Re: Nested calls to getopts incorrectly parses clustered options
Nobody else having issues with this?
It's still a case in bash 4.3.30
On 31/05/14 18:40, Øyvind Hvidsten wrote:
For a simple test:
$ f() { local OPTIND=1 OPTARG OPTERR opt; while getopts ":abcxyz" opt;
do echo "opt: $opt"; if [[ "$opt" = "y" ]]; then f -a -b -c; fi; done;
}; f -x -y -z
opt: x
opt: y
opt: a
opt: b
opt: c
opt: z
However, if the options are clustered:
$ f() { local OPTIND=1 OPTARG OPTERR opt; while getopts ":abcxyz" opt;
do echo "opt: $opt"; if [[ "$opt" = "y" ]]; then f -abc; fi; done; }; f
-xyz
opt: x
opt: y
opt: a
opt: b
opt: c
opt: x
opt: y
opt: a
opt: b
opt: c
opt: x
opt: y
opt: a
opt: b
opt: c
etc
It's important to note that this happens even if f() doesn't call
itself, but rather calls some other function that also uses getopts. The
clustering of the inner set of options (-abc) is also not important -
the internal index of $1 is reset to the beginning either way.
Whatever variable tracks the index within a single clustered set of
options should probably also be exposed as a shell variable so it can be
set as local to the function. Or it should be so implicitly.
Øyvind
Re: Nested calls to getopts incorrectly parses clustered options
On Wed, Jan 14, 2015 at 12:35 PM, Øyvind 'bolt' Hvidsten
wrote:
> Nobody else having issues with this?
> It's still a case in bash 4.3.30
>
>
> On 31/05/14 18:40, Øyvind Hvidsten wrote:
>
>> For a simple test:
>>
>> $ f() { local OPTIND=1 OPTARG OPTERR opt; while getopts ":abcxyz" opt;
>> do echo "opt: $opt"; if [[ "$opt" = "y" ]]; then f -a -b -c; fi; done;
>> }; f -x -y -z
>> opt: x
>> opt: y
>> opt: a
>> opt: b
>> opt: c
>> opt: z
>>
>> However, if the options are clustered:
>> $ f() { local OPTIND=1 OPTARG OPTERR opt; while getopts ":abcxyz" opt;
>> do echo "opt: $opt"; if [[ "$opt" = "y" ]]; then f -abc; fi; done; }; f
>> -xyz
>> opt: x
>> opt: y
>> opt: a
>> opt: b
>> opt: c
>> opt: x
>> opt: y
>> opt: a
>> opt: b
>> opt: c
>> opt: x
>> opt: y
>> opt: a
>> opt: b
>> opt: c
>> etc
>>
>> It's important to note that this happens even if f() doesn't call
>> itself, but rather calls some other function that also uses getopts. The
>> clustering of the inner set of options (-abc) is also not important -
>> the internal index of $1 is reset to the beginning either way.
>>
>> Whatever variable tracks the index within a single clustered set of
>> options should probably also be exposed as a shell variable so it can be
>> set as local to the function. Or it should be so implicitly.
>>
>>
>> Øyvind
>>
>>
>>
>
>
it has been reported before, I guess chet didn't manage to work around it
yet
http://lists.gnu.org/archive/html/bug-bash/2012-01/msg00044.html
CHLD traps run at the same time
I'm responsible for a couple of scripts at work, which have used a trap on CHLD to do some naive parallelisation, starting a new child process when an existing one ends. However, when run under bash 4.3.30, all CHLD traps run at the same time, so my script runs in chunks, rather than keeping a given amount of processes running at all times. I've been told I can rewrite it using wait -n instead, but I'm wondering if this is classified as a bug, or if it's intended to be that way going forwards. Here's a quick example of what happens (from shbot in #bash on freenode): 43# bash -c "echo \$BASH_VERSION; set -m; trap 'date' CHLD; sleep 1 & sleep 3" 4.3.30(1)-release [1]+ Donesleep 1 Wed Jan 14 10:58:33 UTC 2015 Wed Jan 14 10:58:33 UTC 2015 42# bash -c "echo \$BASH_VERSION; set -m; trap 'date' CHLD; sleep 1 & sleep 3" 4.2.53(1)-release Wed Jan 14 10:58:36 UTC 2015 Wed Jan 14 10:58:38 UTC 2015 [1]+ Donesleep 1
Re: Nested calls to getopts incorrectly parses clustered options
On 1/14/15 5:35 AM, Øyvind 'bolt' Hvidsten wrote: > Nobody else having issues with this? > It's still a case in bash 4.3.30 There is a change in the devel branch that makes local copies of OPTIND behave as you expect. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Tilde expansion differences between 4.3 and 4.2
reproducer:
cd ~
mkdir MYDIR
cd MYDIR
echo "${PWD/#$HOME/~}"
Result of echo in 4.3:
/home//MYDIR
Result of echo in 4.2:
~/MYDIR
Is tilde expansion in 4.3 supposed to happen? I don't see any mention in
4.3's compat file, apart from
point 20 which was already present in COMPAT files for older versions.
Does this excerpt from the man page...
"
In each of the cases below, word is subject to tilde expansion,
parameter expansion, command substitution, and arithmetic
expansion.
"
...apply to string in ${parameter/pattern/string} as well? It would make
sense, since the other expansions worked on "string" in previous versions.
Thanks,
Ondrej
Re: Tilde expansion differences between 4.3 and 4.2
On Wed, Jan 14, 2015 at 03:09:47PM +0100, Ondrej Oprala wrote:
> echo "${PWD/#$HOME/~}"
>
> Result of echo in 4.3:
> /home//MYDIR
imadev:~/tmp$ echo "$BASH_VERSION -- ${PWD/#$HOME/\~}"
4.3.30(5)-release -- ~/tmp
imadev:~/tmp$ bash-4.2 -c 'echo "$BASH_VERSION -- ${PWD/#$HOME/\~}"'
4.2.46(1)-release -- \~/tmp
imadev:~/tmp$ t="~"; echo "$BASH_VERSION -- ${PWD/#$HOME/$t}"
4.3.30(5)-release -- ~/tmp
imadev:~/tmp$ bash-4.2 -c 't="~"; echo "$BASH_VERSION -- ${PWD/#$HOME/$t}"'
4.2.46(1)-release -- ~/tmp
Tab completion breaks for tilde-paths with filenames containing space
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/lib -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wall uname output: Linux bb 3.2.60dr #1 SMP Fri Oct 3 14:41:46 EDT 2014 x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 4.2 Patch Level: 37 Release Status: release Description: Pathnames starting with tilde, combined with filenames containing space, only partially tab-complete. Repeat-By: $ cd $ mkdir a $ touch a/a\ a.txt a/a\ a.odt $ vi a/a [correctly completes to] $ vi a/a\ a. a a.ods a a.txt ^C $ vi ~/a/a [correctly completes to] $ vi ~/a/a\ a. [further tabs do nothing] $ vi ~/a/a\ a.t[still nothing]
Re: Tilde expansion differences between 4.3 and 4.2
See: - http://lists.gnu.org/archive/html/bug-bash/2014-10/msg00200.html - http://lists.gnu.org/archive/html/bug-bash/2014-04/msg00077.html - http://lists.gnu.org/archive/html/bug-bash/2014-10/msg00202.html
Re: Tab completion breaks for tilde-paths with filenames containing space
On Wed, Jan 14, 2015 at 09:33:31AM -0500, d...@evilpettingzoo.com wrote: [...] > Bash Version: 4.2 > Patch Level: 37 [dualbus@dualbus ~]$ mkdir a; >a/a\ a.txt [dualbus@dualbus ~]$ echo ~/a/a [completes] [dualbus@dualbus ~]$ echo ~/a/a\ a.txt /home/dualbus/a/a a.txt [dualbus@dualbus ~]$ echo ~/a/a\ a [completes] [dualbus@dualbus ~]$ echo ~/a/a\ a.txt /home/dualbus/a/a a.txt [dualbus@dualbus ~]$ echo $BASH_VERSION 4.2.37(1)-release Are you using any supplementary programs, like bash-completion?
Re: Tab completion breaks for tilde-paths with filenames containing space
On Wed, Jan 14, 2015 at 9:45 AM, Eduardo A. Bustamante López wrote: > On Wed, Jan 14, 2015 at 09:33:31AM -0500, d...@evilpettingzoo.com wrote: > [...] >> Bash Version: 4.2 >> Patch Level: 37 Also tested on 4.3.30 > [dualbus@dualbus ~]$ mkdir a; >a/a\ a.txt You didn't create any ambiguity there. It seems to be a partial requirement. > [dualbus@dualbus ~]$ echo ~/a/a [completes] > [dualbus@dualbus ~]$ echo ~/a/a\ a.txt > /home/dualbus/a/a a.txt > [dualbus@dualbus ~]$ echo ~/a/a\ a [completes] > [dualbus@dualbus ~]$ echo ~/a/a\ a.txt > /home/dualbus/a/a a.txt > > Are you using any supplementary programs, like bash-completion? I don't think so, unless Debian turned it on for me. Note that without a\ a.odt there, $ ls ~/a/a[completes to a\ a.txt] but $ ls ~/a/a\ [does not complete]
Re: Tilde expansion differences between 4.3 and 4.2
On 1/14/15 9:09 AM, Ondrej Oprala wrote:
> reproducer:
> cd ~
> mkdir MYDIR
> cd MYDIR
> echo "${PWD/#$HOME/~}"
>
> Result of echo in 4.3:
> /home//MYDIR
>
> Result of echo in 4.2:
> ~/MYDIR
>
> Is tilde expansion in 4.3 supposed to happen?
Yes. It's a Posix change.
Look at http://austingroupbugs.net/view.php?id=221, which reads, in part:
"For the four varieties of parameter expansion that provide for
substring processing (see [xref to 2.6.2 Parameter Expansion]),
within the string of characters from an enclosed "${" to the
matching '}', the double-quotes within which the expansion occurs
shall have no effect on the handling of any special characters."
which basically means that the outer quotes don't mean the stuff inside
the braces is quoted. This was part of a cleanup of the semantics of
quotes surrounding a parameter expansion and how those quotes affect
character handling inside the expansion.
Look at threads including
http://lists.gnu.org/archive/html/bug-bash/2014-10/msg00197.html
http://lists.gnu.org/archive/html/bug-bash/2014-03/msg00038.html
http://lists.gnu.org/archive/html/bug-bash/2014-04/msg00077.html
and go back from there.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Tab completion breaks for tilde-paths with filenames containing space
On Wed, Jan 14, 2015 at 09:55:33AM -0500, Dave Rutherford wrote: [...] > I don't think so, unless Debian turned it on for me. Can you test with: bash --norc --noprofile -i > Note that without a\ a.odt there, > $ ls ~/a/a[completes to a\ a.txt] > but > $ ls ~/a/a\ [does not complete] > [dualbus@dualbus ~]$ ls a a a.odt a a.txt [dualbus@dualbus ~]$ ls ~/a/a\ [completes to:] [dualbus@dualbus ~]$ ls ~/a/a\ a. if I do : [dualbus@dualbus ~]$ ls ~/a/a\ a. a a.odt a a.txt [dualbus@dualbus ~]$ ls ~/a/a\ a. So, it's working there.
Re: CHLD traps run at the same time
On 1/14/15 6:01 AM, Øyvind 'bolt' Hvidsten wrote: > I'm responsible for a couple of scripts at work, which have used a trap on > CHLD to do some naive parallelisation, starting a new child process when an > existing one ends. > > However, when run under bash 4.3.30, all CHLD traps run at the same time, > so my script runs in chunks, rather than keeping a given amount of > processes running at all times. I've been told I can rewrite it using wait > -n instead, but I'm wondering if this is classified as a bug, or if it's > intended to be that way going forwards. It's not a bug. The only guarantee is that the CHLD trap gets run once for each child bash reaps. Bash gets SIGCHLD, reaps as many terminated child processes as it can, then runs the CHLD trap once for each terminated child when it's no longer in a signal handler context. I don't have any plans to change this. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Tab completion breaks for tilde-paths with filenames containing space
On 1/14/15 9:33 AM, d...@evilpettingzoo.com wrote: > Bash Version: 4.2 > Patch Level: 37 > Release Status: release > > Description: > Pathnames starting with tilde, combined with filenames containing > space, only partially tab-complete. I can't reproduce this using bash-4.2.53 or bash-4.3.33, so I'm going to assume it's an artifact of bash-completion. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Tab completion breaks for tilde-paths with filenames containing space
Dave Rutherford writes: > On Wed, Jan 14, 2015 at 9:45 AM, Eduardo A. Bustamante López > wrote: >> Are you using any supplementary programs, like bash-completion? > > I don't think so, unless Debian turned it on for me. Run complete -p to find out. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Re: Tab completion breaks for tilde-paths with filenames containing space
On Wed, Jan 14, 2015 at 10:14 AM, Eduardo A. Bustamante López wrote: > Can you test with: > bash --norc --noprofile -i It is working in this case. The difference seems to be in direxpand. $ shopt -s direxpand; shopt direxpand direxpand on $ vi ~/a/a\ [nothing] $ shopt -u direxpand; shopt direxpand direxpand off $ vi ~/a/a\[expands to] $ vi ~/a/a\ a. a a.odt a a.txt Is this expected?
Re: [Bug-readline] incorrect "erase" of multibyte characters in "reverse-i-search" mode.
On 1/13/15 6:05 AM, Kyrylo Shpytsya wrote: > readline version: 6.3_p8 and the one in devel branch of bash > OS: gentoo linux "unstable", kernel 3.17, UTF-8 locale > To reproduce: > > in bash, press Ctrl-R to invoke reverse-i-search mode, enter any multi-byte > character (on US keyboard layout LAlt+1 seems to produce "±" which is multi > byte), press backspace. > > Expected behaviour: last character being erased. Actual behaviour: > apparently a single byte is erased instead, leaving an incorrect UTF-8 > character. Thanks for the report. This will be fixed in the next version of bash and readline. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
bash crashes when the REPLY variable is read only and the 'select' builtin is used.
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I../. -I.././include -I.././lib -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wall uname output: Linux larnica 3.13.0-43-generic #72-Ubuntu SMP Mon Dec 8 19:35:06 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 4.3 Patch Level: 11 Release Status: release Description: Using select after making the variable 'REPLY' readonly via 'readonly REPLY', bash will crash. Repeat-By: - snapshot starts - gabriel@larnica:~$ exec /usr/bin/env -i /bin/bash --norc bash-4.3$ readonly REPLY bash-4.3$ select TEST_VALUE in TEST_ITEM1 TEST_ITEM2 TEST_ITEM3; do echo "Result: $TEST_VALUE"; break; done 1) TEST_ITEM1 2) TEST_ITEM2 3) TEST_ITEM3 #? 1 bash: REPLY: readonly variable Warning: Program '/bin/bash' crashed. - snapshot finish -
Re: Tab completion breaks for tilde-paths with filenames containing space
On 1/14/15 10:52 AM, Dave Rutherford wrote: > On Wed, Jan 14, 2015 at 10:14 AM, Eduardo A. Bustamante López > wrote: >> Can you test with: >> bash --norc --noprofile -i > > It is working in this case. The difference seems to be in direxpand. Thanks, that was the key. This will be fixed in the next version of bash and readline. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: bash crashes when the REPLY variable is read only and the 'select' builtin is used.
On 1/14/15 1:10 PM, Etherial Raine wrote: > Bash Version: 4.3 > Patch Level: 11 > Release Status: release > > Description: > Using select after making the variable 'REPLY' readonly via > 'readonly REPLY', bash will crash. > > Repeat-By: > > - snapshot starts - > > gabriel@larnica:~$ exec /usr/bin/env -i /bin/bash --norc > bash-4.3$ readonly REPLY > bash-4.3$ select TEST_VALUE in TEST_ITEM1 TEST_ITEM2 TEST_ITEM3; do echo > "Result: $TEST_VALUE"; break; done > 1) TEST_ITEM1 > 2) TEST_ITEM2 > 3) TEST_ITEM3 > #? 1 > bash: REPLY: readonly variable > > > Warning: Program '/bin/bash' crashed. Thanks for the report. This will be fixed in the next release of bash. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
