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