>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 comma
> 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 exit
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
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/doe
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, vit
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'
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 inc
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
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
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
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 manua
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 f
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_built
13 matches
Mail list logo
