Date: Sat, 18 Nov 2023 21:45:43 +0900 From: Tomoaki AOKI <junchoon@dec.sakura.ne.jp> To: stable@freebsd.org Subject: Re: csh to sh migration for root in RELENG_14 Message-ID: <20231118214543.d58208170ca51ecc08ccddeb@dec.sakura.ne.jp> In-Reply-To: <CO1PR11MB4770E2ACB800E232EF598666E6B6A@CO1PR11MB4770.namprd11.prod.outlook.com> References: <6c6add3c-4a5e-4d84-9964-9a9448a36c95@sentex.net> <25943.49653.523313.53953@hergotha.csail.mit.edu> <CO1PR11MB4770E2ACB800E232EF598666E6B6A@CO1PR11MB4770.namprd11.prod.outlook.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 18 Nov 2023 02:07:24 -0700 "Edward Sanford Sutton, III" <mirror176@hotmail.com> wrote: > On 11/17/23 12:41, Garrett Wollman wrote: > > <<On Fri, 17 Nov 2023 13:40:44 -0500, mike tancsa <mike@sentex.net> said: > > > >> I am trying to bring my environment along from previous versions where > >> csh was the default shell and now trying to get used to sh. In the past > >> things like > > > >> sudo su > > > >> would pick up my settings in /root/.cshrc automatically. However, with > >> sh I have to do > > > >> sudo su -l root > > > >> Is there a way to configure it so I dont need the -l as part of the su > >> to get the same behavior ? > > > > See sh(1) section "Invocation", which describes how /bin/sh reads its > > initialization files, and in particular, that (as POSIX specifies) > > interactive non-login shells do not read any startup files unless the > > environment variable `ENV` is set. This is stupid but required by the > > standard. > > > > I would recommend changing root's shell to something that better suits > > your needs: either change it back to csh, or install the appropriate > > package and set it to bash or zsh, both of which read startup files > > for all interactive shells, not just login shells. > > Though it was worse when upgrading using portupgrade and less likely to > be an issue with packages, I would still consider trying to keep root's > shell as a shell that is part of base and if I really wanted a different > one then I would have a 3rd party shell get launched from a shell from > base as part of the sign in process so it could 'fall back' to skipping > the launch if it fails. This comes from having had issues with 3rd party > shells not functioning for reasons such as it depending on a library > that failed to install properly. I do not have my desktop boot into X > automatically or use a graphical login manager for the same reason; > problems are easier to fix when you can still log in successfully. I > have not often had such issues, but I certainly have had them. > > > -GAWollman Just a FYI: I'm using zsh as interactive shell for now, and I have the line below in ~/.tcshrc.mine, keeping base tcsh as login shell. if ( -X zsh && -f ~/.Use_zsh ) exec zsh This way, if zsh is executable in the path AND ~/.Use_zsh exists, zsh is executed, otherwise tcsh keeps running as interactive shell. If zsh accidentally (or intentionally) dissappears, base tcsh is used. Assuming zsh is available and executable, I can intentionally create ~/.Use_zsh (`touch ~/.Use_zsh` is enough) to use zsh and delete it to use base tcsh. -- Tomoaki AOKI <junchoon@dec.sakura.ne.jp>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20231118214543.d58208170ca51ecc08ccddeb>