Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 26 Jan 2019 12:42:27 +0000
From:      Edward Napierala <trasz@freebsd.org>
To:        rgrimes@freebsd.org
Cc:        Devin Teske <dteske@freebsd.org>, src-committers <src-committers@freebsd.org>,  svn-src-all@freebsd.org, svn-src-head@freebsd.org
Subject:   Re: svn commit: r343440 - head/bin/sh
Message-ID:  <CAFLM3-ojFy%2Byggfw%2Bb2AinFqDGbOGLyofvXZFZgUrQabGGWVpw@mail.gmail.com>
In-Reply-To: <201901260137.x0Q1bwDK091299@pdx.rh.CN85.dnsmgr.net>
References:  <20190125095512.GB26744@v2> <201901260137.x0Q1bwDK091299@pdx.rh.CN85.dnsmgr.net>

next in thread | previous in thread | raw e-mail | index | archive | help
sob., 26 sty 2019 o 01:38 Rodney W. Grimes
<freebsd@pdx.rh.cn85.dnsmgr.net> napisa=C5=82(a):
>
> > On 0125T1705, Rodney W. Grimes wrote:
> > > > > On Jan 25, 2019, at 1:13 AM, Edward Napierala <trasz@freebsd.org>=
 wrote:
> > >
> > > Chop with the big axe most of this as I need to clarify a miss statem=
ent.
> > > ...
> > > > > 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 upgr=
ade.
> > > > So this would effect anybody that goes through an upgrade and perfo=
rms 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 t=
he 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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFLM3-ojFy%2Byggfw%2Bb2AinFqDGbOGLyofvXZFZgUrQabGGWVpw>