Re: segfault evaluating [[ $@ ]] when IFS is \t or \n and $1 == $IFS
On 4/4/17 7:54 PM, Grisha Levit wrote:
> Given:
>
> set -- $'\t'; IFS=$1 A=$1 # or set -- $'\n'
>
> These all segfault (in different places with -DDEBUG)
>
> : ${x-$@}
> [[ $@ ]]
> : ${x-${A[@]}}
> [[ ${A[@]} ]]
Thanks for the report. This was a little bit tricker to fix than I thought
it would be.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: splitting/whitespace in expansions of ${*} vs ${*/}
On 4/4/17 3:29 PM, Grisha Levit wrote:
> There are a few small regressions in the latest devel relative to the
> previous two commits but they're all rather exotic. Again, sorry if this
> is still WIP/too minor:
>
> CTLESC present in output (even with default IFS)
>
>$ set -- 1; unset var; printf ${var-${*:1}} | xxd
>: 0131 .1
>
>$ set -- 1; unset var; : ${var=${*:1}}; printf "$var" | xxd
>: 0131 .1
>
> Not splitting (with default IFS):
>
>$ set -- '1 1'; unset a b; printf '<%s>' ${a=$*} ${b=${*:1}}
><1><1><1 1>
Thanks, these are fixed.
>
> A few more cases below:
I'll look at these.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: while loop with extdebug + debug trap always returning 1
On 4/4/17 5:08 PM, nesro wrote: > > To have both commands similar, let's assume the while as this: > > while (( 1 > 2 )); do :; done > > Thanks for explaining me why it happen, but now I don't know why for cycle > works and while does not. When extdebug is enabled, the command is skipped if the DEBUG trap returns non-zero. This doesn't change $? (traps never do) and it doesn't cause the command that would have been run to return a non-zero exit status. If it did, the combination of DEBUG and `set -e' would exit the shell, for example, and I'm sure it would not behave as the bash debugger would expect. For that matter, why should a command that's not run fail? Since that command returns successfully, when it's used as the `while' command test, it causes the while command to execute forever. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: bash 4.4 null byte warning!!
On 4/6/17 3:47 AM, emlyn.j...@wipro.com wrote: > Hi, > > > > We are trying to use the bash 4.4 downloaded from > http://ftp.gnu.org/gnu/bash/ on our RHEL 6.2 machine. > > But while using a script that has this command : > > FIND_RPM=`find /opt/RPM/components -type d -name enum-1.1.6-print0` > > It throws a warning as below: > > bash:warning:command substitution:ignored null byte ininput Yes. It drops the null bytes because C strings can't handle them. I received bug reports asking why bash silently transforms the command substitution output and added the warning while not changing the behavior. If you want to suppress the warning, you'll have to edit the source and rebuild. This does beg the question of why you're using -print0 without something on the receiving end to handle the null bytes. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
