Bash pipe syntax makes variables local, breaking sendfax scripts

• Messages sorted by:[ date ][ thread ][ subject ][ author ]

Hi,

Pilch wrote:
> BUG/PROBLEM REPORT
[..]
> It becomes clear that the `tee' pipe prevents the 
> declaration of E from being valid outside the curled bracket.

This is very clearly documented everywhere. The return code of the pipe is
the return code of the last program in it. It makes very much sense that
way. If you need the return code of preceding programs, use temporary files,
or construct your pipes in a way that the later programs will fail as well.

> The tee pipe unfortunately also changes the errorlevel of
> everything to 0.  A desirable Bash behavior would be to
> end with the first nonzero error code of the pipe chain.

No. This is not POSIX.

> Simple shell scripts like one for sending the remaining
> faxpages after an interruption become impossible.

Nonsense.

> Normally they could look roughly like this (using 
> Gert Doering's sendfax program):
> 
> <script(>
> 
> until test $# -eq 0 || sendfax -v $@ 2>&1 | tee LOGFILE;do
>   np=$(grep -c sending $LOGFILE);
>   n=1;while test $n -lt $np;do shift;let n=n+1;done;
>  done;

Oh my, just take a look at the manual, and at sendfax' "-r" option. With
this, it's very easy to do "incremental" fax sending. (Thanks to Matthias
Urlichs for the initial feature request!).

> This won't work first of all because of the tee pipe's error
> hiding behavior, secondly because there is no way to store 
> the error information in a variable.  The only workaround
> is to store it in a temporary file, as in the following bulky
> script:

Yes, but a script that relies on *informational* program output (which
isn't meant to be parsed by programs) is broken anyway.

Besides, there is no need for a "bulky" script. You could do it that way:

until test $# -eq 0 || sendfax -v $@ >LOGFILE 2>&1 ;do
  cat $LOGFILE
  np=$(grep -c sending $LOGFILE);
  n=1;while test $n -lt $np;do shift;let n=n+1;done;
done;

-- this will make it barely one line longer (but, admittedly, the output
of sendfax is somewhat delayed).

> Of course the whole script writing task would become very simple, if
> the sendfax program itself could be modified so that it read file
> names from and stored the names of the unsent files in an environment
> variable such as SENDFAXFILES.  You would then need to write only:

You can not store anything in the caller's environment. No way.

But anyway, this is exactly what the "-r" option is achieving, though it
does it in a different way.

> But even if all programs were so considerate, I would like a more
> powerful shell syntax.

If you're complaining about the shell, why are you sending this to the 
**MGETTY** mailing list??? Send it to "bash-bug@gnu.ai.mit.edu" and get
your lecture about POSIX from them.

gert

-- 
                                                            //www.muc.de/~gert
Gert Doering - Munich, Germany                             gert@greenie.muc.de
fax: +49-89-3545980 <---new!!!              gert.doering@physik.tu-muenchen.de