Re: ignoring current shell and always running posix shell? Re: Should this be this way?
On Tue, Mar 12, 2013 at 12:37 AM, Linda Walsh wrote: > Pierre Gaston wrote: >>> >>> >>> It is likely that the document is assuming you are running on >>> a POSIX compliant system where all users use the same shell so there is >>> only 1 shell, thus the use of the word 'the' when referring to the shell. >>> >> Of course, it's the posix specification for the posix shell > > What does that say about bash (in nonposix mode), perl, python, > rbash, etc i.e. -- the case that I ran into was NOT me running in posix > mode. Not much the bash part was covered by quoting the manual. No part of this email was about you, I was merely answering to Roman about the fact that it is specified in the 2 documents that are somehow relevant on this mailing list. > It would make no sense for posix to take the stance that any > unknown script without a shebang at the top, presented to any interpreter > shell > be ignored by the interpreter and instead shall be run under /bin/sh. > > Posix used to claim they were "descriptive", not "prescriptive", > though > they are becoming more of the latter with each new update, I'd find it hard to > think they'd try to enforce all script languages to default sources to > /bin/sh. > Afaik Posix doesn't impose anything on anyone but those who want to claim being posix compliant. (and yeah perl and python don't try to be compliant with the posix shell specification).
Re: ignoring current shell and always running posix shell? Re: Should this be this way?
On 3/11/13 6:37 PM, Linda Walsh wrote: > It would make no sense for posix to take the stance that any > unknown script without a shebang at the top, presented to any interpreter > shell > be ignored by the interpreter and instead shall be run under /bin/sh. The Posix shell specification only talks about the Posix shell. Likewise, Posix takes no position on whether or not shells offer extensions beyond the Posix-specified functionality. There are no other Posix interpreters (well, ok, there's awk). The likelihood of users attempting to run a script written in an arbitrary non-shell language without a #! from the shell prompt is quite small, so it's reasonable for the standard to contain what it does. The standard attempts to codify existing historical practice. > Posix used to claim they were "descriptive", not "prescriptive", though > they are becoming more of the latter with each new update, I'd find it hard to > think they'd try to enforce all script languages to default sources to > /bin/sh. You're entitled to your opinion. The fact remains, though, that this same language, or something very similar, has been in the Posix standard since 1992. As I said above, it attempts to standardize historical practice. The default bash behavior and the SuSE modification are both conformant. The more interesting question is why SuSE feels the need to do this. The original bug report from five years ago admits that it's not a solution to the underlying SuSE-specific problem, just a workaround. Subseqent comments admit that the problem has been fixed for quite a while, but "may reappear at any time." I find this unconvincing, but it's not the first time a vendor has changed bash, not documented the result, and declined to revisit the decision. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Feature request: NUL delimiter for mapfile/readarray
Howdy -- Right now, mapfile isn't suitable for any case where arbitrary C strings need to be read -- which is the case when handling filenames, serializing/deserializing arbitrary command-line parameters, and many other such situations. Is there any chance of getting a -d '' (akin to read) or -0 (GNU convention) option to allow NULs to be used? This significantly decreases the number of places where I can use mapfile. Thanks, -- Charles
