GNU bug report logs - #76768
BUGGY! "cut" AND "printf" in func arg >> $@

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 76768 in the body.
You can then email your comments to 76768 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "G.K." <kreutzgoran <at> gmail.com>
To: bug-coreutils <at> gnu.org
Subject: BUGGY! "cut" AND "printf"  in func arg >> $@
Date: Thu, 06 Mar 2025 03:46:08 +0100

[Message part 1 (text/plain, inline)]

HI THERE!


the bash code to described the buggy form 

two commands cut and printf 

is this a error from commands 
seperated this mail in two parts 




two attachment pic displayed standardout 


I'AM USED TERMUX , ANDROID 11 ON FON GS4



THIS IS TEST ONE FROM cut
#1
echo -e "1\n2\n3\n4"'' | tac | cut -zf-4 

WILL NOT DISPLAYED ONE LINE 

and any command with "cut" make  this not 


THIS IS TEST TWO FROM cut 
#2
second picture in attachment 
the sign asterisk in a file  for the "cut" byte options start print the actually directory with filenames

c14 source for start "cut" and Dir /awk 
 



THIS TEST printing THE ERR from 
COMMAND printf with  "$@" 
 
in the second picture is displayed 
whats wrong 
you see it the difference all printf calls with "$@"



#3
#$ . hashmark 1 2

fname(){
         declare local IFS='#'
         echo "var IFS local #1 $1 $2 , \$# $# , \$* $* , \$@ $@"
         }

fname $1 $2
echo
printf "%s%s%s%s%s%s%s%s\n"'var IFS global #2 '"$1 $2"' , $# '"$#"' , $* '"$*"' , $@ '"$@"
echo
printf "\n%s%s"\$@ $@
echo
printf '$@'"%s"$@
echo
printf "%s%s"'$@ '$@
echo
printf "%s" $@
echo
printf "%s"$@
echo
printf "%s %s" "\$@" " $@ "
echo

[040320251440.jpg (image/jpeg, attachment)]

[060320250319.jpg (image/jpeg, attachment)]

Message #8 received at 76768 <at> debbugs.gnu.org (full text, mbox):

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: "G.K." <kreutzgoran <at> gmail.com>, 76768 <at> debbugs.gnu.org
Subject: Re: bug#76768: BUGGY! "cut" AND "printf" in func arg >> $@
Date: Thu, 6 Mar 2025 08:27:21 +0100

tag 76768 notabug
close 76768
stop

On 3/6/25 03:46, G.K. wrote:
> #1
> echo -e "1\n2\n3\n4"'' | tac | cut -zf-4

First of all, let's simplify the test case: change non-portable 'echo -e' to printf,
and avoiding tac(1).

  $ echo -e '1\n2\n3\n4' | tac | od -tx1z
  0000000 34 0a 33 0a 32 0a 31 0a                          >4.3.2.1.<

  $ printf '4\n3\n2\n1\n' | od -tx1z
  0000000 34 0a 33 0a 32 0a 31 0a                          >4.3.2.1.<

Now, the test case is:

  $ printf '4\n3\n2\n1\n' | cut -zf-4

> WILL NOT DISPLAYED ONE LINE

Sorry, I do not understand what the expected outcome is.

While -z tells cut(1) to use zero-terminated input, still the
delimiter between fields is a tab.
Since there is no '\0' in the input, all of the input is row one.
As the row does not contain any tab, there is only one field,
written as string: '4\n3\n2\n1\n'.

Therefore -f-4 meaning "print all fields up to field 4" just does that,
although there only field 1, but no fields 2 to 4.

The following input with a tab as delimiter between the fields illustrates
that only "up to 4 fields" are output:

  $ printf 'a\tb\tc\td\te' | cut -zf-4
  a	b	c	d

As such, I don't see a bug in cut(1), but rather a confusion about how
the field delimiter works.

> THIS IS TEST TWO FROM cut
> #2
> second picture in attachment

Screenshots are not a good way to show reproducers, because one would have
to type manually to reproduce.  That is prone to errors.
Most readers might not even attempt to open attachments.

> the sign asterisk in a file  for the "cut" byte options start print the actually directory with filenames
>
> c14 source for start "cut" and Dir /awk

The problem is in the line
  echo ${svn[$i]}
where the unquoted ${svn[$i]} resolves to an *, and therefore the shell performs the
glob expansion before passing the result of that - i.e. all file names in the current
directory - to the echo builtin.

Therefore this is a matter of proper quoting, and not a problem in cut(1).

