Re: bash errexit shell option does not work in some cases.
On Mon, Jun 01, 2020 at 05:28:20PM +0700, Robert Elz wrote: > in this case: > > | You're merely the latest person to discover that this applies to you: > | http://mywiki.wooledge.org/BashFAQ/105 > > doesn't really apply - the cases reported are simply bugs in bash, > a shell implementing -e correctly should exit as it was expected to. The specification of set -e is not fixed. It keeps changing. Bash implements a version of set -e that was specified at some point in the past, which included the phrase "simple command". So, the rules that apply to compound commands and the rules that apply to simple commands are not the same. A more recent POSIX specification has changed the wording, and therefore bash's implementation is out of date. A future version of bash will conform to the new wording, which means it will (once again) break backward compatibility with older versions of bash (and also with any other shells that still implement the older specification). Simply waving this off as a "bug in bash" is quite unfair. This is part of the set -e nightmare, which is what we keep trying to get you (and everyone else) to understand.
Vi mode and g commands
Some g commands are implemented, but incorrectly. Examples: * g0 is equivalent to 0, rather than 'beginning of screen line when wrapped' * g$ is equivalent to $, rather than 'end of screen line when wrapped' Other g commands are not implemented, just ignored. Examples: * gM is ignored, rather than going to the middle of the line * gE is ignored, rather than going to the end of the last word Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -g -O2 -fdebug-prefix-map=/build/bash-cP61jF/bash-5.0=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -Wno-parentheses -Wno-format-security uname output: Linux karotte 5.4.0-33-generic #37-Ubuntu SMP Thu May 21 12:53:59 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 5.0 Patch Level: 16 Release Status: release Description: [Detailed description of the problem, suggestion, or complaint.] Repeat-By: [Describe the sequence of events that causes the problem to occur.] Fix: [Description of how to fix the problem. If you don't know a fix for the problem, don't include this section.] -- Dan Shearer d...@shearer.org
Re: Vi mode and g commands
On Mon, Jun 08, 2020 at 02:28:05AM +0100, Dan Shearer wrote: > Some g commands are implemented, but incorrectly. Examples: > * g0 is equivalent to 0, rather than 'beginning of screen line when wrapped' > * g$ is equivalent to $, rather than 'end of screen line when wrapped' > > Other g commands are not implemented, just ignored. Examples: > * gM is ignored, rather than going to the middle of the line > * gE is ignored, rather than going to the end of the last word Those are not standard vi commands, as far as I can tell. They appear to be vim extensions. I opened /usr/bin/vi on HP-UX 11i and typed a line that was longer than my terminal's width, and then tried these commands. They do not do what you describe. In real vi, in an 80-wide terminal, with a single line of 120 or so characters, and the cursor at position 40, g$ acts just like $. With the cursor now at the end of the line, g0 acts just like 0. gE acts just like E (moves to the end of the current word). gM acts just like M (moves to the start of the middle line, which happens to be the first line, because there's only one line). I see no evidence that 'g' is even a meaningful keystroke in real vi. Maybe that's why vim chose it as the prefix for so many of their extension commands.
Re: bash errexit shell option does not work in some cases.
On 6/8/20 7:24 AM, Greg Wooledge wrote: > On Mon, Jun 01, 2020 at 05:28:20PM +0700, Robert Elz wrote: >> in this case: >> >> | You're merely the latest person to discover that this applies to you: >> | http://mywiki.wooledge.org/BashFAQ/105 >> >> doesn't really apply - the cases reported are simply bugs in bash, >> a shell implementing -e correctly should exit as it was expected to. > > The specification of set -e is not fixed. It keeps changing. Bash > implements a version of set -e that was specified at some point in > the past, which included the phrase "simple command". So, the rules > that apply to compound commands and the rules that apply to simple > commands are not the same. This explanation is out of date. It's true that back as recently as 2008, POSIX specified that `set -e' worked only if a simple command failed. Bash implemented that spec, which was incompatible with other (and historical) shell implementations. > > A more recent POSIX specification has changed the wording, and therefore > bash's implementation is out of date. A future version of bash will > conform to the new wording, which means it will (once again) break > backward compatibility with older versions of bash (and also with any > other shells that still implement the older specification). We hashed out the problems with `set -e' starting back in 2009, and the standard changed to match historical behavior. This meant that things like pipelines, (command) subshells, and so on failing would cause the shell to exit when errexit was enabled. I changed bash to match it starting with version 4.0, which was followed by much gnashing of teeth and rending of garments. I'm sure you recall. No one is arguing that the standard did not change here. In this case, there was a defect report, (extensive) discussion, an interpretation, and the standard finally channged in 2013. > Simply waving this off as a "bug in bash" is quite unfair. These two cases are, in fact, bugs in bash. They are remnants from the period when `set -e' only affected simple commands, true, but they are bugs now nonetheless. > This is part of the set -e nightmare, which is what we keep trying to > get you (and everyone else) to understand. Most of the issue with `set -e' is folks not understanding when it's not in effect. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Vi mode and g commands
On 6/7/20 9:28 PM, Dan Shearer wrote: > Some g commands are implemented, but incorrectly. Examples: > * g0 is equivalent to 0, rather than 'beginning of screen line when wrapped' > * g$ is equivalent to $, rather than 'end of screen line when wrapped' > > Other g commands are not implemented, just ignored. Examples: > * gM is ignored, rather than going to the middle of the line > * gE is ignored, rather than going to the end of the last word `g' isn't a valid command in POSIX sh vi editing mode (or vi itself). -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: bash errexit shell option does not work in some cases.
On 6/8/20 10:02 AM, Chet Ramey wrote: > On 6/8/20 7:24 AM, Greg Wooledge wrote: >> This is part of the set -e nightmare, which is what we keep trying to >> get you (and everyone else) to understand. > > Most of the issue with `set -e' is folks not understanding when it's > not in effect. Well, Greg does have a pretty good point (which is a point I for one prioritize in my decision process for "do I personally recommend the use of set -e") in that another part of the issue is its doing different things across point releases of a shell. And that's not counting the times when the issue is people not understanding when it *is* in effect. Or people who know exactly when it is and isn't in effect, and have no issue, but decline to use it because the precise nature of "when it is and isn't in effect" decreases the usefulness of it sufficiently to make them decide they're better off implementing error checking a different way... and *that* is, I think, what Greg is pointing out. -- Eli Schwartz Arch Linux Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: bash errexit shell option does not work in some cases.
On 6/8/20 10:44 AM, Eli Schwartz wrote: > Well, Greg does have a pretty good point (which is a point I for one > prioritize in my decision process for "do I personally recommend the use > of set -e") in that another part of the issue is its doing different > things across point releases of a shell. It last changed in 2009. Except for MacOS X, which is frozen in amber, people should be using a version with the current semantics by now. If you don't want things to change across releases, you have choices about which version to use. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ signature.asc Description: OpenPGP digital signature
Re: Vi mode and g commands
Date:Mon, 8 Jun 2020 09:34:34 -0400 From:Greg Wooledge Message-ID: <20200608133434.ga4...@eeg.ccf.org> | Those are not standard vi commands, as far as I can tell. You're right, they're not. | g$ acts just like $. | g0 acts just like 0. | gE acts just like E None of these are surprising, or shouldn't be, there's no 'g' command in vi, the 'g' is just an error (should really flash the screen or something) - then whatever follows it is just the next command. | I see no evidence that 'g' is even a meaningful keystroke in real vi. | Maybe that's why vim chose it as the prefix for so many of their | extension commands. That's correct, there is no 'g' in vi, and as an explanation, that makes sense. kre
core dump an alt. alt1 alt.
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 -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -fdebug-prefix-map=/build/bash-N2nMjo/bash-4.4.18=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -Wno-parentheses -Wno-format-security uname output: Linux sint 4.15.0-101-generic #102-Ubuntu SMP Mon May 11 10:07:26 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 4.4 Patch Level: 20 Release Status: release Description: Got a core dump (segmentation fault) when i type: Alt-. Alt-1 Alt-. A gdb backtrace shows: #0 0x55985da6413e in xrealloc (pointer=0x55985f041180, bytes=104688) at .././xmalloc.c:133 #1 0x55985da8a024 in _rl_dispatch_subseq (key=46, map=0x55985dce8240 , got_subseq=0) at ../../.././lib/readline/readline.c:853 #2 0x55985da8a10e in _rl_dispatch (key=, map=) at ../../.././lib/readline/readline.c:802 #3 0x55985da8b680 in rl_vi_redo (count=1, c=) at ../../.././lib/readline/vi_mode.c:290 #4 0x55985da89ce1 in _rl_dispatch_subseq (key=46, map=0x55985dce8240 , got_subseq=0) at ../../.././lib/readline/readline.c:859 #5 0x55985da8a10e in _rl_dispatch (key=, map=) at ../../.././lib/readline/readline.c:802 #6 0x55985da8b680 in rl_vi_redo (count=1, c=) at ../../.././lib/readline/vi_mode.c:290 This trace repeats from #4. Repeat-By: cat > inputrc <<-'EOF' set editing-mode vi "\e.": yank-last-arg EOF INPUTRC=./inputrc bash --noprofile --norc # now type: Alt-. Alt-1 Alt-. Regards, Mike
Re: core dump an alt. alt1 alt.
On 6/8/20 6:54 PM, bash...@jonkmans.nl wrote: > Bash Version: 4.4 > Patch Level: 20 > Release Status: release > > Description: > Got a core dump (segmentation fault) when i type: Alt-. Alt-1 Alt-. You tried to redo `.'. The way this happens is you are in command mode, run that yank-last-arg binding (which sets the last vi-mode command to `.'), then try to run it again, but miss the timeout described in the last paragraph of my previous message, which results in you trying to redo the last command (`.') in a context where the binding for `.' is vi-redo. I put something in to stop that at the same time I made the other changes described in my previous message. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
