Question on $@ vs $@$@

Question on $@ vs $@$@

[Steffen Nurpmeso]

Hello.

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

i get

  $ dash shbug.sh
  0 1<>
  1 1<x>
  1 1<>
  1 1<xx>

  #?0|kent:tmp$ busybox.static sh shbug.sh
  0 1<>
  1 1<x>
  1 1<>
  1 1<xx>

  #?0|kent:tmp$ bash shbug.sh
  0 1<>
  1 1<x>
  0 1<>
  1 1<xx>

(This is busybox with my arithmetic patch, built on April 20th.)
Unfortunately my MUA is also bogus :(

--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 $@$@

[Greg Wooledge]

On Wed, Aug 14, 2024 at 02:45:25 +0200, 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

So... what's the question?  You didn't actually ask anything.

As far as I can tell from the bash man page, "$@$@" does not appear to
be well-defined.  From the man page:

       @      Expands to the positional parameters,  starting  from  one.   In
              contexts  where  word  splitting is performed, this expands each
              positional parameter to a separate word; if  not  within  double
              quotes,  these words are subject to word splitting.  In contexts
              where word splitting is not performed, this expands to a  single
              word  with each positional parameter separated by a space.  When
              the expansion occurs within double quotes,  each  parameter  ex‐
              pands  to  a separate word.  That is, "$@" is equivalent to "$1"
              "$2" ...  If the double-quoted expansion occurs within  a  word,
              the  expansion  of the first parameter is joined with the begin‐
              ning part of the original word, and the expansion  of  the  last
              parameter  is  joined  with  the last part of the original word.
              When there are no positional parameters, "$@" and $@  expand  to
              nothing (i.e., they are removed).

We know what "$@" is supposed to do.  And something like "x${@}y" is
well-defined also -- you simply prefix "x" to the first word, and append
"y" to the final word.

But I don't know how "$@$@" is supposed to be interpreted.  I do not see
anything in the official wording that explains how it should work.

Therefore, *my* question is: what are you trying to do?

Given a series of positional parameters, such as

    set -- '' "two words" foobar

what do you expect "$@$@" to expand to?  Bash 5.2 gives me

    hobbit:~$ set -- '' "two words" foobar
    hobbit:~$ printf '<%s> ' "$@$@"; echo
    <> <two words> <foobar> <two words> <foobar> 

which appears to concatenate the last word of the list and the first
word of the list -- a reasonable output, I would say.  Here's a clearer
look:

    hobbit:~$ set -- a '' b
    hobbit:~$ printf '<%s> ' "$@$@"; echo
    <a> <> <ba> <> <b>

I can't complain about this result.  But at the same time, I can't say
"this is the best possible result".  Other interpretations seem equally
valid.  I just wonder what your intent was, in using the "$@$@" expansion
in the first place.

Re: Question on $@ vs $@$@

[Marc Chantreux]

> We know what "$@" is supposed to do.  And something like "x${@}y" is
> well-defined also -- you simply prefix "x" to the first word, and append
> "y" to the final word.

> But I don't know how "$@$@" is supposed to be interpreted.  I do not see
> anything in the official wording that explains how it should work.

As the doc you just mention said: let's set A B C

     "x$@y"    yA" "B" "Cy"

So the only consistent behavior I see is

     "$@$@"    A" "B" "CA" "B" "C"
                        ^-("$3$1")

     "$@ $@"    A" "B" "C A" "B" "C"
                        ^-("$3 $1")

I'm really currious: do you see another one ?

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 $@$@

[Greg Wooledge]

On Wed, Aug 14, 2024 at 11:04:08 +0200, Marc Chantreux wrote:
> > We know what "$@" is supposed to do.  And something like "x${@}y" is
> > well-defined also -- you simply prefix "x" to the first word, and append
> > "y" to the final word.
> 
> > But I don't know how "$@$@" is supposed to be interpreted.  I do not see
> > anything in the official wording that explains how it should work.
> 
> As the doc you just mention said: let's set A B C
> 
>      "x$@y"    yA" "B" "Cy"
> 
> So the only consistent behavior I see is
> 
>      "$@$@"    A" "B" "CA" "B" "C"
>                         ^-("$3$1")
> 
>      "$@ $@"    A" "B" "C A" "B" "C"
>                         ^-("$3 $1")
> 
> I'm really currious: do you see another one ?

The most obvious would be to treat "$@$@" as if it were "$@" "$@",
generating exactly two words for each positional parameter.

    <A> <B> <C> <A> <B> <C>

As a human trying to read this expression and figure out what it means,
I keep returning to the documentation.  "... the expansion of the first
parameter is joined with the beginning part of the original word" and
"... the expansion of the last parameter is joined with the last part
of the original word".

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?

Meanwhile, the first parameter of the *second* $@ is supposed to be
"joined with the beginning part of the original word".  But the "beginning
part of the original word" is once again a list, not a string.

I can't see an unambiguous way to reconcile those.

So, neither of these results would shock me:

    <A> <B> <CA B C>    (treat it like "$@$*")

    <A B CA> <B> <C>    (treat it like "$*$@")

I also wouldn't be shocked if a shell were to say "screw this, I'm just
going to treat it like "$*$*" and give you one big word".

    <A B CA B C>

I wouldn't consider that a *correct* result according to my reading of
the documentation, but also, it wouldn't shock me if some shell did it
that way out of desperation.

The documentation clearly never considered would should happen if the
script uses "$@$@", and I've gotta say, I've been doing shell stuff
for about 30 years now, and this is the first time *I've* ever seen
it come up.

I'd still love to know what the script's intent is.

Re: Question on $@ vs $@$@

[Robert Elz]

    Date:        Wed, 14 Aug 2024 09:23:49 -0400
    From:        Greg Wooledge <greg@wooledge.org>
    Message-ID:  <Zryv5acNkrImASKj@wooledge.org>

  | The most obvious would be to treat "$@$@" as if it were "$@" "$@",

That would clearly be wrong when there are positional parameters.

  | As a human trying to read this expression and figure out what it means,
  | I keep returning to the documentation.  "... the expansion of the first
  | parameter is joined with the beginning part of the original word" and
  | "... the expansion of the last parameter is joined with the last part
  | of the original word".

Yes.   For the minute forget about the "$@$@" case, and see what it
means when there is "$X$@$Y" where we have done "set -- 1 2 3 ; X=x Y=y"
Now just expand things left to right (like always), and I will omit
the quotes, but they are still there:

	$X$@$Y -> x$@$Y  -> x1 2 3$Y -> x1 2 3y

The first expansion is just $X, that's trivial, and makes "x".
The second is (quoted) $@, and since we have 3 positional params
set, that produces 3 fields, 1 2 and 3.  The expansion of the first
(ie: 1) is joined with the beginning part of the original word ("x"
here) to make "x1" and the expansion of the last param (ie: 3) is
joined with the last part of the original word, that is, $Y (so we have "3$Y")
Then Y is expanded making 'y', again trivial.

  | 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".

Yes, it is.

  | But the "last part of the original word" is another list expansion,

Not yet it isn't, if you're expanding "$@$@" using the same setup as
the previous case, we get

	$@$@ -> 1 2 3$@ -> 1 2 31 2 3

Just do the expansions, one at a time, left to right, and it is all
simple.

  | Meanwhile, the first parameter of the *second* $@ is supposed to be
  | "joined with the beginning part of the original word".  But the "beginning
  | part of the original word" is once again a list, not a string.

Again, no it isn't, by the time that second $@ is expanded, the first one
already has been, the final word from that expansion has been joined to
the second $@, and you just expand "3$@" as the word being expanded.


  | So, neither of these results would shock me:
  |     <A> <B> <CA B C>    (treat it like "$@$*")
  |     <A B CA> <B> <C>    (treat it like "$*$@")

They might not shock you, but either of those would be a bug, that's
not how it works, now, or ever.

  | I also wouldn't be shocked if a shell were to say "screw this, I'm just
  | going to treat it like "$*$*" and give you one big word".

No, "$@" is only ever the same as "$*" when it is being expanded in a
situation when field splitting would not be performed (if the quotes were
not there) (and strictly in that case, what "$@" makes is just unspecified
there, it isn't necessarily "$*" - but usually seems to be).   That is,
no-one should ever write
	VAR="$@"
that's unspecified.   Same with 'case "$@" in'.   Most shells just treat
it as "$*" but if "$*" is what the script writer intended, that's what
they should write.

  | The documentation clearly never considered would should happen if the
  | script uses "$@$@",

Probably not, but it isn't really special, you could do "$@$@$@$@$@" if
you wanted, and everything is really perfectly well defined.   Just don't
ever imagine multiple expansions happening in parallel.  They never do.

The one questionable case (the only case where different shells should
be producing different results, other than possible bugs) is when there
are no positional params set ( [ $# = 0 ] is true) and the only 2 possible
results are nothing, and "".

  | I'd still love to know what the script's intent is.

My guess is that it was more academic interest - these things need to
be tested, even if they have no practical import normally, and to test
them, one needs to determine what the correct answer is.

kre

Re: Question on $@ vs $@$@

[Marc Chantreux]

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.
> 
>     <A> <B> <C> <A> <B> <C>

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:
>     <A> <B> <CA B C>    (treat it like "$@$*")
>     <A B CA> <B> <C>    (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 $@$@

[Robert Elz]

    Date:        Wed, 14 Aug 2024 11:04:08 +0200
    From:        Marc Chantreux <mc@unistra.fr>
    Message-ID:  <ZrxzCOnZv-HffFuB@prometheus>

  | I'm really currious: do you see another one ?

The case he was asking about is when $# is 0 (no positional params set)
and whether "$@$@" should result in "" (1 arg) or nothing (0 args).

Upon rereading POSIX, while I am sure that the intent would be to
make that unspecified, just as "$@$X" is, when X is unset or null,
but I'm not convinced that the wording actually does.

As was quoted from POSIX (this time from the new standard, though I
believe this is unchanged, it remains XCU 2.5.2 (the '@' expansion descr)):

    however, if the expansion is embedded within a word which contains one
    or more other parts that expand to a quoted null string, these null
    string(s) shall still produce an empty field,

which I am not sure actually applies in the relevant case, as neither $@
expansion produced a quoted null string, they both produce nothing (when
there are no parameters, which is the only time this is relevant).

So, I am not sure that this exception is relevant, and if it isn't, then
the exception to the exception

    except that if the other parts are all within the same double-quotes
    as the '@', it is unspecified whether the result is zero fields
    or one empty field.

cannot apply either.   That would mean that perhaps "$@$@" might be
specified to produce nothing.   However, as ksh93 makes "" from this
expansion, and so probably ksh88 might have done as well (I don't have
a ksh88 to test it) and as the standard was originally based upon ksh88
if a clarification were added, it would probably be to change the
wording (somehow) so the "$@$@" case is also explicitly unspecified.

kre

Re: Question on $@ vs $@$@

[Oğuz]

On Wed, Aug 14, 2024 at 5:23 PM Robert Elz <kre@munnari.oz.au> wrote:
> However, as ksh93 makes "" from this
> expansion, and so probably ksh88 might have done as well

No, both Sun and SCO variants expand "$@$@" to zero fields when $# is 0.

Re: Question on $@ vs $@$@

[Greg Wooledge]

On Wed, Aug 14, 2024 at 17:58:15 +0300, Oğuz wrote:
> On Wed, Aug 14, 2024 at 5:23 PM Robert Elz <kre@munnari.oz.au> wrote:
> > However, as ksh93 makes "" from this
> > expansion, and so probably ksh88 might have done as well
> 
> No, both Sun and SCO variants expand "$@$@" to zero fields when $# is 0.

HP-UX 10.20 as well:

# set --
# printf '<%s> ' START "$@" END; echo
<START> <END>
# printf '<%s> ' START "$@$@" END; echo
<START> <END>
# uname -a
HP-UX vandev B.10.20 A 9000/778 2000153729 two-user license

Re: Question on $@ vs $@$@

[Chet Ramey]

[-- Attachment #1.1: Type: text/plain, Size: 1051 bytes --]

On 8/13/24 8:45 PM, Steffen Nurpmeso wrote:
> Hello.
> 
> 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
> 
> i get
> 
>    $ dash shbug.sh
>    0 1<>
>    1 1<x>
>    1 1<>
>    1 1<xx>
> 
>    #?0|kent:tmp$ busybox.static sh shbug.sh
>    0 1<>
>    1 1<x>
>    1 1<>
>    1 1<xx>
> 
>    #?0|kent:tmp$ bash shbug.sh
>    0 1<>
>    1 1<x>
>    0 1<>
>    1 1<xx>

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.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

Re: Question on $@ vs $@$@

[Steffen Nurpmeso]

Hello.

I only respond to this to reduce the noise.

Chet Ramey wrote in
 <1bba673e-5ab9-4263-9d88-124854793b4b@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).
And yes, i think bash is doing the more sensitive thing here, as
the standard says that "@" shall expand to zero, and zero plus
zero makes zero for me.

Thank you, and sorry for the noise.

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)

Re: Question on $@ vs $@$@

[Steffen Nurpmeso]

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-124854793b4b@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 $@$@

[Steffen Nurpmeso]

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-124854793b4b@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)

Re: Question on $@ vs $@$@

[Steffen Nurpmeso]

alex xmb sw ratchev wrote in
 <CAALKErGQcz=LS=xC544fXf9OywVmU32s1R-wSKzVTiavQTHZ6Q@mail.gmail.com>:
 |try
 |
 |${@@Q}
 |
 |and
 |
 |${*@Q}
 |
 |greets

I try to avoid using non-portable shell stuff.
I do not think these would be understood by the ash shell variants
(and ksh) which had results other than bash.

--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)