command redirection operators

[carlobaldassi]

The current state of command redirections needs revision:

1. the operators for redirecting stderr (.>) and for appending (>>) must follow > and not be used anymore for redirection
2. it would be nice to have some way to manipulate descriptors, such as the equivalent of the bash redirections like 2>&1 and &> can be performed.

The two issues are related; the easiest solution to the first is of course to add |.> and |>> operators, but I doubt anyone likes that, and it still doesn't solve the second issue.

In #5344, Stefan has suggested

`head -c 1000 /dev/random` |> (1,f) |> (2,f)

as a possible syntax. Some time ago (#1271) I proposed using Dicts, which using a more recent syntax could read e.g.:

`cmd` |> [1=>"out.txt", 2=>"err.txt"]
`cmd1` |> [2=>1] |> `cmd2`

But I haven't given it much thought, and the second one is maybe a little weird. More opinions, proposals, comments etc.?

[johnmyleswhite]

I really like

`cmd` |> [1=>"out.txt", 2=>"err.txt"]

[stevengj]

It would probably be more clear to have

`cmd` |> [STDOUT=>"out.txt", STDERR=>"err.txt"]

[StefanKarpinski]

I hate that button placement.

[carlobaldassi]

It would probably be more clear to have

`cmd` |> [STDOUT=>"out.txt", STDERR=>"err.txt"]

This would be problematic since STDOUT and STDERR are TTY objects and can change programmatically (e.g. by redirect_stdout). One would need to use symbols instead, e.g. [:STDOUT=>"out.txt"] etc., but I'd prefer just :OUT or :out. This would not allow manipulating other file descriptors, but I suppose that's not a problem.

Anyway, the issues I see with such dict-based syntax are:

1. It still does not fully solve the first issue, since it's not clear how one would specify a file name to append to (barring |>> usage).
2. It may be unclear whether to allow redirection of standard input on the rhs, which looks weird: ``cmd |> [:in=>"in.txt", :out=>"out.txt"].

[JeffBezanson]

It feels strange to pipe a command into a dictionary. Maybe something like
redirect(cmd, stdout="file").
On Jan 29, 2014 4:49 PM, "Carlo Baldassi" [email protected] wrote:

It would probably be more clear to have

cmd |> [STDOUT=>"out.txt", STDERR=>"err.txt"]

This would be problematic since STDOUT and STDERR are TTY objects and
can change programmatically (e.g. by redirect_stdout). One would need to
use symbols instead, e.g. [:STDOUT=>"out.txt"] etc., but I'd prefer just
:OUT or :out. This would not allow manipulating other file descriptors,
but I suppose that's not a problem.

Anyway, the issues I see with such dict-based syntax are:

1. It still does not fully solve the first issue, since it's not clear
   how one would specify a file name to append to (barring |>> usage).
2. It may be unclear whether to allow redirection of standard input on
   the rhs, which looks weird: cmd |> [:in=>"in.txt", :out=>"out.txt"].

Reply to this email directly or view it on GitHubhttps://github.com//issues/5349#issuecomment-33635011
.

[astrieanna]

Is this going to happen any time soon?

[StefanKarpinski]

We now have the 2 => f syntax to use, which would be nice here. Doesn't quite work with comma:

julia> :(`echo hello` |> 1=>"echo.out", 2=>"echo.err") |> dump
Expr
  head: Symbol tuple
  args: Array(Any,(2,))
    1: Expr
      head: Symbol =>
      args: Array(Any,(2,))
        1: Expr
          head: Symbol call
          args: Array(Any,(3,))
          typ: Any
        2: ASCIIString "echo.out"
      typ: Any
    2: Expr
      head: Symbol =>
      args: Array(Any,(2,))
        1: Int64 2
        2: ASCIIString "echo.err"
      typ: Any
  typ: Any

[JeffBezanson]

Yes, thanks for bringing this up.

I haven't worked it out fully, but I feel the best option is to make |> syntax for function call, and write something like

`echo hello` |> redirect(1=>"echo.out", 2=>"echo.err")

where redirect returns a closure that consumes a command, and yields another command (or "executable thing").