Re: Question on $@ vs $@$@
On Wed, Aug 14, 2024 at 09:23:49AM -0400, Greg Wooledge wrote:
> The most obvious would be to treat "$@$@" as if it were "$@" "$@",
> generating exactly two words for each positional parameter.
>
>
Thanks for this. My two cents:
if I want "$@" "$@", i write it litterally. "$@$@" kinda tricks me
in that case because it's not consistent with the other cases I already
used ("$foo$@", for exemple).
> If there are *two* instances of $@ within the same word, then the final
> parameter of the *first* $@ is supposed to be "joined with the last
> part of the original word". But the "last part of the original word"
> is another list expansion, not a string! What does it even mean for
> the final parameter to be "joined" with a list expansion?
good point: that's ambigious. zsh has the explicit twigil $^ (inspired
by the rc operator, I think) to make the distribution explicit (like a
brace expansion) but as dash lack both those features, I still think
my proposal both more consistent and doing something different.
> So, neither of these results would shock me:
> (treat it like "$@$*")
> (treat it like "$*$@")
well. "$@" "$@", $@$* and $*$@ are clear syntaxes that proves an intention
so "$@$@" should be another one related to the fact that something is
joined at the boundary. and to me "something" means "anything left between"
(possibly empty).
so: set A B
"$@ x $@" => "A" "B x A" "B"
"$@$@" => "A" "BA""B"
> I'd still love to know what the script's intent is.
I my guess would be based on "nothing but what the other syntaxes
provides more expicitly".
regards
--
Marc Chantreux
Pôle CESAR (Calcul et services avancés à la recherche)
Université de Strasbourg
14 rue René Descartes,
BP 80010, 67084 STRASBOURG CEDEX
03.68.85.60.79
Re: Question on $@ vs $@$@
Hello.
Unfortunately i have to add one thing to this thread..
Steffen Nurpmeso wrote in
<20240814200534.Vh3Eu_Md@steffen%sdaoden.eu>:
|Chet Ramey wrote in
| <1bba673e-5ab9-4263-9d88-124854793...@case.edu>:
||On 8/13/24 8:45 PM, Steffen Nurpmeso wrote:
||> I include bug-bash even though i think bash is correct, but there
||> lots of people of expertise are listening, so, thus.
||> Sorry for cross-posting, nonetheless.
||> Given this snippet (twox() without argument it is)
||>
||>one() { echo "$# 1<$1>"; }
||>two() { one "$@"; }
||>twox() { one "$@$@"; }
||>two
||>two x
||>twox
||>twox x
| ...
||When, as in this case, the result would be split if the double quotes
||weren't there, $@ within double quotes expands to nothing if there are
||no positional parameters, no matter how many times it appears.
|
|As was shown there is standard wording which makes this case
|explicitly unspecified. Thanks for pointing this out. I should
|have reread the standard first (that particular wording is hard to
|grasp for me).
...
In fact Geoff Clare (who we all deserve thanks, together with Don
Cragun, for continued ISO C compiler support for the BSD socket
interface we all use in at least POSIX environments, it is
undefined anywhere else!, and more) sees this differently:
The standard clearly requires "$@$@" to generate zero fields if
there are no positional parameters. The quoted text "if the
expansion is embedded within a word which contains one or more
other parts that expand to a quoted null string, ..." does not
apply because there are no other parts that expand to a quoted
null string. (The second $@ is not a candidate for being such
a part because "the expansion of '@' shall generate zero
fields".)
If this does not match existing behaviour in some shells, we
could consider making it unspecified, but the first step should
be to alert the maintainers of those shells to the issue and
find out whether they are willing to change their shell to
comply with the standard.
So please any shell maintainer listening here, please feel
alerted.
(P.S.: regarding
> I'd still love to know what the script's intent is.
It will be a test. My MUA does not yet apply word splitting for
unquoted variable expansions, and while going that road, there was
a pitfall.)
--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)
Re: Question on $@ vs $@$@
One more, please.
(And please excuse this still copies bug-bash.)
Steffen Nurpmeso wrote in
<20240815184858.r5T_UQnM@steffen%sdaoden.eu>:
|Steffen Nurpmeso wrote in
| <20240814200534.Vh3Eu_Md@steffen%sdaoden.eu>:
||Chet Ramey wrote in
|| <1bba673e-5ab9-4263-9d88-124854793...@case.edu>:
|||On 8/13/24 8:45 PM, Steffen Nurpmeso wrote:
|||> I include bug-bash even though i think bash is correct, but there
|||> lots of people of expertise are listening, so, thus.
|||> Sorry for cross-posting, nonetheless.
...
|In fact Geoff Clare (who we all deserve thanks, together with Don
|Cragun, for continued ISO C compiler support for the BSD socket
|interface we all use in at least POSIX environments, it is
|undefined anywhere else!, and more) sees this differently:
|
| The standard clearly requires "$@$@" to generate zero fields if
| there are no positional parameters. The quoted text "if the
| expansion is embedded within a word which contains one or more
| other parts that expand to a quoted null string, ..." does not
| apply because there are no other parts that expand to a quoted
| null string. (The second $@ is not a candidate for being such
| a part because "the expansion of '@' shall generate zero
| fields".)
|
| If this does not match existing behaviour in some shells, we
| could consider making it unspecified, but the first step should
| be to alert the maintainers of those shells to the issue and
| find out whether they are willing to change their shell to
| comply with the standard.
|
|So please any shell maintainer listening here, please feel
|alerted.
I have extended the test a bit, and i also see word split
differences. Call me idiotic, but .. there seems some state
machinery bug in dash / busybox sh, maybe.
So if i save the code below into a file named t.sh, and if i run
"sh t.sh", then i only get the "$@$@" differences this thread is
about. But if i run "sh t.sh X" then i get an additional
1,1=ja "da du $j" ich,2=,3=,4=,5=,6=,7=,8=,9=,
| 5,1=ja,2="da,3=du,4=$j",5=ich,6=,7=,8=,9=,
.. 5,1=ja "da du $j" ichja "da du $j"
ichja,2="da,3=du,4=$j",5=ich,6=,7=,8=,9=,| ..
13,1=ja,2="da,3=du,4=$j",5=ichja,6="da,7=du,8=$j",9=ichja,
difference in between dash+ (left) and bash (right).
Now i am looking for too long on these, but can anyone reproduce
this on another machine? I *can* reproduce it on an AlpineLinux
[edge] vserver. Ie
sh t.sh > .A
bash t.sh > .B
diff -u .A .B > .D1
sh t.sh X > .A
bash t.sh X > .B
diff -u .A .B > .D2
(Must be said that diffutils diff(1) gives different hunks than
busybox diff, but that aside.)
y() { echo ".. $#,1=$1,2=$2,3=$3,4=$4,5=$5,6=$6,7=$7,8=$8,9=$9,"; }
x() { echo "$#,1=$1,2=$2,3=$3,4=$4,5=$5,6=$6,7=$7,8=$8,9=$9,"; y "$@$@"$@; }
i='ja "da du $j" ich' j=recur
if [ $# -eq 1 ]; then
echo =1=
x ja "da du $j" ich
x ja:"da du $j":ich
x $i
x "$i"
eval x $i
eval x "$i"
x ''
eval x ''
echo =2=
IFS=: x ja "da du $j" ich
IFS=: x ja:"da du $j":ich
IFS=: x $i
IFS=: x "$i"
IFS=: eval x $i
IFS=: eval x "$i"
IFS=: x ''
IFS=: eval x ''
fi
echo =3=
IFS=': ' x ja "da du $j" ich
IFS=': ' x ja:"da du $j":ich
IFS=': ' x $i
IFS=': ' x "$i"
IFS=': ' eval x $i
IFS=': ' eval x "$i"
IFS=': ' x ''
IFS=': ' eval x ''
if [ $# -eq 1 ]; then
echo =4=
i=
x $i
x "$i"
eval x $i
eval x "$i"
fi
Ciao!
--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)
