complete -p does not quote function names correctly.
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -march=x86-64 -mtune=generic -O2 -pipe -fno-plt
-DDEFAULT_PATH_VALUE='/usr/local/sbin:/usr/local/bin:/usr/bin'
-DSTANDARD_UTILS_PATH='/usr/bin' -DSYS_BASHRC='/etc/bash.bashrc'
-DSYS_BASH_LOGOUT='/etc/bash.bash_logout'
-DNON_INTERACTIVE_LOGIN_SHELLS
uname output: Linux t420 5.15.40-1-lts #1 SMP Sun, 15 May 2022
19:07:59 + x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 5.1
Patch Level: 16
Release Status: release
Description:
bash allows declaring functions with a name that contains `*'.
In the output of `complete -p', those function names will not be
quoted which makes the output of `complete -p' output not safe
to pass to `eval' or output to a file that will be read by
`source'.
I think bash should quote the arguments to `-F' in the output of
`complete -p'.
Repeat-By:
bash-5.1$ a*x () { echo hi ;}
bash-5.1$ 'a*x'
hi
bash-5.1$ complete -W 'something something' -F 'a*x' hello
bash-5.1$ complete -p hello
complete -W 'something something' -F a*x hello
Re: complete -p does not quote function names correctly.
> Description:
> bash allows declaring functions with a name that contains `*'.
> In the output of `complete -p', those function names will not be
> quoted which makes the output of `complete -p' output not safe
> to pass to `eval' or output to a file that will be read by
> `source'.
>
> I think bash should quote the arguments to `-F' in the output of
> `complete -p'.
Can you try the devel branch? There has been a related fix about a year ago:
https://lists.gnu.org/archive/html/bug-bash/2021-06/msg00140.html
https://git.savannah.gnu.org/cgit/bash.git/commit/?h=devel&id=5a0e5b7b2862394cefccb919cddabf24f0ab4730
With the devel version, the commands you have provided produce the
following result:
$ bash-dev --norc
$ a*x () { echo hi ;}
$ complete -W 'something something' -F 'a*x' hello
$ complete -p hello
complete -W 'something something' -F 'a*x' hello
--
Koichi
UP does not invoke line history immediately
In rare cases, the following happens to me: when I press UP and then RET to execute the last command line, and the two presses are close enough in time, bash takes the UP key as input without invoking history, so it tries to execute something like '^[[A'. This is minor, but it seems a bug to me. It looks like bash not substituting the pressed key with history immediately. Am I correct? Andrea Monaco
Re: UP does not invoke line history immediately
Hi Andrea This would appear to be an issue with the readline library, rather than Bash itself. As you've noted that it's timing-sensitive, I'm wondering if it's related to bytes received immediately prior, so to investigate this would it be possible to run Bash inside a "script" session, until you encounter one of these events? This will need GNU script as it accepts extension options -I, -O, and -T; each of these takes an output filename argument, to record input, output, and timing, respectively. Immediately after one of these events occurs, run "stty -a" and "bind -p" so that the current settings are recorded in the output log; then exit the shell to close the script session. As there are some significant caveats, please read "man script" (or https://man7.org/linux/man-pages/man1/script.1.html) before doing this. -Martin On Sat, 21 May 2022, 01:16 Andrea Monaco, wrote: > > In rare cases, the following happens to me: when I press UP and then RET > to execute the last command line, and the two presses are close enough > in time, bash takes the UP key as input without invoking history, so it > tries to execute something like '^[[A'. > > This is minor, but it seems a bug to me. It looks like bash not > substituting the pressed key with history immediately. > > Am I correct? > > > > Andrea Monaco > >
[gnu.org #1838744] Bash Manual, 3.6.2 Redirecting Inputs, SUGGESTION
Hello Bash maintainers, Here is a challenging ticket. The requester complains about the association of "n" and "word" in "Redirecting Input" (image.png is a screenshot of this chapter with the examples emphasized): https://www.gnu.org/software/bash/manual/bash.html#Redirecting-Input I'm going to tell him there is no guarantee that this can be changed. For one thing, it would be difficult to find a letter that doesn't take an unwanted meaning when associated with "word". All the best, Thérèse Le Ven 20 Mai 2022 11:26:09, ecapofe...@gmail.com a écrit : > Hello. I know this is completely unintentional. And I know it's superficial > and very small, but...maybe it's a bad look to some. You might want to > think about changing the "n" variable name for these examples: > > [image: image.png] > > Evan Capoferri > ecapofe...@gmail.com > m: 773 474 6389
Re: [gnu.org #1838744] Bash Manual, 3.6.2 Redirecting Inputs, SUGGESTION
On Fri, May 20, 2022, at 2:06 PM, Therese Godefroy via RT wrote: > I'm going to tell him there is no guarantee that this can be changed. > For one thing, it would be difficult to find a letter that doesn't > take an unwanted meaning when associated with "word". Perhaps something like "num" or "fd" could be used -- much like "varname" earlier in the same section. These would also have the benefit of being marginally more self-explanatory. -- vq
Re: [gnu.org #1838744] Bash Manual, 3.6.2 Redirecting Inputs, SUGGESTION
On Fri, May 20, 2022, at 7:01 PM, Lawrence Velázquez wrote: > On Fri, May 20, 2022, at 2:06 PM, Therese Godefroy via RT wrote: >> I'm going to tell him there is no guarantee that this can be changed. >> For one thing, it would be difficult to find a letter that doesn't >> take an unwanted meaning when associated with "word". > > Perhaps something like "num" or "fd" could be used Or even "fdnum", to stretch the comparison with "varname" to its breaking point. -- vq
