svn commit: r343440 - head/bin/sh

[Edward Napierala]

sob., 26 sty 2019 o 01:38 Rodney W. Grimes
<freebsd at pdx.rh.cn85.dnsmgr.net> napisał(a):
>
> > On 0125T1705, Rodney W. Grimes wrote:
> > > > > On Jan 25, 2019, at 1:13 AM, Edward Napierala <trasz at freebsd.org> wrote:
> > >
> > > Chop with the big axe most of this as I need to clarify a miss statement.
> > > ...
> > > > > The change we're discussing doesn't affect upgrades at all - it's only
> > > > > for new installs.
> > > >
> > > > mergemaster, iirc, will merge in changes to etc files after an upgrade.
> > > > So this would effect anybody that goes through an upgrade and performs mergemaster.
> > >
> > > Correct, and to my knowledge there is no way to stop that effect.
> >
> > Won't happen in this case, this doesn't apply to files in /etc
> > at all; it only applies to the default /root/.shrc and /root/.profile
> > that get installed on fresh systems.
>
> mergemaster is the wrong term here, freebsd-update is
> going to want to merge this change.

Are you sure freebsd-update also updates root's private configuration
files?  I've never used it, but this seems somewhat surprising.

> > > > >  And it doesn't affect root by default, you
> > > > > need to change their shell from csh(1) to sh(1).
> > > >
> > > > By your own commit messages admission, this is for the toor account, so it does affect a user (and as you were keen to point out, users with the default shell).
> > >
> > > Further it effects root any time root types "sh" or "/bin/sh"
> > > and intentially invokes sh interactive for some reason,
> > > something I do more often than I care to admit simply
> > > cause I know what I want to do is much easier in that
> > > shell.
> >
> > It doesn't.  For sh(1) to read ~/.shrc (/root/.shrc in this case)
> > you need to have ENV set; the default /root/.profile only sets
> > it when sh(1) is your login shell.
> I do not see any conditional logic in /root/.profile,
> what your mis stating is that /root/.profile is not
> run for a login shell, so ENV would not be set unless
> something else caused /root/.profile to be read, aka
> source ~/.profile

Correction: /root/.profile is not-run for non-login shell, so ENV
wouldn't be set.  Yeah, that's what I've meant.

> >   Which means, this doesn't
> > change the behaviour when you casually run "sh" or "/bin/sh"
> > as root; sh needs to be set up as login shell for this to take
> > effect.
>
> Again I do not see any conditional logic in /root/.profile
> that would make that true.  A su - toor would be effected.

As opposed to 'su - root' or plain '/bin/sh', right.