> THIS TEST printing THE ERR from
> COMMAND printf with  "$@"
>
> in the second picture is displayed
> whats wrong
> you see it the difference all printf calls with "$@"
>
>
>
> #3
> #$ . hashmark 1 2
>
> fname(){
>           declare local IFS='#'
>           echo "var IFS local #1 $1 $2 , \$# $# , \$* $* , \$@ $@"
>           }
>
> fname $1 $2
> echo
> printf "%s%s%s%s%s%s%s%s\n"'var IFS global #2 '"$1 $2"' , $# '"$#"' , $* '"$*"' , $@ '"$@"
> echo
> printf "\n%s%s"\$@ $@
> echo
> printf '$@'"%s"$@
> echo
> printf "%s%s"'$@ '$@
> echo
> printf "%s" $@
> echo
> printf "%s"$@
> echo
> printf "%s %s" "\$@" " $@ "
> echo

Sorry, also here I'm quite lost what you wan to achieve, but most probably this
is also a problem of missing or wrong quotes.  Just start with this to list
all parameters correctly which have been passed to the shell script:

  printf "var='%s'\n" "$@"

Again, this is rather a shell topic and no problem with the GNU coreutils.
Hence, I'm closing this as "notabug" in our bug tracker.

Have a nice day,
Berny

Message #15 received at 76768 <at> debbugs.gnu.org (full text, mbox):

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: "G. K." <kreutzgoran <at> gmail.com>, 76768 <at> debbugs.gnu.org
Subject: Re: bug#76768: BUGGY! "cut" AND "printf" in func arg >> $@
Date: Fri, 7 Mar 2025 08:51:14 +0100

[re-adding the list]

On 3/6/25 15:32, G. K. wrote:
> hi bernhard voelker/berny,
>
> an explanation in connection with the "cut" program for displaying the files in the current directory, I had to
> specifically exclude that in your answer.
>
> you said that the problem could be the quotation marks that are missing for the echo, I had commented out this
> instruction completely.
> the listing of files in the workdir remained.
>
> for testing with the c14 program.
> the "cut" command is solely for the variable as an array via the "for" loop and is re-instructed each time with the counter.
>
>   TEST PROGRAM
>
> declare -a local svn='' echo -n '------*' > 1234567 for i in `seq 7` do svn[$i]=`cut -b$i 1234567` # # echo ${svn[$i]} done

This one is messed up.  I don't know what email program you are using, but that
effectively kills proper syntax.  Please fix this.

This is probably what it should look like:

  $ cat x
  #!/bin/bash
  declare -a local svn=''
  echo -n '------*' > 1234567
  for i in `seq 7`
  do
      svn[$i]=`cut -b$i 1234567`
      # # echo ${svn[$i]}
  done

Now, let's run it with the debug flag -x:

  $ bash -x ./x
  + declare -a local svn=
  + echo -n '------*'
  ++ seq 7
  + for i in `seq 7`
  ++ cut -b1 1234567
  + svn[$i]=-
  + for i in `seq 7`
  ++ cut -b2 1234567
  + svn[$i]=-
  + for i in `seq 7`
  ++ cut -b3 1234567
  + svn[$i]=-
  + for i in `seq 7`
  ++ cut -b4 1234567
  + svn[$i]=-
  + for i in `seq 7`
  ++ cut -b5 1234567
  + svn[$i]=-
  + for i in `seq 7`
  ++ cut -b6 1234567
  + svn[$i]=-
  + for i in `seq 7`
  ++ cut -b7 1234567
  + svn[$i]='*'

In the last line, we see the proof that the output of 'cut -b7' is a literal '*',
which then gets assigned to the svn array element.

If you un-comment the echo, then you'll see that the shell will expand the unquoted * to all
files in the current directory and pass it to echo which in turn outputs their names.

  ...
  ++ cut -b7 1234567
  + svn[$i]='*'
  + echo 1234567 fileA fileB fileC x
  1234567 fileA fileB fileC x

With proper quoting ...

  echo "${svn[$i]}"

... it would instead output a literal '*' again.

  ++ cut -b7 1234567
  + svn[$i]='*'
  + echo '*'
  *

> in general, no error can be seen in all the help and examples relating to variables and their arrays.
>
> the contents of a new file are inserted using the "echo" program.
>
> an asterisk is the last character of seven.
>
> in the sequenced "for" loop, "cut" is added to the index with the sequence statement as a counter for the byte in the
> array of the variable.
>
> from this perspective, there is no asterisk or list of files in index seven of the array of the variable. the "cut"
> program generates the display itself and takes over. this confirms that the variable is empty with an output via the
> array index.

no, see above.

> the program command as an instruction in the input prompt
>
> with "cut -b7 1234567" displays the asterisk from the file '1234567' without any problems.
>
> the error that I believe can be identified can only be seen between the two, that of executing "cut" within the indexed
> array variable and in the entry for this.
>
> what is wrong with the fact that an entire work directory and all the files in it are listed with an asterisk when
> reading the file?
>
> in comparison, shell instructions and programs like "ls" are necessary. that is more like foreign and suspicious to me.
>
> then have a nice day

Again, this is no issue with any of the GNU coreutils, and I'd say not even an issue
with the shell being used, but simply a misunderstanding on how quoting has to be
used in shell syntax.

Have a nice day,
Berny

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.