Chet Ramey wrote in
 <[email protected]>:
 |On 4/11/25 3:47 AM, Steffen Nurpmeso via austin-group-l at The Open Group 
 |wrote:
 |>|So I think the question for the shell authors is can they reach a
 |>|consensus on which two behaviors are "right" (by which I mean they meet
 |>|user expectations, not that they behave as currently described in the
 |>|standard), or do they think more than two of the observed behaviors are
 |> 
 |> Well, only to add that bash, NetBSD k?sh and possibly more behave
 |> exactly "as currently described in the standard", except for, as
 |> you say, the special parameter $*, they use "the quoted variant of
 |> $*" as a source for field splitting, instead of generating "one
 |> field for each positional parameter that is set", and splitting
 |> the result of that.
 |
 |That doesn't matter; the implementation doesn't matter. All that matters
 |is that the result conforms to the standard, and the bash output does
 |("any empty fields may be discarded").

I am sorry that you alway react stroppingly if i come over with
something, unless you are right or can give advice.
The above is plain not true, and it took me months to finally
believe that it is not my code that is broken, but that the
standard is not in line with what is actually happening.
And never was, as Geoff Clare has shown when trying against ksh88.

 |The question is whether shells will agree on *which* empty fields are
 |discarded. Since bash has behaved this way for a very long time (I
 |stopped looking at bash-3.0, which was released in 2002), I don't see
 |changing the behavior. As to your user expectations question, I think
 |that's been set by the decades of consistent behavior. (That plus the
 |constant drumbeat of advice not to use unquoted $* in any circumstance.)

This drumbeat was on the bash list, yes.

 |For everyone who isn't on the bash mailing list, this is the message
 |from kre that Steffen is referring to that explains the bash and NetBSD
 |sh behavior.
 |
 |https://lists.gnu.org/archive/html/bug-bash/2025-03/msg00030.html

No.  That is not the message.  But i looked, and it more is

  https://lists.gnu.org/archive/html/bug-bash/2025-03/msg00041.html

    * Expands to the positional parameters, starting from one,
      initially producing one field for each positional parameter that
      is set. When the expansion occurs in a context where field
      splitting will be performed, any empty fields may be discarded
      and each of the non-empty fields shall be further split as
      described in Section 2.6.5.

  By the very meaning of this the fields are split individually,
  *first*.  This is exactly what i do.
  Hence
      echo $#,1="$1"/$1,2="$2"/$2,3="$3"/$3,4="$4"
  ->
      4,1=:a:/ a ,2=a/a,3=/,4=a
  becomes
      :a: -> '' + a
      a -> a
      '' -> discarded (but remembered as it separates fields)
      a -> a
  becomes, with IFS=:, when actually creating the argument
      :a:a::a
  becomes the actual argument
      < a a  a>

  Like is said, in a sh(1) script

    a() {
            echo $#,1="$1"/$1,2="$2"/$2,3="$3"/$3,4="$4"
            echo $#,'*'="$*"/$*,
    }
    set -- '' 'a' ''
    for f in ' ' '' : ': ' ' :'; do
            IFS=$f ; echo "$*"$* $*; a "$*"$* $*;unset IFS
    done

  the difference in between the shells and my shell expression thing

    --- .1  2025-03-15 23:38:31.359307576 +0100
    +++ .2  2025-03-15 23:38:32.715974215 +0100
    @@ -6,10 +6,10 @@ a a a$
     3,*=aaa/a a a,$
     :a: a  a$
     4,1=:a:/ a ,2=a/a,3=/,4=a$
    -4,*=:a::a::a/ a  a  a,$
    +4,*=:a::a::a/ a a  a,$
     :a: a  a$
     4,1=:a:/ a ,2=a/a,3=/,4=a$
    -4,*=:a::a::a/ a  a  a,$
    +4,*=:a::a::a/ a a  a,$
      a  a a$
     3,1= a / a ,2=a/a,3=a/a,4=$
     3,*= a  a a/ a a a,$

as well as

  https://lists.gnu.org/archive/html/bug-bash/2025-03/msg00049.html

  But, dear Robert.  The problem is not an empty field.  The problem
  is that ":a:" has to be splitted to ""+a by itself, not to
  ""+a+"", as the second : only delimits the "a".

and finally

  https://lists.gnu.org/archive/html/bug-bash/2025-03/msg00051.html

  True.  The only logical consequence, and here we come to the
  message of Greg Wooledge, is

    +                       /* In order to be compatible with bash, NetBSD sh 
and NetBSD ksh, at minimum, we need to
    +                        * deriviate from POSIX standardized behaviour, and 
field split the quoted variant instead!
    +                        * This applies to $@ as well as $* */
    +                       if(*spcp->spc_ifs != '\0' && 
!su_cs_is_space(*spcp->spc_ifs)){
    +                               cp = n_var_vlook(n_star, TRU1);
    +                               goto jfs_split;
    +                       }
    +
    +                       /* In all other cases individually field split the 
expanded parameters */

  and with that applied the test produces identical behaviour to all
  of you, including bash.

 |Chet
 |-- 
 |``The lyf so short, the craft so long to lerne.'' - Chaucer
 |   ``Ars longa, vita brevis'' - Hippocrates

In practice it is not that bad, as other programmers surely do
nothing but either looking or even copy+pasting from their
"behaviour of desire" -- thankfully you spent lots of time to
produce an Open Source shell, that also i use.  This likely
explains why it took ~37 years before that discrepancy became
a bug tracker issue.

 |Chet Ramey, UTech, CWRU    [email protected]    http://tiswww.cwru.edu/~chet/
 --End of <[email protected]>

Greetings, and Ciao from Germany,

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

  • Call for input on 2.... Andrew Josey via austin-group-l at The Open Group
    • Re: Call for in... Geoff Clare via austin-group-l at The Open Group
      • Re: Call fo... Steffen Nurpmeso via austin-group-l at The Open Group
        • Re: Cal... Chet Ramey via austin-group-l at The Open Group
          • Re:... Steffen Nurpmeso via austin-group-l at The Open Group
            • ... Chet Ramey via austin-group-l at The Open Group
              • ... Steffen Nurpmeso via austin-group-l at The Open Group
          • Re:... Geoff Clare via austin-group-l at The Open Group
            • ... Steffen Nurpmeso via austin-group-l at The Open Group
              • ... Geoff Clare via austin-group-l at The Open Group
                • ... Steffen Nurpmeso via austin-group-l at The Open Group
                • ... Geoff Clare via austin-group-l at The Open Group

Reply via email to