A NOTE has been added to this issue. ====================================================================== http://austingroupbugs.net/view.php?id=1123 ====================================================================== Reported By: kre Assigned To: ====================================================================== Project: 1003.1(2013)/Issue7+TC1 Issue ID: 1123 Category: Shell and Utilities Type: Clarification Requested Severity: Objection Priority: normal Status: New Name: Robert Elz Organization: User Reference: Section: 2.6 Page Number: 2353 Line Number: 75006-75007 Interp Status: --- Final Accepted Text: ====================================================================== Date Submitted: 2017-03-04 07:56 UTC Last Modified: 2018-08-05 21:45 UTC ====================================================================== Summary: Problematic specification of execution environment for word expansions ======================================================================
---------------------------------------------------------------------- (0004070) kre (reporter) - 2018-08-05 21:45 http://austingroupbugs.net/view.php?id=1123#c4070 ---------------------------------------------------------------------- Since this report must be reaching the head of the queue to be discussed soon, I thought I'd do a little experiment to see what the standard should actually say for this ... I ran the following little script (which was /tmp/T) V=${C:=XYZZY} $A ${B=-l} ${F:=foo.c} > ${R:=/tmp/junk} 2>/dev/null printf 'A<%s> B<%s> C<%s> F<%s> R<%s> V<%s>\n' \ "$A" "${B}" "${C}" "${F}" "${R}" "${V}" in a loop like: for S in 'bash -o posix' bash <....> do printf '%s: ' "${S} A=: $S /tmp/T printf '%s: ' "${S} A=ls $S /tmp/T done (using every shell I have available that I remembered ...) and obtained the following results: bash -o posix: A<:> B<-l> C<XYZZY> F<foo.c> R</tmp/junk> V<XYZZY> bash -o posix: A<ls> B<-l> C<XYZZY> F<foo.c> R<> V<> bash: A<:> B<-l> C<XYZZY> F<foo.c> R</tmp/junk> V<> bash: A<ls> B<-l> C<XYZZY> F<foo.c> R<> V<> bosh: A<:> B<-l> C<XYZZY> F<foo.c> R</tmp/junk> V<XYZZY> bosh: A<ls> B<-l> C<XYZZY> F<foo.c> R</tmp/junk> V<> dash: A<:> B<-l> C<XYZZY> F<foo.c> R</tmp/junk> V<XYZZY> dash: A<ls> B<-l> C<XYZZY> F<foo.c> R</tmp/junk> V<> fbsh: A<:> B<-l> C<XYZZY> F<foo.c> R</tmp/junk> V<XYZZY> fbsh: A<ls> B<-l> C<XYZZY> F<foo.c> R</tmp/junk> V<> ksh93: A<:> B<-l> C<XYZZY> F<foo.c> R</tmp/junk> V<XYZZY> ksh93: A<ls> B<-l> C<XYZZY> F<foo.c> R</tmp/junk> V<> ksh: A<:> B<-l> C<XYZZY> F<foo.c> R</tmp/junk> V<XYZZY> ksh: A<ls> B<-l> C<XYZZY> F<foo.c> R</tmp/junk> V<> mksh: A<:> B<-l> C<XYZZY> F<foo.c> R</tmp/junk> V<XYZZY> mksh: A<ls> B<-l> C<XYZZY> F<foo.c> R</tmp/junk> V<> pdksh: A<:> B<-l> C<XYZZY> F<foo.c> R</tmp/junk> V<XYZZY> pdksh: A<ls> B<-l> C<XYZZY> F<foo.c> R</tmp/junk> V<> sh: A<:> B<-l> C<XYZZY> F<foo.c> R</tmp/junk> V<XYZZY> sh: A<ls> B<-l> C<XYZZY> F<foo.c> R</tmp/junk> V<> yash: A<:> B<-l> C<XYZZY> F<foo.c> R</tmp/junk> V<XYZZY> yash: A<ls> B<-l> C<XYZZY> F<foo.c> R</tmp/junk> V<> zsh: A<:> B<-l> C<XYZZY> F<foo.c> R</tmp/junk> V<> zsh: A<ls> B<-l> C<> F<foo.c> R<> V<> Most of those shells are obvious to all of you I think, "sh" is the NetBSD shell, "ksh" is /bin/ksh on NetBSD which is a very very close relation of pdksh (and I'd be surprised if the results were different, and they aren't...) fbsh is a slightly old now version of the FreeBSD shell. I included the V= output just for interest, what happens to V is unrelated to the current issue, and is best ignored here. What this shows is that *all* shells (or all I tested, I have no access to either ksh88 or some old SysVR4 /bin/sh) expand the command word and its args in the current shell environment, not that of the command to be executed, which I think is unavoidable (as mentioned in the original bug report). That is the values of B and F. Further all shells with the exception of zsh (which was not in its posix emulation mode, as I am not a zsh user, and have no idea how to make that happen correctly, it has no "-o posix") expand the variable assignment in the current shell execution environment, only zsh does it in the envoronment of the command to be executed. This is the value of C. And lastly, all shells but bash (in posix mode, or not) and zsh evaluate expansions in redirects in the current shell environment, not in the environment of the command to be executed (but as you will observe I did not test a here document expansion for this, that one might be different.) When reviewing this, in order to propose some new text to replace what is broken, I also noticed the following lines... (lines 75008-75010) If the complete expansion appropriate for a word results in an empty field, that empty field shall be deleted from the list of fields that form the completely expanded command, which are fine up to there, but continue: unless the original word contained single-quote or double-quote characters. which I am sure is not what was intended. Consider the (whole) word: ${F:+"xxx"} If F is unset or null, the whole word (field) should be deleted, regardless of the "" characters that are present - only quote characters that are actually processed as part of the expansion matter for this purpose. This could be a whole new bug report, but it seems a bit over the top to not just fix it all in one action (the following lines, 75011..75019 are the subject of another issue, so those can be handled with that one.) To handle all of this, the following note will propose some new text to replace (all of) lines 75008-75013, though I am not really happy with the wording of most of it - at least it should provide a starting point for discussion. Issue History Date Modified Username Field Change ====================================================================== 2017-03-04 07:56 kre New Issue 2017-03-04 07:56 kre Name => Robert Elz 2017-03-04 07:56 kre Section => 2.6 2017-03-04 07:56 kre Page Number => 2353 2017-03-04 07:56 kre Line Number => 75006-75007 2018-08-05 21:45 kre Note Added: 0004070 ======================================================================
