Date:Sun, 24 Feb 2019 18:37:33 -0500
From:Grisha Levit
Message-ID:
| There are some what seem to be regressions (?) in bash-4.4 and
| bash-5.0 regarding the handling of "$@" expansion when it consists
| entirely of null strings.
I think these are actually mor
This is oddI wanted to turn on the file+line numbers on the function
defs...thought it might help the debugger as it gets confused when
functions are already in memory, but when I did that, now I get
a weird error on login:
/usr/share/bashdb/init/require.sh: line 17: _Dbg_requires: unbound vari
On Sun, Feb 24, 2019 at 5:14 PM Dominick Grift
wrote:
>
> Simple test:
This seems to be the same as
https://lists.gnu.org/archive/html/bug-bash/2019-01/msg00276.html
https://lists.gnu.org/archive/html/bug-bash/2019-02/msg0.html
Which has been fixed in the devel branch
There are some what seem to be regressions (?) in bash-4.4 and
bash-5.0 regarding the handling of "$@" expansion when it consists
entirely of null strings.
The relevant commits are bash-20160722 [1], bash-20170331 [2],
bash-20190220 [3].
Using:
$ n() { echo $#; }
Since bash-20160722:
$ s
Simple test:
21:54 So, the simple testcase, without SELinux : |
21:54 - sudo chmod a-r /home |
21:54 - cd $HOME |
21:54 - touch a.test |
21:54 - rm ~/*.test
I noticed that Bash5 requires some additional permissions that I found
questionable.
Mostly the listing of / and /home
I am wondering whether there is a way to avoid the requirement for above
permissions.
After some digging with the help of the community we came up with the following
analysis
Configuration Information:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2 -fdebug-prefix-map=/build/bash-Kt4GMb/bash-5.0=.
-fstack-protector-strong -Wformat -Werror=format-security -Wall
-Wno-parentheses -Wno-format-security
uname output: Linux barinkl 4.19.0-1-amd64 #1 SMP
> Bash Version: 5.0
> Patch Level: 0
> Release Status: release
>
> Description:
>
> There are two problems: (1) The keymap `cmd_xmap' used to store the
> command strings by `bind -x' is shared with all the keymaps. This
> makes problem when one defines `bind -x' key bindings for multiple
> differ
