Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > gnu.bash.bug > #15447

ARGV[@] Not Always Populated

Show key headers only | View raw

*Configuration Information [Automatically generated, do not
change]:Machine: x86_64OS: linux-gnuCompiler: gccCompilation CFLAGS: -g -O2
-fdebug-prefix-map=/build/bash-LQgi2O/bash-5.0=. -f$uname output: Linux
amdubuntu 5.0.0-29-generic #31-Ubuntu SMP Thu Sep 12 13:05$Machine Type:
x86_64-pc-linux-gnuBash Version: 5.0Patch Level: 3Release Status: release*

A description of the bug behaviour.
If you don't access the ARGV array before you drop into a function, ARGV is
not populated.
E.g. If the script below is named test.bsh
If I run:
$> test.bsh arg1 arg1val arg2 arg2val arg3 arg3val
*I expect the following output: *
inside the options handler with i = 5, BASH_ARGV[5] is arg1, BASH_ARGV[] is
arg3val
inside the options handler with i = 4, BASH_ARGV[4] is arg1val, BASH_ARGV[]
is arg3val
inside the options handler with i = 3, BASH_ARGV[3] is arg2, BASH_ARGV[] is
arg3val
inside the options handler with i = 2, BASH_ARGV[2] is arg2val, BASH_ARGV[]
is arg3val
inside the options handler with i = 1, BASH_ARGV[1] is arg3, BASH_ARGV[] is
arg3val
inside the options handler with i = 0, BASH_ARGV[0] is arg3val, BASH_ARGV[]
is arg3val
Instead nothing is printed.
If you uncomment the echo at the top of the script then the printing is as
expected.
I realize the Bash Documentation states:
       BASH_ARGV
              An  array variable containing all of the parameters in the
current bash
              execution call stack.  The final parameter of the last
subroutine  call
              is  at the top of the stack; the first parameter of the
initial call is
              at the bottom.  When a subroutine is executed, the parameters
 supplied
              are  pushed  onto BASH_ARGV.  The shell sets BASH_ARGV only
when in ex‐
              tended debugging mode (see the description of the  extdebug
 option  to
              the shopt builtin below).  Setting extdebug after the shell
has started
              to execute a script, or
*referencing this variable when extdebug is  not              set, may
result in inconsistent values.*
Many people are using BASH_ARGV:
e.g.
https://stackoverflow.com/questions/2740906/how-to-access-command-line-arguments-of-the-caller-inside-a-function
If it's not too much trouble I think a lot of people would be glad if you
could make this work in a standardized way.

A short script or ‘recipe’ which exercises the bug and may be used to
reproduce it.

> #!/bin/bash
> ## If you uncomment the next line, command line args are printed;
> #echo "inside top version_ctl, args:${BASH_ARGV[@]}, #
> args:${#BASH_ARGV[@]} "
> function process_options() {
> local -i i=0
> local CURVAL=""
> local NEXTVAL=""
> for((i=$((${#BASH_ARGV[@]}-1));i>=0;i--)); do
>  CURVAL=${BASH_ARGV[${i}]}
>  NEXTVAL=${BASH_ARGV[$((${i}-1))]}
>  echo "inside the options handler with i = $i, BASH_ARGV[${i}] is
> ${BASH_ARGV[${i}]}, BASH_ARGV[${next_arg}] is ${BASH_ARGV[${next_arg}]} "
> done
> return ${RETURN_CODE}
> }
>
> process_options
> exit 0

Back to gnu.bash.bug | Previous | Next | Find similar | Unroll thread

Thread

ARGV[@] Not Always Populated Adam Danischewski <adam.danischewski@gmail.com> - 2019-10-01 18:33 -0400

csiph-web