zopen-config consumes calling shell scripts parameters, unless it is passed its own

[BarryLz]

Description

Sourcing files under the shell (effectively treating as 'included' inline by the caller) has the unsurprising effect of seeing the parameters of the calling shell script. I believe the problem is in the snippet following, due to the use of shift. When my calling shell script is passed parameters, this causes those meant for my shell script to be consumed and upon 'return' there are none for my shell script to process (e.g. $1, $2, etc).

Because zopen-config does not complain about unrecognized parameters I get no indication of a problem.

https://github.com/zopencommunity/meta/blob/main/include/common.sh , and the code in question is this:
while [ $# -gt 0 ]; do
  case "$1" in
    --eknv) exportknv="export "; knv=true;;
    --knv) knv=true;;
    --override-zos-tools)  export ZOPEN_TOOLSET_OVERRIDE=1;;
    --nooverride-zos-tools)  unset ZOPEN_TOOLSET_OVERRIDE;;
    --override-zos-tools-subset) shift;  export ZOPEN_TOOLSET_OVERRIDE=1; overrideFile="$1";;
    --quiet) displayText=false;;
    -?|--help) displayHelp; return 0;;
  esac
  shift
done

I believe the problem can be avoided by putting the code which is parsing the arguments (doing shift) into a function, which has the effect of saving/restoring the original variables, and it seems new/changed/exported variables are still visible after the function is called.

---

Meanwhile an easy workaround for me was to pass any arguments to the sourced zopen-config, this has the effect of preserving the "callers" positional parameters. (This behavior was implemented for sourcing long ago so that even sourced scripts could be passed their own parameters -- but when no parameters are passed the original behavior that I described above is retained for those relying on it.)

So secondarily there is this problem when I first tried my workaround. I thought passing "--" would be OK since zopen-config appears to not care about unrecognized parameters; alas the last case statement testing "-?" is actually a pattern so matches "--". So for now I'm passing just "-" (I could use --quiet if I really needed to).

It would be nice if a future change expressly allow "--" as it is often used to mean "no more options after this", and as well -? should be appropriately escaped to avoid unintentionally matching (I think both -\? and '-?' would work).

---

Lastly a question -- Is zopen-config documented to be /bin/sh shell compatible? In case I happened to be running bash when I sourced this, is that tested & supported?

I also noticed that zopen-config is coded with shebang #!/bin/false, which is clever to avoid not being sourced, but can be a challenge to know that nothing was done since there's no message. So long as the script file intended to be source does not turn on the +x (execute) permissions, it can only be sourced as it will fail if attempted to actually run it. (I have a different approach which is to do this test: if [ $(basename "$0") = "<my_program_filename>" ]; then # should only happen if not sourced... which requires the program is always named <my_program_filename> (I avoid using a variable for this value since any variables set could clobber those in a calling shell script).

Severity

Sev 4 - Low

Expected Behavior

xopen-config should leave alone the calling shell scripts parms, and all variables or functions intact except those expressly meant to be visible after execution of the sourced shell script.

Actual Behavior

Consumes parameters. I've not checked if any variables or functions are visible after the sourced shell script completes, but they ought to be protected so as to be local only to xopen-config.

z/OS Version

OS/390 SA0W 27.00 04 8561

zopen package manager version

2025/03/13 21:08:08 CUT v1.3.5.0 bcb459b6 7509 PH64192 1385 36baca08

Additional Information (Optional)

Making severity low since I do have a workaround and presumably nobody else has hit these problems.

Note that I could not do zopen --version as indicated above, but instead did zoaversion.

Network or Security Configuration (Optional)

No response