[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lost output from asynchronous lists

From: Eric Blake
Subject: Re: lost output from asynchronous lists
Date: Wed, 29 Oct 2008 06:22:37 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20080914 Thunderbird/ Mnenhy/

Hash: SHA1

According to Stephane Chazelas on 10/29/2008 3:32 AM:
>> Yes.  For shell portability, I'll write the first line as
>>   : > stdout
>>   : > stderr
>> though.
> Why?

It fails on old Ultrix sh, which can't redirect the same fd more than once
in a single statement.  But that platform is relatively dead these days.

>> +  ( $at_traceon; $1 ) >>"$at_stdout" 2>>"$at_stder1"
> I've not read the full code so I don't know what $1 may contain,
> but I wonder whether eval "$1" shouldn't be preferable here (in
> case $1 is meant to contain a shell command line as opposed to a
> space separated list of wildcards).

This is in the context of m4 macro-expanding text that ultimately results
in shell code.  $1 is an m4 argument that contains properly quoted shell
code, and not a shell argument.

>> -  ( :; $1 ) >"$at_stdout" 2>"$at_stderr"
>> +  : >"$at_stderr"
>> +  ( :; $1 ) >>"$at_stdout" 2>>"$at_stderr"
> What's the ":;" for?

A workaround to the bash 3.2 bug, fixed in bash32-030, where failure to
use :; prior to a compound command (except for a subshell) meant that bash
incorrectly returns status 0 if redirection fails.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


reply via email to

[Prev in Thread] Current Thread [Next in Thread]