On 28 August 2017 at 17:54, Neven Sajko <nsa...@gmail.com> wrote: > On 28 August 2017 at 15:05, Chet Ramey <chet.ra...@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 c...@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 <nsa...@gmail.com> wrote: > On 28 August 2017 at 21:00, Chet Ramey <chet.ra...@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 c...@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.ra...@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 c...@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.
