New instances of Bash should ignore and reset BASH_ARGV0
This doesn't look right to me: # export BASH_ARGV0=fdsafasfas # bash # echo "$BASH_ARGV0|$0" fdsafasfas|fdsafasfas # echo $BASH_VERSION 5.2.0(1)-release -- konsolebox
Re: bash core dumps doing glob pattern on long string
@Oğuz A simple look at the core dump will suffice to convince you that the stack has overflowed. As Koichi stated, both ksh and bash do implement de 'simple' recursive approach. My question was only about the strategy that bash would follow, to converge with bash, i.e we can still both core dump, and if we decide not to then implement a common behavior.
Less detailed error for ENOENT from execve
Hi, I think the execute_cmd.c change here (https://git.savannah.gnu.org/cgit/bash.git/commit/?h=devel&id=1fff64acdc5709cdc213f0143f1b8169fdf68a39) made things worse, not better. I don’t know what the original report that prompted this change was though, but my impression is that the error became much less detailed. The problem with `ENOENT` error from `execve` is that it is ambiguous: it will be returned in the case when the executable does not exist _or_ when the requested interpreter does not exist. So, in the `else` branch there is this chunk of logic that disambiguates them and reports either “no such file” or “bad interpreter”. With this change, `ENOENT` now has its own branch and hence that disambiguation logic is never reached. (I might be wrong, I don’t have bash 5.2 available to test, this is purely based on my reading of the code.) Cheers, Kirill
Re: bash core dumps doing glob pattern on long string
2022年10月9日(日) 18:37 Oğuz : > I'm not familiar with how extended globs are implemented in either shell > but this doesn't look like something that'd involve recursion. For the particular pattern +(0), you might think it is possible to implement it without recursion, but the extglob engine needs to handle general patterns. Pattern matching that involves the `+' operator is non-deterministic and accepted by the non-deterministic finite automaton (NFA). An efficient implementation for the general patterns would be to emulate the DFA converted from the NFA, which requires some mathematical knowledge. An alternative naive implementation would be to directly handle the NFA by backtracking, where recursion can be used to accumulate the backtracking points. I haven't checked the actual implementations of bash and ksh, but I guess these are implemented in the latter approach. So I think option 4 would be to re-implement the engine by the DFA, though I'm not sure if it is straightforward to take account of the collating symbols [.x.] and equivalence classes [=x=] in the POSIX bracket expressions [...]..
Re: bash core dumps doing glob pattern on long string
9 Ekim 2022 Pazar tarihinde Phi Debian yazdı: > > $ [[ $(printf '%010d' 0) == +(0) ]] > > I see 3 way of fixing this > I'm not familiar with how extended globs are implemented in either shell but this doesn't look like something that'd involve recursion. -- Oğuz
bash core dumps doing glob pattern on long string
I was looking at a bug on ksh93 that is "core dumps doing glob pattern on long string" and it happen that bash suffer the same. $ [[ $(printf '%010d' 0) == +(0) ]] I see 3 way of fixing this 1) [[ string == pattern ]] is for glob pattern, so string should be limited to PATH_MAX, so an upfront string length on string could prevent to call the glob pattern recursive functions, and then avoid the core dump. 2) Since some may have abused the glob pattern with long string bigger then PATH_MAX but smaller than core dump, imposing a PATH_MAX limit may break some wrong scripts, so instead we could have a fix recursion deep level, as we do have for shell functions calling, this hopefully should allow wrong doing script with abused string length to continue to run, yet avoiding core dump when reaching the limit, i.e break the call path. 3) Implement a stack deep check in the recursion, when getting close to the end of stack break the function trail (like function too deep for recursive functions). A last possibility is 'do nothing', since most of the people/scripts that works, don't care. Yet, the core dump limit is not the same on between bash and ksh93 then making porting hazardous. If the bash team plan to fix it, I'd like to know which way, so we could make ksh93 behave the same, for 1) and 2) it would be the exact same limit, for 3) it would be depending on stack usage, would not be the same exact string length that would break, but it would breaks instead of core dumping. Cheers,
