Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2 -Wno-parentheses -Wno-format-security
uname output: Linux VirtualBox 4.18.0-20-generic #21~18.04.1-Ubuntu SMP $
Machine Type: x86_64-pc-linux-gnu
Bash Version
On Tue, Jun 04, 2019 at 01:42:40PM +0200, Nils Emmerich wrote:
> Configuration Information [Automatically generated, do not change]:
> Machine: x86_64
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -g -O2 -Wno-parentheses -Wno-format-security
> uname output: Linux VirtualBox 4.18.0-20-generi
On 6/4/19 3:09 AM, George R Goffe wrote:
> Hi,
> I'm trying to build the latest bash from ftp.gnu.org and am having some
> problems. Are these a bug or am I doing something wrong?
This is what happens when the bash configure can't find a working termcap
or curses library. What does the Makefile h
On 6/4/19 7:42 AM, Nils Emmerich wrote:
> Bash Version: 5.0
> Patch Level: 0
> Release Status: release
>
> Description:
> It is possible to get code execution via a user supplied variable
> in the mathematical context.
> I don't know if this is considered a bug or not, but if not,
If you run
echo "$((v))"
and v is a user supplied variable.
If the user put a specific string in v, he can execute whatever he wants
in the name of the script, because echo "$((v))" will run that code.
Am 6/4/2019 um 4:29 PM schrieb Chet Ramey:
On 6/4/19 7:42 AM, Nils Emmerich wrote:
Bash Ve
On 4.6. 16:24, Greg Wooledge wrote:
On Tue, Jun 04, 2019 at 01:42:40PM +0200, Nils Emmerich wrote:
Bash Version: 5.0
Patch Level: 0
Release Status: release
Description:
It is possible to get code execution via a user supplied variable in
the mathematical context.
For example: (( 'a
On Mon, Jun 03, 2019 at 03:42:22PM -0400, Chet Ramey wrote:
> Here's what happens. The relevant change is that wait without options now
> waits for the last process substitution, since that sets $! and is "known"
> to the shell.
>
> The sequence of events is approximately:
>
> 1. Subshell starts, f
On 6/4/19 4:34 PM, mwnx wrote:
> Thanks for the explanation. In view of the change you describe,
> there is another behaviour that I think might qualify as a bug. I'll
> give you my actual use case first.
>
> I simply want to make sure all processes running inside a given
> subshell are killed on
