Mike Frysinger wrote:
> Bob Proulx wrote:
> > $ env -i HOME=$HOME PATH=$PATH env | wc -l
>
> since the args are being passed on the command line and the shell
> itself isnt evaluating it, you'll want to make sure to quote them if
> you have spaces:
> $ env -i HOME="$HOME" PATH="$PATH" env | wc -
On Wednesday, June 23, 2010 00:42:19 Bob Proulx wrote:
> $ env -i HOME=$HOME PATH=$PATH env | wc -l
since the args are being passed on the command line and the shell itself isnt
evaluating it, you'll want to make sure to quote them if you have spaces:
$ env -i HOME="$HOME" PATH="$PATH" env | wc
Apparently this list doesn't set the Reply-To header, apologies.
-- Forwarded message --
From: Andres P
Date: Wed, Jun 23, 2010 at 12:10 AM
Subject: Re: How not to inherit any environment variable from parent process?
To: Peng Yu
On Wed, Jun 23, 2010 at 12:02 AM, Peng Yu wrote
Peng Yu wrote:
> I use bash --noprofile to start a bash session. Since this doesn't
> source any profile files, I'd think that no environment variable
> should be set. But I still see environment variables set. Are they
> inherit from the parent session. Is there a way to start a bash
> session wit
On Wed, Jun 23, 2010 at 12:32 PM, Peng Yu wrote:
> I use bash --noprofile to start a bash session. Since this doesn't
> source any profile files, I'd think that no environment variable
> should be set. But I still see environment variables set. Are they
> inherit from the parent session. Is there
I use bash --noprofile to start a bash session. Since this doesn't
source any profile files, I'd think that no environment variable
should be set. But I still see environment variables set. Are they
inherit from the parent session. Is there a way to start a bash
session without using parent environ
On 6/22/10 6:57 PM, Matthew Woehlke wrote:
> No question something bad is going on here.
You're right. I found and fixed it. It wasn't where I was looking
initially. The fix will be in the next bash release and may come out
as a patch.
> Also, when run under valgrind, I see a number of leaks
On 6/22/10 3:10 PM, Andres P wrote:
>> The exit status of the command substitution will ultimately be ignored
>> because it's part of an assignment statement on the LHS of a || list, so
>> the commands run in the command substitution inherit that state.
>>
>
> Thanks, this behaviour seemed strang
oyvi...@dhampir.no wrote:
Description:
When used in a script that iterates over several thousand lines of
logs or similar data, the bash string replacement functions seem to
leak memory. The Repeat-By list uses "ls -lR" to generate input, but
any data will do (try your system logs)
Repeat-By:
On Tue, Jun 22, 2010 at 2:21 PM, Chet Ramey wrote:
> On 6/22/10 12:51 AM, Andres P wrote:
>> Bash 4.1 does not set the ERR trap:
>
> It does, but remember that the ERR trap is only executed under the
> circumstances that would cause the shell to exit when set -e is enabled.
>
To clarify, I meant
On 6/18/10 10:05 AM, Dr. Werner Fink wrote:
> as now is visible the last command in the pipe sequence done
> in the bash is a real sub process whereas in the ksh it is not.
>
> The question rises: Why does the bash require a sub peocess/shell
> for the final command of a pipe sequence.
It's an i
On 6/18/10 5:34 AM, Freddy Vulto wrote:
> Within the bash-completion package
> (http://bash-completion.alioth.debian.org/), we're planning on prefixing
> all functions and variables to create some kind of namespace. The
> prefixes probably are going to be:
>
> bashcomp_
> BASHCOMP_
>
> A
On 6/22/10 12:51 AM, Andres P wrote:
> Bash 4.1 does not set the ERR trap:
It does, but remember that the ERR trap is only executed under the
circumstances that would cause the shell to exit when set -e is enabled.
>
> $ env -i HOME="$HOME" TERM="$TERM" bash3 <<\!
>
> set -o errexit
> set -o
At Tuesday 22 June 2010, Andres P wrote:
> On Tue, Jun 22, 2010 at 4:45 AM, Stefano Lattarini
>
> wrote:
> >> ++ false # Subshell false
> >> +++ TRIGGERED_ERR # Ignores outer "|| true"
> >
> > No, it doesen't even see it; the script seen by the subshell
> > consists just of the string
On Tue, Jun 22, 2010 at 4:45 AM, Stefano Lattarini
wrote:
>> ++ false # Subshell false
>> +++ TRIGGERED_ERR # Ignores outer "|| true"
> No, it doesen't even see it; the script seen by the subshell consists
> just of the string "false", so there is no `||' the subshell can see.
> And thi
At Tuesday 22 June 2010, Andres P wrote:
> Bash 4.1 does not set the ERR trap:
>
> $ env -i HOME="$HOME" TERM="$TERM" bash3 <<\!
>
> set -o errexit
> set -o errtrace
>
> TRIGGERED_ERR() { return $?; }
>
> trap 'TRIGGERED_ERR' ERR
>
> set -o xtrace
>
> var=$(false) || true
Here, the subs
16 matches
Mail list logo
