svn commit: r343440 - head/bin/sh

Devin Teske dteske at FreeBSD.org
Fri Jan 25 22:50:41 UTC 2019



> On Jan 25, 2019, at 2:47 PM, Devin Teske <dteske at FreeBSD.org> wrote:
> 
> 
> 
>> On Jan 25, 2019, at 2:41 PM, Devin Teske <dteske at FreeBSD.org <mailto:dteske at FreeBSD.org>> wrote:
>> 
>> 
>> 
>>> On Jan 25, 2019, at 1:37 PM, Edward Napierala <trasz at freebsd.org <mailto:trasz at freebsd.org>> wrote:
>>> 
>>> pt., 25 sty 2019 o 19:57 Rodney W. Grimes
>>> <freebsd at pdx.rh.cn85.dnsmgr.net <mailto:freebsd at pdx.rh.cn85.dnsmgr.net>> napisał(a):
>>>> 
>>>>> Author: trasz
>>>>> Date: Fri Jan 25 17:09:26 2019
>>>>> New Revision: 343440
>>>>> URL: https://svnweb.freebsd.org/changeset/base/343440 <https://svnweb.freebsd.org/changeset/base/343440>
>>>>> 
>>>>> Log:
>>>>>  Comment out the default sh(1) aliases for root, introduced in r343416.
>>>>>  The rest of this stuff is still to be discussed, but I think at this
>>>>>  point we have the agreement that the aliases should go.
>>>>> 
>>>>>  MFC after:  2 weeks
>>>>>  Sponsored by:       DARPA, AFRL
>>>> 
>>>> Please just revert this and the prior commit out, and when
>>>> the path forward is clear commit it.  I would not want any of this
>>>> merged to 12/ or 11/ until the time that it is all settled.
>>> 
>>> Oops, my bad - neither this nor the previous commit is supposed
>>> to be MFC-ed; the "2 weeks" above comes from my default Subversion
>>> config.
>>> 
>>> Regarding the backoff - just a few hours ago you said you don't have
>>> any problem with this, except for aliases and the default ENV.  The
>>> aliases problem has been addressed, and you hadn't yet responded
>>> to my explanations regarding the ENV.  Another committer asked for
>>> backoff, because "sh is not an interactive shell", while in fact sh(1)
>>> is FreeBSD's default interactive shell except for root.  Finally, there's
>>> one person who asked for revert, but without giving any reasons
>>> whatsoever.
>>> 
>>> So far nobody had proposed any scenario where this would break
>>> anything, or even affect existing users.  It seems like a typical bikeshed
>>> situation.
>> 
>> It is not clear to me after reading r343416 and D18872 what this change is trying to solve.
>> 
>> PS1 should have a reasonable default. If that default is not reasonable, then we should change the C code.
>> 
>> Maybe I see things differently, but I'd rather see PS1 default change so no profile/shrc change is necessary.
>> 
>> I prefer that sh, in its default configuration, not attempt to read $HOME/.shrc, for security reasons.
>> 
>> Further, it is documented that the contents of ENV may be ignored in privileged mode, negating these changes.
>> 
>> If you wanted your new shiny default PS1 to actually have an effect in all modes (including privileged mode, where you probably want it), you would have put it in /etc/profile and not in a file that is wholly ignored by some modes (e.g., privileged mode).
>> 
>> So the solution is not even the right one for the desired result.
> 
> I would also like to add, that the current default for PS1 is static for a reason.
> 
> Long ago, people used to write things in TCL/Expect. If PS1 is not static, you either have to override it or account for the variance (# for root, $ for others).
> 
> This is an important distinction specifically because TCL/Expect is used in the control of interactive shells.

And an aside:

I still program in TCL/Expect. I have been known to customize PS2 and PS4.

I may have neglected to give reasons previously, but that's because I was in a meeting and unable to expand on the particular technical intricacies:

1. The relationship default PS1, PS2, and PS4 have with software like TCL/Expect
2. The fact that ENV is wholly ignored in privileged mode
3. The fact that introducing ~/.shrc as a runnable file for interactive sh globally and by-default is something that should be run by secteam
-- 
Devin



More information about the svn-src-head mailing list