Feature Request: Allow each completion to have their own wordbreaks
Right now I'm trying to perfect this completion script for rake (https://git.io/JDaSA), but the problem is it has to rely on modifying the COMP_WORDBREAKS variable so it doesn't contain '=' and ':'. This conflicts with git's completion script at least which prefers `:` to be assigned, and I'm not sure how it affects other scripts that may want `=` not removed. Either way the best solution in my opinion is to have Bash add a new feature that allows each completion have their own COMP_WORDBREAKS, probably through a new complete option, or a global associative array variable that can contain the name of the completion as the key and the value as the word break characters. -- konsolebox
Line is corrupted when pasting long string in vi mode with exit_attribute_mode prompt
To reproduce: - Launch a bash shell in a terminal emulator (I've tested konsole and gnome-terminal on KDE 5.23.4 with X11, if that matters). - Copy "Lorem ipsum dolor sit amet, consectetur adipiscing elit" (without the quotes) to your clipboard. - Run these commands in the terminal: ``` bash --norc --noprofile set -o vi PS1='$(tput sgr0)' # emit exit_attribute_mode capability string ``` - Press Ctrl-Shift-V to paste lipsum text into the terminal - Press Esc Observe that first six characters of the pasted string have been duplicated. If you try to delete them you'll notice you're unable to. They're in the same state as the characters that comprise the prompt, whatever state that is. Occasionally I've been able to delete the duplicated characters in gnome-terminal. I've noticed that the length of the string matters. Moderately short strings don't cause this issue. If you're unable to reproduce, maybe try a longer string. GNU bash, version 5.1.12(1)-release (x86_64-pc-linux-gnu) Thanks for all the great work you guys do, Jack
in-line calls to functions cause "exit" in the function to act like "return"
(Composed using 'bashbug')From: yesxo...@protonmail.ch
To: bug-bash@gnu.org
Subject: in-line calls to functions cause "exit" in the function to act like
"return"
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -O2 -g -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions
-fstack-protector-strong -grecord-gcc-switches
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
-Wno-parentheses -Wno-format-security
uname output: Linux 523x.env.dtu.dk 5.11.22-100.fc32.x86_64 #1 SMP Wed May 19
18:58:25 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-redhat-linux-gnu
Bash Version: 5.0
Patch Level: 17
Release Status: release
Description:
When 'exit' is executed in a function called to "in-line" its output to stdout,
the 'exit' acts like return, leaving the function scope, but not terminating
the bash process.
Repeat-By:
Sample script:
#!/bin/bash
set -x
function bar()
{
exit 1
}
foo="$(bar)"
exit 0
Running:
$ ./foo.sh
++ bar
++ exit 1
+ foo=
+ exit 0
$ echo $?
0
The call of 'exit 1' in 'function bar' "should" cause the bash process to
terminate and declare its exit status as 1 to the kernel, unless my
understanding of bash(1) and its relation with the kernel is mistaken.
Fix:
I have to work around by doing more checks in calling functions. But, I've
only seen this in that "in-lining" mechanism, thus, that seems to be where the
problem lies.
The "fix" is for exit to do its job, irrespective of the function depth.
If I have seriously misunderstood things, I apologise for wasting your time.
I love bash(1), and thank all who have worked upon it.
Warm regards,
YesXorNo
Re: in-line calls to functions cause "exit" in the function to act like "return"
you execute it in a separate bash subshell via $( .. ) this code parsing layer u bring to exit On Sat, Dec 18, 2021, 16:50 yesxorno via Bug reports for the GNU Bourne Again SHell wrote: > (Composed using 'bashbug')
Re: in-line calls to functions cause "exit" in the function to act like "return"
On Sat, 18 Dec 2021 13:07:03 +
yesxorno via Bug reports for the GNU Bourne Again SHell
wrote:
> Description:
>
> When 'exit' is executed in a function called to "in-line" its output to
> stdout, the 'exit' acts like return, leaving the function scope, but not
> terminating the bash process.
It does, in fact, exit the subshell in question.
>
> Repeat-By:
>
> Sample script:
>
> #!/bin/bash
>
> set -x
>
> function bar()
> {
> exit 1
> }
>
> foo="$(bar)"
Here, the use of a command substitution causes a subshell to be created. The
command, exit 1, is not run by the shell that the kernel loaded to interpret
your script.
--
Kerin Millar
Re: Line is corrupted when pasting long string in vi mode with exit_attribute_mode prompt
On Dez 17 2021, Jack Pearson wrote: > PS1='$(tput sgr0)' # emit exit_attribute_mode capability string Non-printable characters in the prompt must be bracketed by \[ \]. PS1='\[$(tput sgr0)\]' -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: in-line calls to functions cause "exit" in the function to act like "return"
x=$( exit 2 ) ; printf $?\\n
On Sat, Dec 18, 2021, 17:03 Kerin Millar wrote:
> On Sat, 18 Dec 2021 13:07:03 +
> yesxorno via Bug reports for the GNU Bourne Again SHell
> wrote:
>
> > Description:
> >
> > When 'exit' is executed in a function called to "in-line" its output to
> stdout, the 'exit' acts like return, leaving the function scope, but not
> terminating the bash process.
>
> It does, in fact, exit the subshell in question.
>
> >
> > Repeat-By:
> >
> > Sample script:
> >
> > #!/bin/bash
> >
> > set -x
> >
> > function bar()
> > {
> > exit 1
> > }
> >
> > foo="$(bar)"
>
> Here, the use of a command substitution causes a subshell to be created.
> The command, exit 1, is not run by the shell that the kernel loaded to
> interpret your script.
>
> --
> Kerin Millar
>
>
Re: Line is corrupted when pasting long string in vi mode with exit_attribute_mode prompt
Ahh my bad, didn't read that section of the manual carefully enough. Thanks Andreas! Jack On December 18, 2021 8:03:17 AM PST, Andreas Schwab wrote: >On Dez 17 2021, Jack Pearson wrote: > >> PS1='$(tput sgr0)' # emit exit_attribute_mode capability string > >Non-printable characters in the prompt must be bracketed by \[ \]. > >PS1='\[$(tput sgr0)\]' > >-- >Andreas Schwab, sch...@linux-m68k.org >GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 >"And now for something completely different."
Re: bash manual on interactive shell
On 2021-12-13 at 11:23 +, Kerin Millar wrote: > You mentioned being confused by how the and's and or's combine. The > wording of the bash man page seems marginally less ambiguous in that > regard, partly owing to its sparse use of the comma. > > "An interactive shell is one started without non-option arguments > (unless -s is specified) and without the -c option whose standard > input and error are both connected to terminals (as determined by > isatty(3)), or one started with the -i option." > > Although, I would say that the absence of a comma before whose is a > grammatical error. In any case, I wanted to suggest the use of the > word, either. For example:- > > "An interactive shell is either one started without non-option > arguments (unless -s is specified) and without the -c option whose > standard input and error are both connected to terminals (as > determined by isatty(3)), or one started with the -i option." > > I think that the addition of this word might increase the probability > of the sentence being (correctly) interpreted in the fashion of "an > interactive shell is either one that fulfils ( criteria A ) or ( > criteria B )", keeping in mind that the -i option always renders bash > interactive. I think it is much simpler than what the existing definition (and the mentioned proposals) do by describing non-option arguments, and those two options. It all boils down to "bash doesn't have anything to run" Thus I propose: «An interactive shell is one which was provided no command to run (neither by directly receiving a file after all options and their arguments nor by use of -c or -s options) and whose standard input and error are both connected to terminals (as determined by isatty(3)), or one explicitly started with the -i option.» Regards
