Eric Blake wrote:
Re-adding the list - I am not the bash maintainer, so keeping the list in
the loop is essential if you want any action taken.
I am the bash maintainer, so I figure my opinion will count for something.
| So there's a bug in the manual, which does not breathe a word about
| ti
Doug McIlroy wrote:
These two bash sequences are not equivalent.
My intuition and the bash man page tell me they should be the same.
% export X=x; time --version; unset X
-bash: --version: command not found
% unset X; X=x time --version
GNU time 1.7
They are not the same, and should n
Bob Proulx wrote:
> This implies to me that a variable assignment forces subsequent
> commands to be external commands because the current environment is
> not affected. In your case above the external /usr/bin/time program
> is forced by the variable assignment requiring the environment
> variab
Eric Blake wrote:
> Doug McIlroy wrote:
> | So there's a bug in the manual, which does not breathe a word about
> | time being executed by the shell. And the shell covers its tracks, too:
>
> Like I said, there's a difference between a builtin (for example,
> 'builtin' or 'exec') and a reserved w
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Re-adding the list - I am not the bash maintainer, so keeping the list in
the loop is essential if you want any action taken.
According to Doug McIlroy on 3/7/2008 9:12 PM:
| Thank you for the prompt reply
|
|> The difference in behavior is because t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Doug McIlroy on 3/7/2008 7:17 PM:
| These two bash sequences are not equivalent.
| My intuition and the bash man page tell me they should be the same.
|
| % export X=x; time --version; unset X
| -bash: --version: command not found
|
|
These two bash sequences are not equivalent.
My intuition and the bash man page tell me they should be the same.
% export X=x; time --version; unset X
-bash: --version: command not found
% unset X; X=x time --version
GNU time 1.7
Behavior observed in:
GNU bash, version 3.2.33(18)-relea
