bugThe GNU Bourne-Again SHell - Bugs: bug #65651, argument reference inconsistency

 
 

bug #65651: argument reference inconsistency

Submitter:  None
Submitted:  Sun 28 Apr 2024 06:51:44 AM UTC
   
 
Category:  None Severity:  3 - Normal
Item Group:  None Status:  Invalid
Privacy:  Public Assigned to:  None
Open/Closed:  Open
* Mandatory Fields

Add a New Comment Rich Markup
   

Mon 29 Apr 2024 05:25:41 PM UTC, comment #4: 

comment #2:

> I have to add though that the logic of loops can appear wild.

None of this is about loops per se, but the consequences of improper quoting.

> The trespassing set of the 'for' loop you noted depends on a peculiarity of a value which appears as argument to the print command. [...] (If you change "$a" to $a you receive the 6 element set again.)

This is not true.  The positional parameters are iterated over properly, but the subsequent unquoted $a is, again, split.  You can see that the iteration variable takes on the correct values:

for a
do
    declare -p a
done


> That's difficult to understand and doesn't likely satisfy peoples' expectations about procedural determinedness.

Regardless, this is all extremely well established behavior that will not be changing.

> Furthermore it is noteworthy that a single print command which is not in a loop can cause a looping output.
>
> printf 'arg %s\n' "$@"
>
> brings the same result as the loop. Hope this is reproducible.

Not only is it reproducible, it is (as Chet already noted) standardized:

> The format operand shall be reused as often as necessary to satisfy the argument operands. Any extra `b', `c', or `s' conversion specifiers shall be evaluated as if a null string argument were supplied; other extra conversion specifications shall be evaluated as if a zero argument were supplied.

Lawrence Velázquez <larryv>
Mon 29 Apr 2024 01:04:33 PM UTC, comment #3: 

printf reuses the format string as many times as it needs to consume all the arguments. This is standard behavior.

Chet Ramey <chet>
Group administrator
Mon 29 Apr 2024 09:14:54 AM UTC, comment #2: 

Thank you for clarification!

I have to add though that the logic of loops can appear wild. The trespassing set of the 'for' loop you noted depends on a peculiarity of a value which appears as argument to the print command. That's difficult to understand and doesn't likely satisfy peoples' expectations about procedural determinedness. (If you change "$a" to $a you receive the 6 element set again.)

Furthermore it is noteworthy that a single print command which is not in a loop can cause a looping output.

printf 'arg %s\n' "$@"

brings the same result as the loop. Hope this is reproducible.


Anonymous
Sun 28 Apr 2024 07:33:16 AM UTC, comment #1: 

Presumably you're referring to the output with argument set C:

script has 3 arguments
cmdline $* = alp ha be ta gam ma
first 3 args: [alp ha] [be ta] [gam ma]
arg: alp
arg: ha
arg: be
arg: ta
arg: gam
arg: ma

Your `for' command's $* is being split because it is unquoted.  This behavior is documented.

Quoted or not, $* is ill-suited for iteration.  Correct alternatives include

for a
do
    printf 'arg: %s\n' "$a"
done

or the more explicit

for a in "$@"
do
    printf 'arg: %s\n' "$a"
done


Lawrence Velázquez <larryv>
Sun 28 Apr 2024 06:51:44 AM UTC, original submission:  

Try the following script w/ various sets of arguments and tell me if you see something weird!

#!/bin/bash
echo "script has $# arguments"
echo "cmdline \$* = $*"
echo "first 3 args: [$1] [$2] [$3]"

for a in $*
do
   echo "arg: $a"
done

Argument set:
A)   alpha beta gamma
B)   "alpha" "beta" "gamma"
C)   "alp ha" "be ta" "gam ma"

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by chet (Updated the item)
  • -email is unavailable- added by larryv (Posted a comment)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2024-04-28 chet StatusNone Invalid

    Back to the top

    Powered by Savane 3.13-4b48.
    Corresponding source code