On 10/17/14, 11:34 AM, Greg Wooledge wrote:
> 3) Everything else. These are ignored.
>
Not quite. Bash saves them and adds them to the environment it passes to
the external commands it invokes. Bash is transparent with respect to
environment variables it doesn't handle.
Chet
--
``The lyf so
On 10/17/14, 11:22 AM, lorenz.bucher@rohde-schwarz.com wrote:
> No, I can't.
> $ foo%%="bar"
> foo%%=bar: command not found
You just demonstrated what I wrote:
> No, shell variable names should continue to be shell identifiers. You
> can already use `%' (any character, really) in environmen
On 10/16/14, 4:37 PM, Geir Hauge wrote:
> Regardless though, shouldn't source <(declare -xp) work whether or not
> the environment contains invalid identifiers? It doesn't at present:
>
> $ env %=% bash -c 'echo "$BASH_VERSION"; source <(declare -xp)'
> 4.3.30(1)-release
> /dev/fd/63: line 1: dec
On 10/16/14, 12:38 AM, idal...@idallen.ca wrote:
> Bash Version: 4.2
> Patch Level: 25
> Release Status: release
>
> Description:
>
> If a bash shell script starts up with TSTP ignored, commands run by that
> script will not ignore TSTP, even if you set a trap in the script to
> ignore TSTP. If
Awesome - Thanks everyone for the help! I will forward these responses
on to the security group. But again, Thank you everyone!!!
-Dave
On 10/17/14, Andreas Schwab wrote:
> Eric Blake writes:
>
>> The following is a better test for whether CVE-2014-7187 can be
>> exploited to remotely attack yo
> Von:Chet Ramey
> No, shell variable names should continue to be shell identifiers. You
> can already use `%' (any character, really) in environment variable
> names.
On Fri, Oct 17, 2014 at 05:22:30PM +0200, lorenz.bucher@rohde-schwarz.com
wrote:
> No, I can't.
> $ foo%%="bar"
> foo%
No, I can't.
$ foo%%="bar"
foo%%=bar: command not found
Or better said not in the normal way
$ set foo%%=bar
--
Mit freundlichen Grüßen
Lorenz Bucher
TechConnect GmbH
Im Auftrag der/on behalf of
Rohde & Schwarz GmbH & Co. KG
Postfach 80 14 69 • 81614 München
Mühldorfstraße 15 • 81671
Eric Blake writes:
> The following is a better test for whether CVE-2014-7187 can be
> exploited to remotely attack your system:
>
> f='() { echo vulnerable; } bash -c f
Missing quote character.
f='() { echo vulnerable; }' bash -c f
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key f
On 10/17/2014 08:18 AM, Greg Wooledge wrote:
> On Fri, Oct 17, 2014 at 10:10:36AM -0400, Dave Kalaluhi wrote:
>> Locally we are using:
>>
>> (for x in {1..200} ; do echo "for x$x in ; do :"; done; for x in
>> {1..200} ; do echo done ; done) | bash ||
>> echo "CVE-2014-7187 vulnerable, word_lineno"
On Fri, Oct 17, 2014 at 10:10:36AM -0400, Dave Kalaluhi wrote:
> Locally we are using:
>
> (for x in {1..200} ; do echo "for x$x in ; do :"; done; for x in
> {1..200} ; do echo done ; done) | bash ||
> echo "CVE-2014-7187 vulnerable, word_lineno"
As mentioned in previous emails on this topic, tha
I guess that would help. I meant to include that in the initial mail,
but alas, running in 50K directions.
Locally we are using:
(for x in {1..200} ; do echo "for x$x in ; do :"; done; for x in
{1..200} ; do echo done ; done) | bash ||
echo "CVE-2014-7187 vulnerable, word_lineno"
If we run the t
11 matches
Mail list logo
