BASH_BUILTINS(1) | 'man bash_builtins' | Manual not found
Hello. For reference | Execute 'man ' e.g 'man alias'; this opens a BASH_BUILTINS(1) titled manual. The obvious is then noticeable: a manual entry for bash_builtins does exist. Once it is searched with 'man', it is no longer found. To reproduce: $ man bash_builtins No manual entry for bash_builtins Regards.
mapfile -t doesn't always remove the delimiter
The mapfile builtin command doesn't correctly strip delimiters (when
requested with the -t option) in all cases.
unicorn:~$ echo "$BASH_VERSION"
5.1.4(1)-release
unicorn:~$ printf $'a\xffb\xffc\xff' | { mapfile -t -d $'\xff' array; declare
-p array; }
declare -a array=([0]=$'a\377' [1]=$'b\377' [2]=$'c\377')
I expected the \377 delimiters to be removed by the -t option.
Other delimiters that I tried, which also fail (aren't removed by -t)
are $'\xfe', $'\xf0', $'\x81' and $'\x80'.
Delimiters which work (are removed by -t) include 'q', $'\x01' and $'\x7f'.
At this point, it looks like any byte with the most significant bit set
triggers the error.
Additional info:
unicorn:~$ locale
LANG=en_US.utf8
LANGUAGE=
LC_CTYPE="en_US.utf8"
LC_NUMERIC="en_US.utf8"
LC_TIME=C
LC_COLLATE="en_US.utf8"
LC_MONETARY="en_US.utf8"
LC_MESSAGES="en_US.utf8"
LC_PAPER="en_US.utf8"
LC_NAME="en_US.utf8"
LC_ADDRESS="en_US.utf8"
LC_TELEPHONE="en_US.utf8"
LC_MEASUREMENT="en_US.utf8"
LC_IDENTIFICATION="en_US.utf8"
LC_ALL=
unicorn:~$ uname -a
Linux unicorn 5.10.0-8-amd64 #1 SMP Debian 5.10.46-5 (2021-09-23) x86_64
GNU/Linux
unicorn:~$ cat /etc/debian_version
11.0
unicorn:~$ dpkg -l bash | tail -n1
ii bash 5.1-2+b3 amd64GNU Bourne Again SHell
Re: BASH_BUILTINS(1) | 'man bash_builtins' | Manual not found
On Sep 30 2021, Greg Wooledge wrote: > No, they probably have a /usr/share/man/man1/alias.1.gz -> bash-builtins.1.gz > symlink or something, set up by their OS vendor. See the comment in doc/builtins.1: .\" This is a hack to force bash builtins into the whatis database .\" and to get the list of builtins to come up with the man command. This happens automagically. Andreas. -- 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_BUILTINS(1) | 'man bash_builtins' | Manual not found
On Sep 30 2021, Greg Wooledge wrote: > It's also possibly worth pointing out that the "builtins.7" provided > by Debian 11 contains a synopsis from bash 2.05b, listing a set of > builtin commands that's *vastly* out of date. But the actual content > provided by "bash-builtins.7" is newer, and includes builtins like > mapfile, which are not listed in the synopsis. That's a bug with debian's packaging. The manpage from the bash sources doesn't have that bug. Note that the bash sources do not contain any section 7 manpages. Andreas. -- 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_BUILTINS(1) | 'man bash_builtins' | Manual not found
i havent read official 'man alias' either maybe you meant help alias On Thu, Sep 30, 2021, 13:27 Greg Wooledge wrote: > On Thu, Sep 30, 2021 at 11:50:36AM +0300, Ricky Tigg wrote: > > Hello. > > > > For reference | Execute 'man ' e.g 'man alias'; this > opens a > > BASH_BUILTINS(1) titled manual. The obvious is then noticeable: a manual > > entry for bash_builtins does exist. Once it is searched with 'man', it is > > no longer found. > > > > To reproduce: > > > > $ man bash_builtins > > No manual entry for bash_builtins > > This setup is operating system specific. You'll need to talk to your > OS vendor's support mailing list, web forum, IRC channel, etc. > > E.g. on Debian 11: > > unicorn:~$ man bash-builtins | head -n1 > BASH-BUILTINS(7) Miscellaneous Information Manual > BASH-BUILTINS(7) > > This page is provided by the "bash" package in Debian, but there are > none of your symlinks, e.g. "man alias" does not give me this page. Again, > all of that stuff is set up (or not set up) by your OS vendor. > >
Re: BASH_BUILTINS(1) | 'man bash_builtins' | Manual not found
On Thu, Sep 30, 2021 at 01:37:57PM +0200, Alex fxmbsw7 Ratchev wrote: > i havent read official 'man alias' either > maybe you meant help alias No, they probably have a /usr/share/man/man1/alias.1.gz -> bash-builtins.1.gz symlink or something, set up by their OS vendor. We do not. Because we're using a different OS.
Re: BASH_BUILTINS(1) | 'man bash_builtins' | Manual not found
On Thu, Sep 30, 2021 at 01:56:45PM +0200, Andreas Schwab wrote: > On Sep 30 2021, Greg Wooledge wrote: > > > No, they probably have a /usr/share/man/man1/alias.1.gz -> > > bash-builtins.1.gz > > symlink or something, set up by their OS vendor. > > See the comment in doc/builtins.1: > > .\" This is a hack to force bash builtins into the whatis database > .\" and to get the list of builtins to come up with the man command. > > This happens automagically. unicorn:~$ locate builtins.7 [...] /etc/alternatives/builtins.7.gz /usr/share/man/man7/bash-builtins.7.gz /usr/share/man/man7/builtins.7.gz /var/lib/dpkg/alternatives/builtins.7.gz unicorn:~$ ls -l /usr/share/man/man7/builtins.7.gz lrwxrwxrwx 1 root root 31 Aug 5 07:09 /usr/share/man/man7/builtins.7.gz -> /etc/alternatives/builtins.7.gz unicorn:~$ ls -l /etc/alternatives/builtins.7.gz lrwxrwxrwx 1 root root 38 Aug 5 07:09 /etc/alternatives/builtins.7.gz -> /usr/share/man/man7/bash-builtins.7.gz unicorn:~$ ls -l /usr/share/man/man7/bash-builtins.7.gz -rw-r--r-- 1 root root 508 Aug 4 16:25 /usr/share/man/man7/bash-builtins.7.gz unicorn:~$ man mapfile No manual entry for mapfile unicorn:~$ man complete | head -n1 No manual entry for complete unicorn:~$ man alias | head -n1 ALIAS(1POSIX) POSIX Programmer's Manual ALIAS(1POSIX) unicorn:~$ man for | head -n1 for(n) Tcl Built-In Commands for(n) Again, all of this stuff is OS-specific. Or in some cases, even single- system-specific. It's also possibly worth pointing out that the "builtins.7" provided by Debian 11 contains a synopsis from bash 2.05b, listing a set of builtin commands that's *vastly* out of date. But the actual content provided by "bash-builtins.7" is newer, and includes builtins like mapfile, which are not listed in the synopsis.
Re: BASH_BUILTINS(1) | 'man bash_builtins' | Manual not found
On Thu, Sep 30, 2021 at 11:50:36AM +0300, Ricky Tigg wrote: > Hello. > > For reference | Execute 'man ' e.g 'man alias'; this opens a > BASH_BUILTINS(1) titled manual. The obvious is then noticeable: a manual > entry for bash_builtins does exist. Once it is searched with 'man', it is > no longer found. > > To reproduce: > > $ man bash_builtins > No manual entry for bash_builtins This setup is operating system specific. You'll need to talk to your OS vendor's support mailing list, web forum, IRC channel, etc. E.g. on Debian 11: unicorn:~$ man bash-builtins | head -n1 BASH-BUILTINS(7) Miscellaneous Information Manual BASH-BUILTINS(7) This page is provided by the "bash" package in Debian, but there are none of your symlinks, e.g. "man alias" does not give me this page. Again, all of that stuff is set up (or not set up) by your OS vendor.
Re: mapfile -t doesn't always remove the delimiter
On 9/30/21 10:50 AM, Greg Wooledge wrote: > The mapfile builtin command doesn't correctly strip delimiters (when > requested with the -t option) in all cases. Thanks for the report. It's an easy fix. -- ``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: EXIT trap is not executed after an exec failure in a non-interactive shell
i think its not a bug but normal runtime as ive understood, exec 'replaces' itself with , then no more continued code well error checking could maybe be better On Fri, Oct 1, 2021, 01:25 Mark March wrote: > If execfail is set, a failed exec does not cause a non-interactive shell > to exit, but it seems to reset the EXIT trap: > > cat <<'EOF' | bash > shopt -s execfail > trap "echo exiting..." EXIT > exec ~/does-not-exist > echo "exec failed in bash-$BASH_VERSION" > exit 1 > EOF > > Output: > > bash: line 3: /home/march/does-not-exist: No such file or directory > exec failed in bash-5.0.17(1)-release > > The "exiting..." line is missing. If you comment out exec > ~/does-not-exist, "exiting..." will be printed as expected. > I get this under 5.1.8 as well, built with gcc 9.3 This is on Ubuntu 20 on > x86_64. > > -Mark > >
Re: EXIT trap is not executed after an exec failure in a non-interactive shell
> On Fri, Oct 1, 2021, 01:25 Mark March wrote: > > > If execfail is set, a failed exec does not cause a non-interactive shell > > to exit, but it seems to reset the EXIT trap: It also appears to reset the EXIT trap in an interactive shell. unicorn:~$ shopt -s execfail unicorn:~$ trap 'echo exiting' EXIT unicorn:~$ trap -p EXIT trap -- 'echo exiting' EXIT unicorn:~$ exec sdkfkjsdf bash: exec: sdkfkjsdf: not found unicorn:~$ trap -p EXIT unicorn:~$
EXIT trap is not executed after an exec failure in a non-interactive shell
If execfail is set, a failed exec does not cause a non-interactive shell to exit, but it seems to reset the EXIT trap: cat <<'EOF' | bash shopt -s execfail trap "echo exiting..." EXIT exec ~/does-not-exist echo "exec failed in bash-$BASH_VERSION" exit 1 EOF Output: bash: line 3: /home/march/does-not-exist: No such file or directory exec failed in bash-5.0.17(1)-release The "exiting..." line is missing. If you comment out exec ~/does-not-exist, "exiting..." will be printed as expected. I get this under 5.1.8 as well, built with gcc 9.3 This is on Ubuntu 20 on x86_64. -Mark
Re: EXIT trap is not executed after an exec failure in a non-interactive shell
>then no more continued code man bash(1) says the following for the execfail option: execfail If set, a non-interactive shell will not exit if it can‐ not execute the file specified as an argument to the exec builtin command. An interactive shell does not exit if exec fails. It says nothing about the traps getting reset. In my example the script clearly continues to execute after the failed exec, as it should (since execfail is set). -Mark On Thursday, September 30, 2021, 04:47:13 PM PDT, Alex fxmbsw7 Ratchev wrote: i think its not a bug but normal runtime as ive understood, exec 'replaces' itself with , then no more continued code well error checking could maybe be better On Fri, Oct 1, 2021, 01:25 Mark March wrote: > If execfail is set, a failed exec does not cause a non-interactive shell to > exit, but it seems to reset the EXIT trap: > > cat <<'EOF' | bash > shopt -s execfail > trap "echo exiting..." EXIT > exec ~/does-not-exist > echo "exec failed in bash-$BASH_VERSION" > exit 1 > EOF > > Output: > > bash: line 3: /home/march/does-not-exist: No such file or directory > exec failed in bash-5.0.17(1)-release > > The "exiting..." line is missing. If you comment out exec ~/does-not-exist, > "exiting..." will be printed as expected. > I get this under 5.1.8 as well, built with gcc 9.3 This is on Ubuntu 20 on > x86_64. > > -Mark > >
