Re: Bug with bash 4.3
On 3/5/14 5:01 PM, Albert Shih wrote:
> If you got a file name begin with "(" the completion didn't work.
>
> For example if I do
>
> mkdir emptydir
> cd emptydir
> touch \(\)
> rm + Tab
>
> don't give me anything.
This is actually a general problem with empty completions (typing TAB at
the end of a line) in general with bash-4.3 and the latest versions of the
bash-completion package.
The problem, as it usually is, is mismatched assumptions. There was a
change between bash-4.2 and bash-4.3 prompted by this message thread
from 2011 (!):
http://lists.gnu.org/archive/html/bug-bash/2011-10/msg00059.html
The problem, in a nutshell, was that complete and compgen need to act
differently based on how they are invoked: from the command line for
testing, and from within readline's completion engine. When invoked on
the command line, the arguments are run through the usual word
expansions; when run via the programmable completion code, they are not.
That has implications for quoted words, and the bash-completion package
assumes that the programmable completion code unconditionally dequotes
all words passed to complete and compgen that are supposed to be treated
as filenames (as the bash-4.2 code did).
Here is a message describing what I ultimately put into bash-4.3:
http://lists.gnu.org/archive/html/bug-bash/2011-10/msg00068.html
This works, as far as it goes, but the problem with it is that it missed
this particular case. When the original word doesn't have quotes (so
readline doesn't find any quotes and doesn't set the flag indicating that),
but the argument passed to compgen has quotes and therefore needs
dequoting, the bash-4.3 code doesn't dequote it. The bash-4.2 code, since
it dequoted unconditionally, doesn't have this problem.
I've attached a patch that solves the problem with "empty" completions.
It's a start, but it may require more work to capture all of the cases.
(Frankly, I'm disappointed that this slipped through into bash-4.3. The
change was made back in 2011, and has been in the devel tree since early
2012. Bash-4.3 testing versions were available for almost a year.)
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-4.3/pcomplete.c 2013-08-26 15:23:45.0 -0400
--- pcomplete.c 2014-03-07 13:12:42.0 -0500
***
*** 184,187
--- 184,188
COMPSPEC *pcomp_curcs;
const char *pcomp_curcmd;
+ const char *pcomp_curtxt;
#ifdef DEBUG
***
*** 754,757
--- 755,767
dfn = (*rl_filename_dequoting_function) ((char *)text, rl_completion_quote_character);
}
+ /* Intended to solve a mismatched assumption by bash-completion. If
+ the text to be completed is empty, but bash-completion turns it into
+ a quoted string ('') assuming that this code will dequote it before
+ calling readline, do the dequoting. */
+ else if (iscompgen && iscompleting &&
+ pcomp_curtxt && *pcomp_curtxt == 0 &&
+ text && (*text == '\'' || *text == '"') && text[1] == text[0] && text[2] == 0 &&
+ rl_filename_dequoting_function)
+ dfn = (*rl_filename_dequoting_function) ((char *)text, rl_completion_quote_character);
else
dfn = savestring (text);
***
*** 1523,1527
{
COMPSPEC *cs, *oldcs;
! const char *oldcmd;
STRINGLIST *ret;
--- 1533,1537
{
COMPSPEC *cs, *oldcs;
! const char *oldcmd, *oldtxt;
STRINGLIST *ret;
***
*** 1546,1552
--- 1556,1564
oldcs = pcomp_curcs;
oldcmd = pcomp_curcmd;
+ oldtxt = pcomp_curtxt;
pcomp_curcs = cs;
pcomp_curcmd = cmd;
+ pcomp_curtxt = word;
ret = gen_compspec_completions (cs, cmd, word, start, end, foundp);
***
*** 1554,1557
--- 1566,1570
pcomp_curcs = oldcs;
pcomp_curcmd = oldcmd;
+ pcomp_curtxt = oldtxt;
/* We need to conditionally handle setting *retryp here */
Executing 'return' inside RETURN trap causes function to recurse infinitely
WARNING: the codes given below cause the shell to enter an infinite
loop.
Both:
dualbus@debian:~$ bash -Tc 'f(){ :; }; trap return RETURN; f'
^C
and:
dualbus@debian:~$ bash -c 'f(){ trap return RETURN; }; f'
^C
Cause the function call to recurse infinitely. I would understand if
this is labeled as a feature, rather than a bug (in the sense that
the user shouldn't be putting return inside a return trap :), so one
can safely assume that if they did it, it's because they wanted the
infinite recursion).
Though, I think the following 2 approaches would be better/more
consistent.
(1) treat the execution of return inside a RETURN trap as an error,
like when 'return' is called outside a function/sourced script.
(2) treat return specially when it's executed inside a return trap,
making it return immediately from the trap.
dualbus@debian:~$ bash --version
GNU bash, version 4.3.0(1)-rc2 (x86_64-unknown-linux-gnu)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
--
Eduardo Alan Bustamante López
Re: Executing 'return' inside RETURN trap causes function to recurse infinitely
On Fri, Mar 07, 2014 at 11:38:21AM -0800, Eduardo A. Bustamante López wrote:
> WARNING: the codes given below cause the shell to enter an infinite
> loop.
>
>
> Both:
> dualbus@debian:~$ bash -Tc 'f(){ :; }; trap return RETURN; f'
> ^C
>
> and:
> dualbus@debian:~$ bash -c 'f(){ trap return RETURN; }; f'
> ^C
>
> Cause the function call to recurse infinitely. I would understand if
By the way, I forgot to add the reason why I found this. POSIX states
the following:
| EXIT STATUS
|
| The value of the special parameter '?' shall be set to n, an unsigned
| decimal integer, or to the exit status of the last command executed
| if n is not specified. If the value of n is greater than 255, the
| results are undefined. When return is executed in a trap action, the
| last command is considered to be the command that executed
| immediately preceding the trap action.
Reference:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_24
The interesting bit is 'when return is executed in a trap action,
...'. So I wanted to test that, and the easiest way I thought I could
verify if that matched, was to execute return in a RETURN trap. It's
worth noting that using --posix does not affect the outcome.
--
Eduardo Alan Bustamante López
Re: readline 6.3 bug report
On 3/7/14 2:25 AM, Daan van Rossum wrote: > Hi Chet, > > Readline 6.3 has a new bug in vi-mode: > the "." command does no longer redo the latest "dw", "dl", "D", ... commands. > > Reverting back to version 6.2 fixed the issue for me. Thanks for the report. It's the result of an overzealous attempt to keep the arrow keys from setting vi mode's idea of the last command. Here's a patch to bash-4.3 that should work; you can apply it to readline-6.3 with the right options to patch. 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-4.3/lib/readline/readline.c 2013-10-28 14:58:06.0 -0400 --- lib/readline/readline.c 2014-03-07 15:20:33.0 -0500 *** *** 965,969 if (rl_editing_mode == vi_mode && _rl_keymap == vi_movement_keymap && key != ANYOTHERKEY && ! rl_key_sequence_length == 1 && /* XXX */ _rl_vi_textmod_command (key)) _rl_vi_set_last (key, rl_numeric_arg, rl_arg_sign); --- 965,969 if (rl_editing_mode == vi_mode && _rl_keymap == vi_movement_keymap && key != ANYOTHERKEY && ! _rl_dispatching_keymap == vi_movement_keymap && _rl_vi_textmod_command (key)) _rl_vi_set_last (key, rl_numeric_arg, rl_arg_sign);
C-style escapes within substitution expansion
Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -g -O2
uname output: Linux perseus 3.0.0-1 #1 Thu Aug 11 12:53:44 BST 2011
i686 GNU/Linux
Machine Type: i686-pc-linux-gnu
Bash Version: 4.3
Patch Level: 0
Release Status: release
Description:
When invoked as sh, bash 4.3.0 doesn't interpret C-style escapes
within double-quoted substitution expansions ("${var/$'what'/ever}").
Repeat-By:
bash -c "a=-@- ; echo \${a/\$'\\x40'/+} ; echo \"\${a/\$'\\x40'/+}\""
-+-
-+-
sh -c "a=-@- ; echo \${a/\$'\\x40'/+} ; echo \"\${a/\$'\\x40'/+}\""
-+-
-@-
pattern substitution expands "~" even in quoted variables
Configuration Information
[Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: x86_64-pc-linux-gnu-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./include -I. -I./include -I./lib
-DDEFAULT_PATH_VALUE='/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'
-DSTANDARD_UTILS_PATH='/bin:/usr/bin:/sbin:/usr/sbin'
-DSYS_BASHRC='/etc/bash/bashrc' -DSYS_BASH_LOGOUT='/etc/bash/bash_logout'
-DNON_INTERACTIVE_LOGIN_SHELLS -DSSH_SOURCE_BASHRC -march=barcelona
-mtune=barcelona -O2 -pipe
uname output: Linux shanghai 3.12.13 #2 SMP PREEMPT Wed Mar 5 17:26:09 CET 2014
x86_64 Quad-Core AMD Opteron(tm) Processor 2389 AuthenticAMD GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 4.3
Patch Level: 0
Release Status: release
Description:
bash-4.3 seems to expand a "~" (tilde character) with full homepath in a
pattern substitution even when the variable is embraced by double quotes.
Repeat-By:
replace_with_tilde() { P="foo_bar" ; echo ${P/_/~} ; echo "${P/_/~}" ; }
bash-4.2.45:
~% replace_with_tilde
foo/home/polynomial-cbar
foo~bar
bash-4.3.0:
~% replace_with_tilde
foo/home/polynomial-cbar
foo/home/polynomial-cbar
signature.asc
Description: PGP signature
Re: pattern substitution expands "~" even in quoted variables
On Fri, Mar 07, 2014 at 05:21:53PM +0100, Lars Wendler wrote:
> Configuration Information
> [Automatically generated, do not change]:
> Machine: x86_64
> OS: linux-gnu
> Compiler: x86_64-pc-linux-gnu-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./include -I. -I./include -I./lib
> -DDEFAULT_PATH_VALUE='/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'
> -DSTANDARD_UTILS_PATH='/bin:/usr/bin:/sbin:/usr/sbin'
> -DSYS_BASHRC='/etc/bash/bashrc' -DSYS_BASH_LOGOUT='/etc/bash/bash_logout'
> -DNON_INTERACTIVE_LOGIN_SHELLS -DSSH_SOURCE_BASHRC -march=barcelona
> -mtune=barcelona -O2 -pipe
> uname output: Linux shanghai 3.12.13 #2 SMP PREEMPT Wed Mar 5 17:26:09 CET
> 2014 x86_64 Quad-Core AMD Opteron(tm) Processor 2389 AuthenticAMD GNU/Linux
> Machine Type: x86_64-pc-linux-gnu
>
> Bash Version: 4.3
> Patch Level: 0
> Release Status: release
>
> Description:
>
> bash-4.3 seems to expand a "~" (tilde character) with full homepath in a
> pattern substitution even when the variable is embraced by double quotes.
>
> Repeat-By:
>
> replace_with_tilde() { P="foo_bar" ; echo ${P/_/~} ; echo "${P/_/~}" ; }
>
>
> bash-4.2.45:
>
> ~% replace_with_tilde
> foo/home/polynomial-cbar
> foo~bar
>
>
> bash-4.3.0:
>
> ~% replace_with_tilde
> foo/home/polynomial-cbar
> foo/home/polynomial-cbar
(1) You're not quoting it right:
dualbus@debian:~$ for shell in /bin/bash ~/local/bin/bash; do "$shell" -c
'p=foo_bar; echo "${p/_/\~} $BASH_VERSION"'; done
foo\~bar 4.2.37(1)-release
foo~bar 4.3.0(2)-release
(2) In fact, this change in 4.3 is a fix to an old (and a bit weird)
behavior, see:
- http://lists.gnu.org/archive/html/bug-bash/2012-02/msg00106.html
- http://lists.gnu.org/archive/html/bug-bash/2013-03/msg00099.html
If you want the old behavior:
dualbus@debian:~$ ~/local/bin/bash -c 'shopt -s compat42; p=foo_bar; echo
"${p/_/\~} $BASH_VERSION"'
foo\~bar 4.3.0(2)-release
--
Eduardo Alan Bustamante López
Re: pattern substitution expands "~" even in quoted variables
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 3/7/14, 11:21 AM, Lars Wendler wrote: > Bash Version: 4.3 > Patch Level: 0 > Release Status: release > > Description: > > bash-4.3 seems to expand a "~" (tilde character) with full homepath in a > pattern substitution even when the variable is embraced by double quotes. Yes, this is a fix for a bug in bash-4.2. Eduardo's excellent explanation provides more detail. ksh93 behaves the same as bash-4.3, FWIW. 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/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMaaYYACgkQu1hp8GTqdKv/wACdEmh6RxfsHOxN8IwQ8EV7XRJB pT8AmwaOD6sUaJpC3d8sD+4GUtMjuSy+ =inIq -END PGP SIGNATURE-
Re: C-style escapes within substitution expansion
On 3/7/14, 2:42 PM, David Sines wrote:
> Bash Version: 4.3
> Patch Level: 0
> Release Status: release
>
> Description:
> When invoked as sh, bash 4.3.0 doesn't interpret C-style escapes
> within double-quoted substitution expansions ("${var/$'what'/ever}").
I think this is a bug; this is the wrong place for posix-mode treatment of
single quotes inside double-quoted word expansions. Here's a patch that
makes posix mode behave like the default in this case.
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-4.3/parse.y 2014-02-11 09:42:10.0 -0500
--- parse.y 2014-03-07 20:57:15.0 -0500
***
*** 3399,3403
unescaped double-quotes or single-quotes, if any, shall occur." */
/* This was changed in Austin Group Interp 221 */
! if MBTEST(posixly_correct && shell_compatibility_level > 41 && dolbrace_state != DOLBRACE_QUOTE && (flags & P_DQUOTE) && (flags & P_DOLBRACE) && ch == '\'')
continue;
--- 3399,3403
unescaped double-quotes or single-quotes, if any, shall occur." */
/* This was changed in Austin Group Interp 221 */
! if MBTEST(posixly_correct && shell_compatibility_level > 41 && dolbrace_state != DOLBRACE_QUOTE && dolbrace_state != DOLBRACE_QUOTE2 && (flags & P_DQUOTE) && (flags & P_DOLBRACE) && ch == '\'')
continue;
