On 5/22/23 8:36 AM, Emanuele Torre wrote:
Error messages for fatal error e.g. ${x?foo} or rovar=foo or
$x expanded with nounset, report an error message prefixed by the string
"environment:" instead of "scriptname:" (or "$0:").
Thanks for the report. Error messages during function execu
Got it, thanks for the info.
Thanks,
Fan
-Original Message-
From: Chet Ramey [mailto:chet.ra...@case.edu]
Sent: Wednesday, October 24, 2018 4:48 AM
To: Chen, Farrah ; bug-bash@gnu.org
Cc: chet.ra...@case.edu
Subject: Re: Environment variable "PS4" can not be passed to b
On 10/23/18 12:06 PM, Greg Wooledge wrote:
> On Tue, Oct 23, 2018 at 03:20:12PM +, Chen, Farrah wrote:
>> But in Bash script, it cannot work, it keeps its original value:
>> [root@fchen ~]# cat test.sh
>> #!/usr/bin/bash
>> echo $PS4
>> echo $FAN
>
> This is because you're doing it as root. B
On Tue, Oct 23, 2018 at 03:20:12PM +, Chen, Farrah wrote:
> But in Bash script, it cannot work, it keeps its original value:
> [root@fchen ~]# cat test.sh
> #!/usr/bin/bash
> echo $PS4
> echo $FAN
This is because you're doing it as root. Bash strips PS4 from the
environment when started as ro
On 10/3/14, 5:37 PM, Paul FM wrote:
> Bash Version: 4.2
> Patch Level: 47
> Release Status: release
>
>
>
> Description:
> When run as rbash, it parses then environment for functions when the
> man page specifically says it does NOT do this.
Yeah, that's a documentation problem. It's neve
On 10/03/2014 03:37 PM, Paul FM wrote:
>
> Bash Version: 4.2
> Patch Level: 47
You are several patches behind.
> Repeat-By:
> while running bash:
> export Y=\(\)\ \{\ ignored\;\ \}\;\ /usr/bin/id
This syntax no longer causes function parsing, as of 4.2 patch level 50.
--
Eric Blake ebl
Eric Blake wrote:
> This is a known issue, but NOT necessarily a security bug. In other
> words, it's no worse than running:
>
> env LD_PRELOAD=... ./test.sh
>
> with a malicious preload library. Remember, the security aspect of
> CVE-2014-6271 is that bash does unwanted parsing of the _content
On 09/26/2014 11:31 AM, Norihiro Tanaka wrote:
> I tried 4.3.25 in order to check the details of CVE-2014-6271, and
> confirmed that the bug is fixed with a test case.
>
> Next, I tried following case, and receive an output `rm -rf /'. I seem
> that is designed, but it's also vulnerable.
>
> $ c
Antonio Macchi wrote:
>
> $ declare +x x
>
> $ x=one
>
> $ ( echo $x; x=two; echo $x )
> one
> two
>
>
>
> subshell inherits "x"?
> is this behavior coherent?
User-specified subshells execute in an environment that is a duplicate
of the parent shell environment, with a couple of exceptions (
On 2009-02-13, Antonio Macchi wrote:
> i think that
>
> $ ( echo $x )
>
> is like
>
> $ bash -c 'echo $x'
it is confusing I agree. 'man bash' and look for the
section 'COMMAND EXECUTION ENVIRONMENT', which essentially
says that a simple command gets a different environment
(namely only the expor
The environment is designed to be inherited.
The subshell even inherits the shell variables.
I 'm not sure what causes you trouble here or what it could be incoherent with?
i think that
$ ( echo $x )
is like
$ bash -c 'echo $x'
I'm on error... but I can't understand why
On Fri, Feb 13, 2009 at 12:26 PM, Antonio Macchi
wrote:
>
> $ declare +x x
>
> $ x=one
>
> $ ( echo $x; x=two; echo $x )
> one
> two
>
>
>
> subshell inherits "x"?
> is this behavior coherent?
The environment is designed to be inherited.
The subshell even inherits the shell variables.
I 'm not s
12 matches
Mail list logo
