Hi,
I'm not sure this a feature or bug, but:
$ BASH_ARGV0=foo /usr/local/stow/bash/bin/bash -c 'echo "$0"'
/usr/local/stow/bash/bin/bash
I expect $0 set to foo instead. In zsh:
$ ARGV0=foo zsh -c 'echo $0'
foo
Set BASH_ARGV0 after initialize the shell works as expected.
Config
Bash 5.0 adds $EPOCHSECONDS and $EPOCHREALTIME.
The latter expands, each time it's referenced, to the number of
seconds since the epoch with microsecond precision.
Experiment shows that the expansion always has exactly 6 digits after
the decimal point. For example, if you typed "echo $EPOCHREALT
Date:Mon, 7 Jan 2019 08:55:58 -0500
From:Greg Wooledge
Message-ID: <20190107135558.reqhfhr5vy3ih...@eeg.ccf.org>
| https://mywiki.wooledge.org/BashFAQ/109
Which only works when the shell is bash...
df...@dfong.com said:
| there's a good reason for the "craziness
The first public release of the GNU Readline library, version 8.0, is
now available for FTP with the URLs
ftp://ftp.cwru.edu/pub/bash/readline-8.0-rc1.tar.gz
ftp://ftp.gnu.org/pub/gnu/readline/readline-8.0-rc1.tar.gz
and from the master branch in the readline git repository
(http://git.savannah.g
Introduction
The first public release of bash-5.0 is now available with the URLs
ftp://ftp.cwru.edu/pub/bash/bash-5.0.tar.gz
ftp://ftp.gnu.org/pub/gnu/bash/bash-5.0.tar.gz
and from the master branch of the bash git repository
(http://git.savannah.gnu.org/cgit/bash.git/log/)
and the
>
> Crazy python people.
>
there's a good reason for the "craziness": it enables individual testing of
the script's functions. it's a good idea, and IMHO it should be more
widely used in "production" shell scripts.
On Mon, Jan 7, 2019 at 5:56 AM Greg Wooledge wrote:
> On Mon, Jan 07, 2019 at 0
On 1/7/19 4:15 AM, Robert Elz wrote:
> Date:Sun, 6 Jan 2019 17:22:36 -0500
> From:Chet Ramey
> Message-ID:
>
> | Bash, in its default mode, considers errors from builtins non-fatal. When
> | you run this in posix mode, which makes a distinction between "special"
On Mon, Jan 07, 2019 at 04:20:46PM +0700, Robert Elz wrote:
> Date:Sun, 6 Jan 2019 16:58:59 -0600
> From:Dennis Williamson
> Message-ID:
>
>
> | You should be able to protect yourself from this by detecting if a script
> | is not being sourced when it's intended
On Sat, Jan 05, 2019 at 08:28:45AM +, Paulo Nogueira wrote:
> What occurred to me is the following: suppose a script s1 starts
> being executed, by forking say, and then s1 is overwritten
DON'T... DO... THAT.
Problem solved.
>
>
> > https://pastebin.com/cV1jP41Y
>
> Really? What is your analysis? There are 100 duplicate global symbols
> shared between bash and other libraries? Or is it your assertion that
> one should never use the same symbol names, unconditionally? You're not
> making much of a point here.
It is th
On Mon, Jan 07, 2019 at 01:30:46AM -0800, Eduardo A. Bustamante López wrote:
(...)
> I missed a spot, updated patch:
>
> diff -ruN bash-5.0-rc1.orig/lib/readline/undo.c
> bash-5.0-rc1/lib/readline/undo.c
> --- bash-5.0-rc1.orig/lib/readline/undo.c 2019-01-03 13:14:43.428392927
> -0800
> ++
On Mon, Jan 07, 2019 at 01:16:05AM -0800, Eduardo A. Bustamante López wrote:
> I found this with AFL. I think it's related to the problem reported here:
> http://lists.nongnu.org/archive/html/bug-bash/2018-09/msg00045.html
>
> debian@debian-fuzz:/mnt$ cat -A rl_do_undo
> ^RM-CM-!M-CM-CM-!M-C^[.^[^
Found by fuzzing `read -e' with AFL:
debian@debian-fuzz:/mnt$ cat -A dispose_word
"^[^EM-b^_M-u$$(M-J^^_^Q$
^[^E
debian@debian-fuzz:/mnt$ base64 < dispose_word
IhsF4h/1JCQoyl4fEQobBQ==
debian@debian-fuzz:/mnt$ LC_ALL=zh_CN.gbk ~/build-gdb/bash --noprofile --norc
-c 'PATH= read -e < dispose_wo
On Sun, Jan 06, 2019 at 08:46:33PM -0800, Eduardo A. Bustamante López wrote:
> On Sun, Jan 06, 2019 at 07:18:27PM -0800, Eduardo A. Bustamante López wrote:
> (...)
> > malloc: unknown:0: assertion botched
> > malloc: 0x55769408: allocated: last allocated from unknown:0
> > realloc: start and en
Date:Sun, 6 Jan 2019 16:58:59 -0600
From:Dennis Williamson
Message-ID:
| You should be able to protect yourself from this by detecting if a script
| is not being sourced when it's intended that it must be and acting
| accordingly.
If you can work out how to d
Date:Sun, 6 Jan 2019 17:22:36 -0500
From:Chet Ramey
Message-ID:
| Bash, in its default mode, considers errors from builtins non-fatal. When
| you run this in posix mode, which makes a distinction between "special" and
| "regular" builtins, it should be a fatal
I found this with AFL. I think it's related to the problem reported here:
http://lists.nongnu.org/archive/html/bug-bash/2018-09/msg00045.html
debian@debian-fuzz:/mnt$ cat -A rl_do_undo
^RM-CM-!M-CM-CM-!M-C^[.^[^[0^P^@^P^Q0^[-^P^Q0^[^W0^@0&/^[^[^[--^W^_~0^@0^@-^L^D^@^@'/^[B^@0^B^@M-
^[^[M
On Mon, Jan 7, 2019 at 9:37 AM Eduardo A. Bustamante López
wrote:
> On Mon, Jan 07, 2019 at 08:15:12AM +0100, Ole Tange wrote:
> > On Mon, Jan 7, 2019 at 12:08 AM Chet Ramey wrote:
> > > On 1/5/19 3:12 PM, Eduardo A. Bustamante López wrote:
> > > > On Fri, Dec 28, 2018 at 10:24:50AM +0100, Ole Ta
On Mon, Jan 07, 2019 at 08:15:12AM +0100, Ole Tange wrote:
> On Mon, Jan 7, 2019 at 12:08 AM Chet Ramey wrote:
> >
> > On 1/5/19 3:12 PM, Eduardo A. Bustamante López wrote:
> > > On Fri, Dec 28, 2018 at 10:24:50AM +0100, Ole Tange wrote:
> > > (...)
> > >> Patch attached.
> :
> > > - Does the new
19 matches
Mail list logo
