stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <se...@roguewave.com>
Subject Re: svn commit: r463535 - in /incubator/stdcxx/trunk: etc/config/makefile.common etc/config/makefile.rules util/cmdopt.cpp util/display.cpp util/output.cpp util/runall.cpp util/target.h
Date Wed, 18 Oct 2006 23:06:38 GMT
Andrew Black wrote:

> Martin Sebor wrote:
> 
>> Andrew Black wrote:
>>
>> [...]
>>
>>> I believe the attached patch might be an option that doesn't rely on 
>>> bash, though it has a slight inelegant feel to it.  In particular, 
>>> the part reading '(echo $$cache > /dev/null)' is a hack to keep bash 
>>> from losing the cache variable in the pipeline (perhaps 'export 
>>> cache' should be used instead?).
>>
>>
>> I'm not sure I understand what this does. The pipe takes the
>> stdout of the echo $cache >/dev/null command, not that of the
>> prior command. Doesn't that lose the output of the compiler?
>>
>> Martin
> 
> 
> In my (somewhat limited) testing, it does not.  What is happening is 
> that the output of the list of commands is being sent through the 
> pipeline, rather than the output of the last command executed, 
> reflecting the bash documentation on pipelines.  It would be somewhat 
> possible to clarify this behavior by adding {}s around the compile 
> command and the output redirection sequence, but this would result in a 
> minor rethink of how to define redirected commands.


$ echo foo; echo bar | wc -l
foo
1

Here's a simple experiment that tries to duplicate what you're
doing in the patch. AFAICT, it doesn't behave the way we want.
What am I missing?

Martin

Mime
View raw message