Found problem mentioned in email 3/27: path interpretted/eval'd as numeric expression

[Linda Walsh]

I'm leaning toward the side of this not being a bug, BUT is it really
this way??  Really seems a buried "gotcha" and maybe behavior should be
reconsidered if this is desirable.

I have a function "include", that looks along my PATH for the file.

One might ask why shopt -s sourcepath doesn't work:
1) main reason: it only works for a flat directory structure
2) 2nd reason -- doesn't prevent multiple includes of same source (i.e.
   if you have nested includes a includes b & c, and b includes c..
   double calling).

Restriction: need to have the defining function to define the include in
a file called at the start of every script (in your BASH_ENV).
I couldn't figure out a way to be invoked out of a separate script the
1st time it was used and then be defined thereafter.


The problem was it wasn't working if it had to 'walk' PATH -- it worked
under certain conditions but when trying to test if the item had been
included, storing the path in a bash-hash, a path with 2 '/'s in it
would be evaled as a numeric expression.  Still not entirely sure why it
worked with items having only one '/' but not more... But the problem
was that the "type" of the HASH was getting lost and re-defaulting to an
array -- causing the numeric eval of the subscript.

You may remember I actually used  'declare -p' to print out the type
just before I executed the statement w/the hash, and IT printed out that
it was "still a hash".   To refresh memories, here's the function
.  it's one of multiple aliases/functions I include -- normally only
when running interactively, but have started running them all the time
due to their utility in scripts.


------
declare -A _INC
export _INC
function include {
  echo "include(0=$0,@=$@)"
  [[ -n $1 ]] || return 1
  local fnc="${1%.shh}.shh"
  [[ $PATH != ${_SPATH:-} || ${#_FPATH[@]} -lt 1 ]] && {
    unset _FPATH
    local -xa _FPATH=( $(IFS=:;echo $PATH) )
    export _SPATH=$PATH
  }
  typeset -Ag _INC     ##  new -- remind BASH of type of _INC
  if [[ -z ${_INC["${fnc:-}"]:-}  ]]; then
    local pw
    for pw in "${_FPATH[@]}"; do
      local fn="${pw%/}/${fnc}"
      if [[ -r $fn  ]]; then
        source "$fn"  || {
          local stat=$?
          echo "Error: include of \"$fnc\" did not return 0 status"
          return $stat
        }
        _INC["$fnc"]="$fn"
        return 0
      fi
    done
    echo "Cannot find \"$fnc\" in \"$PATH\"" >&2
    exit 2
  fi
}
export -f include
-------------------

The problem, was that _INC was declared once at the same
time the function was -- but it's value was lost
over any forks as hashes and arrays aren't currently
exportable.  (though why 'typedef -p _INC, printed
the "-A" attribute is a bit confusing... there may be
a bug in here yet...).

But basically the function was being exported and the HASH
didn't follow it.  When it was evaled.. it defaulted to
ARRAY, so putting in an extra definition inside
the function ensured proper interpretation.


But why it still printed out -A when I did the
earlier had typedef -p  there, instead of the redefine,
I'm not sure.


Maybe it is related to this type of thing:?

> declare -A foo=([one]=1 [two]=2) 
> ( typeset -p foo)                 
declare -A foo='([one]="1" [two]="2" )'

Theoretically, () is a separate process, yet foo seems
to still be a hash.


BTW, is it planned to implement exporting ARRAY and HASHES?

Sure would simplify some programs... ;-)