`echo_cmd` using stdout instead of stderr is kind of annoying.

[Thom Chiovoloni]

I use xshell in some projects that involve code generation. It's nice for these have a way to print the output to stdout, so that I can do just inspect it visually, or manually redirect it to a file, rather than have it always directly overwrite the output file.

This means in practice, at least for these scripts, all messages that aren't part of the actual output (e.g. informational stuff and verbose output), needs to use stderr. This isn't too bad, but echo_cmd only has options to use stdout/disable, and is on by default.

I don't know the best solution here. I'd rather not have to configure this on every invocation of xshell::cmd! (although it's fine if that's what you'd prefer — see option 4). Here are some solutions that come to mind:

1. Just changing it to use stderr always would obviously be fine by me, if you didn't have strong feelings about writing to stderr/stdout by default.

2. I think an cargo feature for it would work fine too — it's not exactly a normal feature use case, but I don't expect xshell to be used by libraries substantially separate from the original application.

3. If it were me, I'd also consider using a global AtomicBool for the default, and having a global function (Well, a static method on to xshell::Cmd) to set it to one or the other. This is rather cludgey, but would work, and isn't a ton of effort.

4. Having it be configured on a per-xshell::cmd! basis would be still be better than the status quo, since I could at least wrap it in a macro that configures it for me to always use stderr.

   I guess the most natural way this would look would be for echo_cmd to take Option<OutStream> (where enum OutStream { Stdout, Stderr }), but this is a breaking change (well, barring some trait shenanigans to allow it to still continue accepting a bool I guess). So, if you'd prefer this, let me know what the broad strokes of the API should be (e.g. accept Option, new function orthogonal to echo_cmd that does nothing if it's false, do trait shenanigans to avoid breaking changes while extending what echo_cmd accepts, ... etc)

   This has the benefit of being the only option that doesn't assume this should behave the same for all invocations of xshell::cmd!. I think that assumption is reasonable, but perhaps that's not a good assumption.

5. Having a cargo feature to use log! or something might work too, although I'm not already using log, and would need to do some finagling to make things work, since now I'd need to depend on log, and find or write a logger impl that uses stderr, and add code to enable it by default since I think that's useful still...

   So, while this is in some ways the most "correct" option, but would be my least favorite, since it's the biggest hassle. That said, it would still work.

Any of these would be fine by me, and I could contribute any of them if they'd be accepted. (It's more or less in the order that I find palatable, but that's also essentially the same as the order of "most work -> least work" in terms of using this)

Thanks.

[Thom Chiovoloni]

Oh, also, I wasn't sure what to name this issue. Feel free to rename — it's kind of negative as-is, which isn't really how I feel about xshell.

[Alex Kladov]

right, using stdout here is totally wrong. Heh, that's painful, it usually is me who says "stderr is not for errors, it's for humans". I guess we should just switch this around.

Out of curiousity, do you know which stream is used by bash's set -x?

[Thom Chiovoloni]

I just tested and it seems to be stderr.