Re: bash pollutes namespace it shouldn't touch when emulating sh

[Neven Sajko]

On 28 August 2017 at 17:54, Neven Sajko <nsajko@gmail.com> wrote:
> On 28 August 2017 at 15:05, Chet Ramey <chet.ramey@case.edu> wrote:
>> On 8/28/17 3:42 AM, Neven Sajko wrote:
>>>> I am not sure what you think Posix mode should do here. Since Posix doesn't
>>>> standardize the behavior of `^', Bash is free to use it as part of history
>>>> expansion. If you think history expansion should behave differently,
>>>> either use histchars to change the default behavior or disable history
>>>> expansion.
>>>
>>> Exactly *because* POSIX doesn't define "^" it should be possible to
>>> use it as you would use any other string. That means being able to
>>> execute ^ if it's in the search path, which is not possible. POSIX
>>> doesn't define histchars so it can't be the neccesary solution for sh
>>> ( i.e., bash emulating sh).
>>
>> A statement like this shows a fundamental misunderstanding of bash's
>> posix mode.
>>
>> Bash in posix mode is not `emulating sh', whatever that means.  Those
>> things that Posix does not standardize are available to the application,
>> in this case bash, to do with as it likes. They are outside the bounds
>> of standardization. When bash is in posix mode, it modifies certain
>> defaults that are not strictly Posix conformant. It doesn't turn off
>> anything that Posix doesn't specify.
>>
>>> sh is not being emulated if you're not compatible with it.
>>
>> The problem with a statement like this is the `it'. There is no single
>> `sh' that is a target for `emulation'. The best standard for `sh' is Posix,
>> and bash is conformant.
>>
>>> Try comparing bash with dash if the example I gave in the first mail
>>> isn't enough.
>>
>> It sounds like you want a shell that doesn't implement anything beyond
>> what Posix specifies. Bash is not that shell.
>>
>> --
>> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>>                  ``Ars longa, vita brevis'' - Hippocrates
>> Chet Ramey, UTech, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/
>
> If there is an executable named '^', or anything else not equal to a
> function or builtin, and it is in a directory in PATH, any POSIX sh
> should allow to executing it by calling the command with the same
> name. If that's not true you're not POSIX compliant. Simple as that.
>
> Maybe reading 
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_01_01
> would help?

On 29 August 2017 at 02:52, Neven Sajko <nsajko@gmail.com> wrote:
> On 28 August 2017 at 21:00, Chet Ramey <chet.ramey@case.edu> wrote:
>> On 8/28/17 11:54 AM, Neven Sajko wrote:
>>
>>> If there is an executable named '^', or anything else not equal to a
>>> function or builtin, and it is in a directory in PATH, any POSIX sh
>>> should allow to executing it by calling the command with the same
>>> name. If that's not true you're not POSIX compliant. Simple as that.
>>
>> That's just not how the standard works. As long as you implement the
>> features Posix standardizes, in the way Posix says they should work,
>> you conform. Posix doesn't say anything about features it doesn't
>> standardize. This is how you get additional metacharacters (&|), syntax
>> features (;;& and ;& case statement terminators), expanded quoting
>> ($'...'), new reserved words (`function', `coproc'), entirely new
>> compound commands (`select'), and transformations like brace and
>> history expansion. None of these things make a shell non-conforming.
>>
>> The standard is not prohibitive. There is an infinite number of things
>> that Posix doesn't cover.
>>
>> --
>> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>>                  ``Ars longa, vita brevis'' - Hippocrates
>> Chet Ramey, UTech, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/
>
> The 'Command Search and Execution' section in POSIX explicitly defines
> a set of command names (alloc autoload bind ...) whose invocation as
> commands is unspecified (as can be seen from the URI provided in my
> previous message), and '^' is not among them.
>
> The fact is, a POSIX compatible shell would execute '^' if it is in
> the PATH. You might simply disable the conflicting features while in
> POSIX mode, or you could also check for an executable in the PATH with
> that name before disabling them, is that really a problem to do for
> POSIX mode?

On 29 August 2017 at 15:45, Chet Ramey <chet.ramey@case.edu> wrote:
> On 8/28/17 8:52 PM, Neven Sajko wrote:
>
>> The 'Command Search and Execution' section in POSIX explicitly defines
>> a set of command names (alloc autoload bind ...) whose invocation as
>> commands is unspecified (as can be seen from the URI provided in my
>> previous message), and '^' is not among them.
>
> That's not the intent of that section. Posix wants to set the execution
> order of special builtins, regular builtins, and shell functions. That
> section doesn't even list all of the regular builtins the various shells
> implement; it's not meant to be exhaustive.
>
>> The fact is, a POSIX compatible shell would execute '^' if it is in
>> the PATH.
>
> Saying this with certainty doesn't make it any more true.  Posix doesn't
> prohibit a shell from implementing a history expansion facility like
> bash's (or a brace expansion facility -- should {a,b} look for and
> execute a file named "{a,b}" from $PATH). It's simply outside the scope
> of the standard.
>
>
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>                  ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, UTech, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/

(Sorry for going off list accidentally.)

Imagine a C API added a function that conflicted with user code, this
is the same thing.

That is what I meant with 'compatibility': bash's sh is not executing
a command because of its nonstandard feature.

Compare with gcc or gawk, they too provide compatibility switches for
disabling nonstandard extensions. As I thought bash did with its POSIX
mode.