Re: Bug report + feature request

Re: Bug report + feature request

[Sven Wischnowsky]

Sullivan N. Beck wrote:

> ...
> 
> Now for the feature request.  Since I'd actually like to separate and
> pipe STDOUT and STDERR separately to different commands (all of the
> above came about from various attempts to get this working) without
> resorting to fifos, intermediate files, etc., what I'd _really_ like to
> do is to be able to pipe different file descriptors similar to how I can
> redirect them to a file.  For example, I'd like to replace the following
> lines:
> 
>   COMMAND > /tmp/stdout 2> /tmp/stderr
>   cat /tmp/stderr | STDERR_COMMAND
>   cat /tmp/stdout | STDOUT_COMMAND
> 
> with the single line:
> 
>   COMMAND >| STDOUT_COMMAND 2>| STDERR_COMMAND
> 
> If this syntax isn't acceptable, that's fine with me.  Any syntax is
> fine.  I'd just like the functionality.

How should it find out if, in your example, STDERR_COMMAND should be
used for COMMAND or STDOUT_COMMAND?

But anyway... have you seen the >>(cmd) process substitution?
You can do:

  COMMAND >>(STDOUT_COMMAND) 2>>(STDERR_COMMAND)

or

  COMAMND 2>>(STDERR_COMMAND) | STDOUT_COMMAND

if you prefer.


Note to workers: in the info file, >>(foo) is shown as `> >(foo)'. Urgh.


Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Process substitution

[Bart Schaefer]

On Oct 6, 10:24am, Sven Wischnowsky wrote:
}
} Note to workers: in the info file, >>(foo) is shown as `> >(foo)'. Urgh.

That -is- the way it's parsed.  It works just fine to write it that way.

The nice thing would be if there were a way to wait for those jobs to
complete.  They run in the background (as they must, really) but they're
not entered into the job table.

BTW, it's fairly easy to get zsh to forget to delete a file created with
=(...).  Compare:

	cat <<<'bar' =(echo foo)		# temp file removed
	echo bar >> =(echo foo)			# temp file removed
	cat <<<'bar' >> =(echo foo)		# temp file remains

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Bug report + feature request

[Sullivan N. Beck]

I have found a bug in zsh.  I've got access to:
   zsh 3.1.5  on Solaris 2.6
   zsh 3.1.9  on Solaris 8, redhat 6.2, irix 6.5
and each of these suffers from the problem.

Basically, I want to switch STDOUT and STDERR so I pipe STDERR to some
other commands.  The following lines show what's happening to prevent me
from doing this (though I can do it in sh/ksh distributed with Solaris).

   echo '=1 ====='
   echo
   ls -l /tmp/z   | while read line ;do echo ":: "$line; done
   echo
   echo '=2 ====='
   echo
   ls -l /tmp/z/a | while read line ;do echo ":: "$line; done
   echo
   echo '=3 ====='
   echo
   ls -l /tmp/z   3>&1 1>&2 2>&3 | while read line ;do echo ":: "$line; done
   echo
   echo '=4 ====='
   echo
   ls -l /tmp/z/a 3>&1 1>&2 2>&3 | while read line ;do echo ":: "$line; done

produce

   =1 =====
   
   :: total 16
   :: -rw-r--r--   1 sbeck    apps         396 Oct  5 13:44 foo
   
   =2 =====
   
   /tmp/z/a: No such file or directory
   
   =3 =====
   
   total 16
   -rw-r--r--   1 sbeck    apps         396 Oct  5 13:44 foo
   :: total 16
   :: -rw-r--r--   1 sbeck    apps         396 Oct  5 13:44 foo
   
   =4 =====
   
   :: /tmp/z/a: No such file or directory

Notice that in the 3rd section, the output from the command ends up on
both STDOUT and STDERR.  All other shells (ksh, sh, bash) that I tested
give the correct output for the 3rd case:

   total 16
   -rw-r--r--   1 sbeck    apps         396 Oct  5 13:44 foo



Now for the feature request.  Since I'd actually like to separate and
pipe STDOUT and STDERR separately to different commands (all of the
above came about from various attempts to get this working) without
resorting to fifos, intermediate files, etc., what I'd _really_ like to
do is to be able to pipe different file descriptors similar to how I can
redirect them to a file.  For example, I'd like to replace the following
lines:

  COMMAND > /tmp/stdout 2> /tmp/stderr
  cat /tmp/stderr | STDERR_COMMAND
  cat /tmp/stdout | STDOUT_COMMAND

with the single line:

  COMMAND >| STDOUT_COMMAND 2>| STDERR_COMMAND

If this syntax isn't acceptable, that's fine with me.  Any syntax is
fine.  I'd just like the functionality.



Please reply to me as well as the list since I'm not currently subscribed
to this list.


--------------------------|  Sullivan Beck  |---------------------------
mailto:sbeck@cise.ufl.edu          |            Senior System Programmer
http://www.cise.ufl.edu/~sbeck     |               University of Florida
PH : (352) 392-1057                |                     CISE Department
Fax: (352) 392-1220                |                            CSE 314E
------------------------------------------------------------------------

Re: Bug report + feature request

[Peter Stephenson]

>    ls -l /tmp/z   3>&1 1>&2 2>&3 | while read line ;do echo ":: "$line; done
>    
>    total 16
>    -rw-r--r--   1 sbeck    apps         396 Oct  5 13:44 foo
>    :: total 16
>    :: -rw-r--r--   1 sbeck    apps         396 Oct  5 13:44 foo
> 
> Notice that in the 3rd section, the output from the command ends up on
> both STDOUT and STDERR.  All other shells (ksh, sh, bash) that I tested
> give the correct output for the 3rd case:
> 
>    total 16
>    -rw-r--r--   1 sbeck    apps         396 Oct  5 13:44 foo

That's not a bug, it's due to zsh's `multios' feature, where a repeated
mention of an fd means that it should be used twice:  on input this does
cat, and on output it does tee.  In this case fd 1 is used for copying to 2
and as a pipe, so stdout goes to both.  You need to `setopt nomultios' to
turn this off.

It's about time we had a `no_pipe_multios' option --- this gets so many
people (including me, before now).

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
Cambridge Silicon Radio, Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070