stdin broken since release 0.2.3

[rudolphfroger]

Since 0.2.3 the run function now uses output_impl and output_impl is missing the option to allow stdin to be Stdio::inherit(), which I guess should have been the default behaviour. In practice this breaks interaction with commands being executed by run.

I think https://github.com/matklad/xshell/blob/master/src/lib.rs#L1011-L1014 should account for the case where one wants stdin to be inherited. So possibly output_impl also needs a ignore_stdin argument to switch stdin to Stdio::none(). If you want I can write a piece of code to demonstrate the bug.

[rudolphfroger]

I've written a snippet to demonstrate the problem:

fn main() {
    let sh = xshell::Shell::new().unwrap();

    let cmd = xshell::cmd!(sh, "test -t 0");
    let result = cmd.run();
    println!("test if stdin is open and associated with a terminal: {result:?}");

    let cmd = xshell::cmd!(sh, "cat");
    let result = cmd.run();
    println!("{result:?}");
}

xshell 0.2.3, doesn't wait for input and gives:

$ test -t 0
test if stdin is open and associated with a terminal: Err(command exited with non-zero code `test -t 0`: 1)
$ cat
Ok(())

xshell 0.2.2, does wait for input and outputs:

$ test -t 0
test if stdin is open and associated with a terminal: Ok(())
$ cat
^C

As expected I had to C-c to stop cat from reading from stdin.

All functions using output_impl() have this problem (also in 0.2.2) it's just that in 0.2.3 run() also started to use output_impl().

[matklad]

Stdin is intentionally not inherited by default. xshell is primarily oriented towards non-interactive usage in scripts or larger programs, and there accidentally inheriting stdin might cause a latent bug.

But adding a method to control this behavior, to enable inheriting of stdin, would be useful!

There's also a bigger issue that our overall semantics with inheriting/dev/nulling standard streams seems alll over the place. Eg, the read would inherit stderr, which also feels error prone....

So, it seems like it might make sense to overhaul the overall streams behavior here, to make it more predicatble and robust. The following would make sense to me:

• Default behavior is to /dev/null stdin, pipe stdout/stderr, but return an error if those are non-empty.
• Each stream then has inherit/ignore toggles

The run is thus split into two methids with TBD names:

• one runs command silently just for side-effects (you use that from the guts of a complex system)
• one echos the command itself, and inherits its streams (you use that for "scripting", to show the resulting logs to the user (eg, in CI)).

We might actually extend this split to non-run commands like read? If I do

let pkgid = cmd!(sh, "cargo pkgid").read()?;

In my CI, I'd probably would love to both:

• See

  $ cargo pkgid
  file:///home/matklad/p/xshell#0.2.5
  

  printout

• get the actual string value

This requires some fancy tee-ing of the stdout.

This large overhaul would require 0.3 of course. Toggling just stding inheritance would be a minor patch though!

[blckngm]

Some programs use whether the stdin is a tty to decide whether to turn on color output. I had to stay on 0.2.2 for this.

[rudolphfroger]

This large overhaul would require 0.3 of course. Toggling just stding inheritance would be a minor patch though!

It would be great if this could be added with a simple method.

[maxcountryman]

Chiming in to mention this is important for e.g. CLIs like tailwindcss: without TTY, the --watch flag doesn't work at all.

[matklad]

pipe stdout/stderr, but return an error if those are non-empty.

I've since learned that checking for empty stderr is a wrong thing to do.

While you do generally expect my-command do-thing to return with zero and have empty stderr, there are annoying edge-cases.

For example, it might turn out that my-command is a tool managed by some version manager, like rustup, and, when you run my-command do-thing, the command itself has empty stderr, but you still get

my-command v6.6.6 not found locally
downloading my-command v6.6.6

stderr printouts from that version manager.