On Tue, 27 Jun 2023 21:52:53 +0200 of1 <o...@disroot.org> wrote: > On 27/06/2023 21:05, Kerin Millar wrote: > > It doesn't work at all for >=5.2. The reason for this is interesting and I > > may make a separate post about it. > > > > Prior to 5.2, it can easily be tricked into printing names that do not > > exist. > > > > $ VAR=$'\nNONEXISTENT=' ./declare-P | grep ^NONEXISTENT > > NONEXISTENT > > > Thank you. I was just reading the discussion in Gentoo forum and > realizing that I've been to quickly: it doesn't pass the > FOO=$'\nBAR BAZ QUUX=' test. But what about this? (I also quickly > tested with Bash 5.2.15). > > > FOO=$'\nBAR BAZ QUUX=' > VAR=$'\nNONEXISTENT=' > > declare-P() { > local curVar > declare -a curVars > > readarray -t curVars <<<"$1" > curVars=( "${curVars[@]%%=*}" ) > curVars=( "${curVars[@]##* }" ) > for curVar in "${curVars[@]}"; do > ### we can use [[ -v "$curVar" ]] at some point! > [[ "${curVar//[a-zA-Z0-9_]}" || \ > "${curVar:0:1}" == [0-9] || \ > ! -v "$curVar" || \ > ! "$curVar" =~ $2 ]] || printf '%s\n' "$curVar" > done > } > > declare-P "$(declare -p)" > echo "##################" > declare-P "$(declare -p)" "QU|^NON|VAR"r >
This use of test -v is probably sufficient to address that particular issue. It is just as well that the test occurs after determining that the string is a valid identifier because test -v has the power to facilitate arbitrary code execution. My assertion that your code is broken in 5.2 was incorrect. Rather, the problem seems to be that regcomp(3) behaviour differs across platforms, where given an empty expression to compile. To address that, you could determine whether a second positional parameter was given and is non-empty before proceeding to use it. Curiously, repeated invocation may lead to obvious issues of resource consumption. # This is excruciatingly expensive time for i in {1..100}; do declare-P "$(declare -p)" done # This is not so expensive (!) time for i in {1..100}; do declare-P "$(declare -p)" : done At present, I do not have a concrete explanation as to why this is, though it may well have something to do with the value of the _ parameter. Suffice to say that I'll be sticking to multiple ${!prefix*} expansions until such time as bash offers a better way of going about it that doesn't also require readline. -- Kerin Millar