Re: Bash Bug - Incorrect Printing of Escaped Characters
On Mon, Dec 25, 2023 at 05:00:37PM -0500, Seth Sabar wrote: > I'm reaching out to report what I believe to be a bug with the > *--pretty-print* feature in bash-5.2. Tangentially, this option doesn't seem to be documented outside of "bash --help": $ git clone https://git.savannah.gnu.org/git/bash.git Cloning into 'bash'... remote: Counting objects: 41221, done. remote: Compressing objects: 100% (5024/5024), done. remote: Total 41221 (delta 36225), reused 41045 (delta 36106) Receiving objects: 100% (41221/41221), 259.98 MiB | 15.65 MiB/s, done. Resolving deltas: 100% (36225/36225), done. $ cd bash/doc/ doc$ fgrep -r pretty texinfo.tex:% above. But it's pretty close. texinfo.tex: % and a tt hyphen is pretty tiny. @code also disables ?` !`. doc$ Eric
Re: Idea: jobs(1) -i to print only :%ID:s
On Fri, Nov 10, 2023 at 01:22:54PM -0500, Greg Wooledge wrote: > It most definitely is *not* everywhere. It's part of GNU coreutils, > and is generally not present on any system that does't use those (BSDs > and commercial Unixes for example). >From _seq(1)_ on FreeBSD: > The seq command first appeared in Version 8 AT UNIX. A seq command > appeared in NetBSD 3.0, and was ported to FreeBSD 9.0. This command > was based on the command of the same name in Plan 9 from Bell Labs and > the GNU core utilities. The GNU seq command first appeared in the 1.13 > shell utilities release. >From _seq(1)_ on OpenBsd: > A seq command appeared in Version 8 AT UNIX. This version of seq > appeared in NetBSD 3.0 and was ported to OpenBSD 7.1.
Re: Seg fault on "echo ~nosuchuser"
On Thu, May 28, 2020 at 03:12:47PM -0700, Keith Thompson wrote: > I see this problem on copies of bash 5.0.16 and 5.0.17 built from > sourced on Ubuntu 20.04 LTS. It does *not* occur with the /bin/bash > GNU bash, version 5.0.16(1)-release (x86_64-pc-linux-gnu) > provided by the distribution. I haven't verified how far > back this goes. For what it's worth, I cannot reproduce this on Bash 5.0.17 compiled with musl 1.2.0 or glibc 2.28 on Debian 10, GCC 8.3.0. musl: ~$ bash --version GNU bash, version 5.0.17(1)-release (x86_64-pc-linux-gnu) ... ~$ bash -c 'echo ~nosuchuser' ~nosuchuser glibc: bash-5.0$ ldd --version ldd (Debian GLIBC 2.28-10) 2.28 ... bash-5.0$ ./bash --version GNU bash, version 5.0.17(2)-release (x86_64-pc-linux-gnu) ... bash-5.0$ ./bash -c 'echo ~nosuchuser' ~nosuchuser Eric
Re: Option to disable VSUSP at prompt (feature request with proof of concept)
On Thu, Nov 24, 2016 at 12:05:20AM -0800, Eric Pruitt wrote:
> In my Bash configuration, I have things setup so Ctrl+Z is no longer
> translated into a signal at the Bash prompt so it can be remapped. Most
> recently, I decided to modify the Bash source to implement this change
> in the interpreter because the stty invocations introduced a perceptible
> amount of lag on a virtualized OpenBSD host I use. I think this feature
> would be a useful default since it usually does not make sense to send
> SIGTSTP to a prompt. Here's an accompanying snippet from my inputrc:
>
> # Allows Ctrl+Z to be used to bring programs back into the
> # foreground. The cursor is moved to the beginning of the line
> # before typing so a specific job can be resumed by typing its
> # identifier (e.g. a number) then hitting Ctrl+Z. This depends on
> # Ctrl+Z being a literal sequence i.e. "stty susp undef".
> "\C-z": "\C-afg \C-m"
This patch had a bug that I recently fixed, and I've attached an updated
version. Under certain conditions, ^Z for SIGTSTP would not be
re-enabled after executing a command. For example, if "cat /dev/zero >
/dev/null" was interrupted by pressing Ctrl+C, pressing Ctrl+Z would not
generate a literal ^Z control character at the next prompt. Some
debugging revealed that I did not fully understand the control flow of
the prompt handling when writing the original patch; control may be
resumed at the top of the "reader_loop" function by way of a long lump
which bypassed the vsusp toggling code. The bug has been fixed by moving
the vsusp toggle logic after the aforementioned long-jump destination.
I'm not requesting that this patch be accepted upstream, just posting an
updated version for anyone that might interested in this feature.
Eric
When running commands interactively, modify the terminal attributes so the
suspend character is interpreted as literal sequence at the prompt but produces
a SIGTSTP signal during command execution. This makes it possible to bind ^Z in
readline. For example, adding `"\C-z": "\C-afg \C-m"` to "~/.inputrc" would
make it possible to suspend a program using ^Z then pressing ^Z again to bring
the program back to the foreground.
--- eval.c 2016-06-02 15:49:27.0 -0700
+++ eval.c 2016-11-20 15:02:23.681680378 -0800
@@ -31,6 +31,7 @@
#include
#include
+#include
#include "bashintl.h"
@@ -69,6 +70,8 @@
int
reader_loop ()
{
+ struct termios ttyattr;
+ cc_t vsusp = 0;
int our_indirection_level;
COMMAND * volatile current_command;
@@ -84,6 +87,13 @@
code = setjmp_nosigs (top_level);
+ if (!vsusp && indirection_level == 1 && interactive &&
+ !tcgetattr(STDERR_FILENO, )) {
+ vsusp = ttyattr.c_cc[VSUSP];
+ ttyattr.c_cc[VSUSP] = 0;
+ tcsetattr(STDERR_FILENO, TCSADRAIN, );
+ }
+
#if defined (PROCESS_SUBSTITUTION)
unlink_fifo_list ();
#endif /* PROCESS_SUBSTITUTION */
@@ -177,6 +187,13 @@
free (ps0_string);
}
+ if (vsusp) {
+ ttyattr.c_cc[VSUSP] = vsusp;
+ if (!tcsetattr(STDERR_FILENO, TCSADRAIN, )) {
+ vsusp = 0;
+ }
+ }
+
execute_command (current_command);
exec_done:
@@ -199,6 +216,11 @@
EOF_Reached = EOF;
}
indirection_level--;
+
+ if (vsusp) {
+ttyattr.c_cc[VSUSP] = vsusp;
+tcsetattr(STDERR_FILENO, TCSADRAIN, );
+ }
return (last_command_exit_value);
}
Re: Option to disable VSUSP at prompt (feature request with proof of concept)
On Thu, Dec 22, 2016 at 09:32:37AM -0500, Chet Ramey wrote: > I haven't thought about it too much, but I'm initially reluctant to put > this into the mainline source, when it seems like it could be accomplished > without any source changes at all. A lot of "new" functionality added in each release could be implemented in Bash itself using functions and / or external programs, so I don't understand this sentiment as a rationale. Off the top of my head, I think the "%T(...)" time formatting which can be achieved with many implementations of date(1) is a great example of this. That aside, implementing this without changes to Bash's C source code requires the use of a DEBUG trap, PS0 or potentially PS1. Using stty in a DEBUG trap the obvious way (simply "stty susp undef") would sometimes result in "jobs" being non-empty when I otherwise had no other programs in the background. I ultimately resolved this by running stty in a subshell i.e. "stty susp undef" became "$(stty susp undef)", but I think the fact that the obvious way of doing this is Bash doesn't work perfectly suggests that it would be better implemented in C. Changing VSUSP natively is also far faster than calling stty. Eric
Re: Option to disable VSUSP at prompt (feature request with proof of concept)
On Thu, Nov 24, 2016 at 12:05:20AM -0800, Eric Pruitt wrote: > In my Bash configuration, I have things setup so Ctrl+Z is no longer > translated into a signal at the Bash prompt so it can be remapped. Most > recently, I decided to modify the Bash source to implement this change > in the interpreter because the stty invocations introduced a perceptible > amount of lag on a virtualized OpenBSD host I use. I think this feature > would be a useful default since it usually does not make sense to send > SIGTSTP to a prompt. Here's an accompanying snippet from my inputrc: > > # Allows Ctrl+Z to be used to bring programs back into the > # foreground. The cursor is moved to the beginning of the line > # before typing so a specific job can be resumed by typing its > # identifier (e.g. a number) then hitting Ctrl+Z. This depends on > # Ctrl+Z being a literal sequence i.e. "stty susp undef". > "\C-z": "\C-afg \C-m" > > With my changes to Bash and this in my inputrc, Ctrl+Z becomes a toggle. > I have attached the patch I wrote for myself. Since I only use modern > POSIX / UNIX-like systems, it was not written with portability in mind > and cannot be disabled with with "set" or "shopt." Consider it a proof > of concept rather than a pull request. Please let me know what you > think. Bump.
Option to disable VSUSP at prompt (feature request with proof of concept)
In my Bash configuration, I have things setup so Ctrl+Z is no longer
translated into a signal at the Bash prompt so it can be remapped. Most
recently, I decided to modify the Bash source to implement this change
in the interpreter because the stty invocations introduced a perceptible
amount of lag on a virtualized OpenBSD host I use. I think this feature
would be a useful default since it usually does not make sense to send
SIGTSTP to a prompt. Here's an accompanying snippet from my inputrc:
# Allows Ctrl+Z to be used to bring programs back into the
# foreground. The cursor is moved to the beginning of the line
# before typing so a specific job can be resumed by typing its
# identifier (e.g. a number) then hitting Ctrl+Z. This depends on
# Ctrl+Z being a literal sequence i.e. "stty susp undef".
"\C-z": "\C-afg \C-m"
With my changes to Bash and this in my inputrc, Ctrl+Z becomes a toggle.
I have attached the patch I wrote for myself. Since I only use modern
POSIX / UNIX-like systems, it was not written with portability in mind
and cannot be disabled with with "set" or "shopt." Consider it a proof
of concept rather than a pull request. Please let me know what you
think.
Thanks,
Eric
--- eval.c 2016-06-02 15:49:27.0 -0700
+++ eval.c 2016-11-20 15:02:23.681680378 -0800
@@ -31,6 +31,7 @@
#include
#include
+#include
#include "bashintl.h"
@@ -69,6 +70,8 @@
int
reader_loop ()
{
+ struct termios ttyattr;
+ cc_t vsusp = 0;
int our_indirection_level;
COMMAND * volatile current_command;
@@ -82,6 +85,13 @@
{
int code;
+ if (!vsusp && indirection_level == 1 && interactive &&
+ !tcgetattr(STDERR_FILENO, )) {
+vsusp = ttyattr.c_cc[VSUSP];
+ttyattr.c_cc[VSUSP] = 0;
+tcsetattr(STDERR_FILENO, TCSADRAIN, );
+ }
+
code = setjmp_nosigs (top_level);
#if defined (PROCESS_SUBSTITUTION)
@@ -177,6 +187,13 @@
free (ps0_string);
}
+ if (vsusp) {
+ ttyattr.c_cc[VSUSP] = vsusp;
+ if (!tcsetattr(STDERR_FILENO, TCSADRAIN, )) {
+ vsusp = 0;
+ }
+ }
+
execute_command (current_command);
exec_done:
@@ -199,6 +216,11 @@
EOF_Reached = EOF;
}
indirection_level--;
+
+ if (vsusp) {
+ttyattr.c_cc[VSUSP] = vsusp;
+tcsetattr(STDERR_FILENO, TCSADRAIN, );
+ }
return (last_command_exit_value);
}
Re: Command substitution with null bytes generates warning
On Wed, Oct 05, 2016 at 09:20:58AM -0400, Chet Ramey wrote: > Try the attached patch, which reduces the number of warnings to 1 per call > to command substitution. I don't agree with this approach -- I think you should be able to turn off the warning completely, so I am not interested in testing the patch. In the script where I ran into this problem, I simply suppressed the warning using 2>&-, and that's what I will continue to do if I will knowingly read files that contain null bytes. Eric
Re: Behavior of ${var/*/text} has changed
On Fri, Sep 16, 2016 at 03:45:39PM -0400, Greg Wooledge wrote:
> On Fri, Sep 16, 2016 at 12:38:20PM -0700, Eric Pruitt wrote:
> > first time. However, that construct still won't work because if a
> > variable is defined, it will still choose "not empty:"
> >
> > ericpruitt@sinister:~$ X=
> > ericpruitt@sinister:~$ echo ${X+Not empty}
> > Not empty
>
> Then you want :+ instead of +
>
> Note that I had :+ (not +) in my original email.
>
> imadev:~$ X=
> imadev:~$ echo "${X+Not empty}"
> Not empty
> imadev:~$ echo "${X:+Not empty}"
>
> imadev:~$
Right you are; thanks.
Eric
Re: Behavior of ${var/*/text} has changed
On Fri, Sep 16, 2016 at 12:30:59PM -0700, Eric Pruitt wrote:
> > That, or ${VAR:+not empty} which is how I suggest testing for variable
> > set-and-not-empty-ness.
>
> I'm aware of that construct, but that doesn't do what I want unless I'm
> missing something; I don't want to change the value of the variable.
Actually, I misunderstood what you wrote when I skimmed your message the
first time. However, that construct still won't work because if a
variable is defined, it will still choose "not empty:"
ericpruitt@sinister:~$ X=
ericpruitt@sinister:~$ echo ${X+Not empty}
Not empty
ericpruitt@sinister:~$ X=XXX
ericpruitt@sinister:~$ echo ${X+Not empty}
Not empty
Eric
Re: Behavior of ${var/*/text} has changed
On Fri, Sep 16, 2016 at 03:22:29PM -0400, Greg Wooledge wrote:
> Off hand I'd say the bash 4.4 behavior is correct. * matches 0 or
> more characters, so it should match an empty or undefined variable.
Yes, I agree that the Bash 4.4 behavior is more reasonable, but I think
the change at least needs to be documented (assuming I didn't miss it).
> > Fix:
> > As a work-around, I have changed the expressions I'm using from
> > ${VAR/*/...} to ${VAR/?*/...}.
>
> That, or ${VAR:+not empty} which is how I suggest testing for variable
> set-and-not-empty-ness.
I'm aware of that construct, but that doesn't do what I want unless I'm
missing something; I don't want to change the value of the variable.
Here's an example from my prompt command:
function prompt-command()
{
# [...]
local jobs="$(jobs)"
# [...]
PS1="${SSH_TTY/?*/\\u@\\h:}\\W${jobs/?*/ [\\j]}\\$ "
# [...]
}
In this example, I want to show the username and hostname if SSH_TTY is
set and not empty, but I do not want to modify its value. I am also
showing the number of jobs in brackets, but I only want to do that if
there are some jobs in the background.
Eric
Behavior of ${var/*/text} has changed
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-unknown-linux-gnu'
-DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/local/share/locale' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -g -O2
-Wno-parentheses -Wno-format-security
uname output: Linux sinister 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u1
(2016-09-03) x86_64 GNU/Linux
Machine Type: x86_64-unknown-linux-gnu
Bash Version: 4.4
Patch Level: 0
Release Status: release
Description:
In Bash 4.3, "${var/*/text}" would generate "" if var was a zero-length
string and "text" if it contained at least one character. In Bash 4.4,
this
is no longer the case. I'm not sure if this is necessarily a bug, but I
was
unable to find this change in behavior in the change log or man page.
Repeat-By:
Bash 4.3:
ericpruitt@sinister:~$ echo ${VAR/*/VAR was not empty}
VAR was not empty
ericpruitt@sinister:~$ VAR=
ericpruitt@sinister:~$ echo ${VAR/*/VAR was not empty}
ericpruitt@sinister:~$
Bash 4.4:
ericpruitt@sinister:~$ VAR=NotEmpty
ericpruitt@sinister:~$ echo ${VAR/*/VAR was not empty}
VAR was not empty
ericpruitt@sinister:~$ VAR=
ericpruitt@sinister:~$ echo ${VAR/*/VAR was not empty}
VAR was not empty
ericpruitt@sinister:~$
Fix:
As a work-around, I have changed the expressions I'm using from
${VAR/*/...} to ${VAR/?*/...}. Since it is not clear to me if this is
actually a bug, I'm not sure what that fix should be. Maybe there
should be a new "compat..." option.
Command substitution with null bytes generates warning
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-unknown-linux-gnu' -DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/local/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -g -O2 -Wno-parentheses -Wno-format-security uname output: Linux sinister 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u1 (2016-09-03) x86_64 GNU/Linux Machine Type: x86_64-unknown-linux-gnu Bash Version: 4.4 Patch Level: 0 Release Status: release Description: I have a script that execute `if [[ "$(<"/proc/$1/cmdline")" = tmux* ]];`. All /proc/*/cmdline include null bytes, and as of Bash 4.4, this results in a warning being spewed on stderr which did not happen in Bash 4.3. Repeat-By: echo "$(<"/proc/$$/cmdline")" Fix: Is this even an intentional change? I looked at some of the other internal_warning invocations, and they were commented out using "#if 0 ... #endif."
Re: Autocompletion problems with nounset and arrays
On Sun, May 01, 2016 at 03:54:16AM -0400, Grisha Levit wrote: > Does the issue go away if you do a "bind 'set colored-stats off"' ? No. That already defaults to "off", and I don't override it. I ran the "bind" command anyway, and it didn't make a difference. Eric
Re: Autocompletion problems with nounset and arrays
On Tue, Apr 26, 2016 at 01:54:12PM -0400, Chet Ramey wrote: > Thanks for the report. I will fix this before bash-4.4 is released. Is there some way for me to work around this issue in older versions of Bash using autocompletion hooks? Eric
Re: Autocompletion problems with nounset and arrays
On Tue, Apr 26, 2016 at 01:54:12PM -0400, Chet Ramey wrote: > Thanks for the report. I will fix this before bash-4.4 is released. Thank you. I am happy to compile a prerelease build to try out your solution if you want another tester before you roll fix into an RC. Eric
Autocompletion problems with nounset and arrays
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-strong -Wformat -Werror=format-security -Wall
uname output: Linux sinister 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u4
(2016-02-29) x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 4.3
Patch Level: 30
Release Status: release
Description:
There's a quirk with Bash's autocompletion when trying to use tab
completion with built-in arrays while the nounset option is enabled:
~$ echo ${BASH_ALbash: BASH_ALIASES: unbound variable
IASES}
Note that this happens using Bash's built-in completion; my Bash
configuration includes "complete -r" since many of the compgen
completions written for Bash use unset variables.
Repeat-By:
Run "set -u" then type "${BASH_AL" then hit "Tab".
Fix:
Not sure what the best approach is, but one way to work around this
would be to ignore nounset when autocompleting array names.
