Date: Fri, 14 Mar 2025 01:34:48 +0100
From: Steffen Nurpmeso <stef...@sdaoden.eu>
Message-ID: <20250314003448.DdqG5Ont@steffen%sdaoden.eu>
| I am deeply sorry, but i have one more difficulty that i fail to
| explain to myself.
As always, there are no rules for this for MUAs so you can
really do what you like, but:
| It *could* (small, very small case) be that
| this time the incorrectness really is on the side of bash.
It isn't. bash is correct.
| a() {
| echo $#,1="$1"/$1,2="$2"/$2,3="$3"/$3,4="$4"
| echo $#,'*'="$*"/$*,
When that echo command is run in the (uncommented) command
given the args to echo are (this can easily be seen if you
enable -x) are:
echo '4,*=:a::a::a/' a '' a '' a,
that is from bash, the NetBSD shell does:
echo '4,*=:a::a::a/' a '' a '' a,
which looks rather similar...
Note, not all shells do it that way, mksh does
echo '3,*=:a::a:a/' a '' a a,
The spec for unquoted $* expansion allows for some variations.
To see why it is the way it is, we need to start with the command:
a "$*"$* $*
The "$*" generates ":a:" (that's simple enough), the 2nd $* generates 3
words, '' 'a' and '' so now we have
":a:"'' a ''
then the third $* generates the same 3 words as the first, so we end
up with
":a:"'' a '' '' a ''
which is where things get variable. The '' that's appended to ":a:"
adds nothing, that one essentially just gets merged and vanishes.
This is where POSIX gets involved (in the description of the
special parameter '*' in XCU 2.5.2)
When the expansion occurs in a context where field
splitting will be performed,
which is here, the unquoted $* expansions
any empty fields may be discarded and each of the non-empty ...
(the remainder is irrelevant here). "may be discarded", shells
are allowed to keep or discard them.
Both bash and the netbsd shell retain leading empty words from $*
expansions, but drop the last, try looking at what happens if you
do
set -- '' '' a '' '' b '' ''
At that point $# is 8 (the 8 words explicitly set)
Now do
set -- $*
and in bash (and NetBSD) $# is now 7, the final '' vanishes.
Do that again, and $# is now 6, what was the 2nd last '' (but
is now last) vanishes. After that, repeating the command changes
nothing, as there's no longer a trailing ''.
In mksh it seems that leading and trailing empty words from $*
get dropped, but intermediate ones are retained. So from when $#
starts as 8, its next step is to 6 args (the initial '' and final ''
are both dropped) and then to 4 (the same happens again).
This output (from your message) shows what is happening
| 4,1=:a:/ a ,2=a/a,3=/,4=a
Showing that $1 is ":a:/ a " $2 is "a" $3 is "" and $4 is 'a'
Given those values, the output you're not expecting is obvious
| 4,*=:a::a::a/ a a a,
There is a space at the end of $1, so when $2 is appended, two
spaces precede the 'a' (one from $1, and one inserted by echo
between the values of its args). the two spaces after that
you're not concerned with I think, but that is $2 $3 $4 where $3
is '' so you end up with 'a' space nothing space 'a'
(where the "space" comes from echo).
If you are getting the same output from the first echo line inside
a() as bash generates (you didn't show yours for that), then it is
hard to see how you could be generating anything different. But
if your 1st echo output is different, as it is for mksh for example:
3,1=:a:/ a ,2=a/a,3=a/a,4=
then anything is possible, this results in
3,*=:a::a:a/ a a a,
for the second line of output. The space you're unsure of is
still there, but there aren't two between the final two 'a' chars,
as the empty extra arg (what was $3 for bash etc) isn't present.
| I find this logical since before the
| resplit we have ":a:" + "a" + "" + "a", and the trailing ":" in
| the first only delimits the field of "a",
The ':' really has little to do with it, the space is a data
char, it isn't in IFS, so isn't going to be touched by field
splitting, and by this time, shell parsing is long done, so its
tokenisation (which drops unquoted whitespace normally) is no
longer relevant either.
If you ever needed a justification to never use unquoted $* (or $@ which
is the same thing) when any of the numeric params can possibly be
empty strings, then this is it. Just don't do that.
kre
