cabal run: "Preprocessing executable" message shouldn't be in stdout

[Rufflewind]

The Preprocessing executable 'X'... message is currently written to stdout, even for cabal run. This contaminates stdout, so cabal run cannot be used with any program that outputs program-readable through stdout (e.g. Pandoc filters).

$ cabal run 2>/dev/null
Preprocessing executable 'X' for
Y...
Running X...
^C
$ cabal --version
cabal-install version 1.24.0.2
compiled using version 1.24.2.0 of the Cabal library 

[hvr]

Would adding -v0 to cabal run help?

[Rufflewind]

It does work around the problem, yes.

[23Skidoo]

We discussed making -v0 the default for new-run to make it more usable in scripts/pipelines and decided against it. Normally you want to see compilation output, otherwise it can be hard to tell whether your program is running or still compiling. So you should use -v0 if you're piping the output of cabal run to other programs. We should change the help message for run/new-run to mention -v0.

[Rufflewind]

In any case, I think those messages are more appropriate for stderr, especially for a "wrapper" command like cabal run.

[23Skidoo]

I don't think so, GHC for example prints it compilation output to stdout and only actual error messages go to stderr.

[Rufflewind]

GHC doesn't wrap any programs though, which makes this a rather atypical situation. stderr doesn't necessarily mean "errors-only" -- it can be used for any kind of diagnostic message.

Other package managers do keep their stdout clean:

$ cargo run 2>/dev/null
[PROGRAM OUTPUT]

$ cargo run >/dev/null
    Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
     Running `target/debug/X`

$ pulp run 2>/dev/null
[PROGRAM OUTPUT]

$ pulp run >/dev/null
* Building project in /home/rf/stuff/jucys/tools
* Build successful.

$ stack build --exec X 2>/dev/null
[PROGRAM OUTPUT]

$ stack build --exec X >/dev/null
X-0.1.0.0: configure (exe)
Configuring X-0.1.0.0...
X-0.1.0.0: build (exe)
Preprocessing executable 'X' for X-0.1.0.0...
[1 of 1] Compiling Main             ( ... )
Linking .stack-work/dist/x86_64-linux/Cabal-1.24.2.0/build/X/X ...
X-0.1.0.0: copy/register
Installing executable(s) in
X/.stack-work/install/x86_64-linux/lts-9.0/8.0.2/bin

[23Skidoo]

OK, this is a more convincing argument. Making debug/info/... in D.S.Utils use stderr instead of stdout should be pretty easy. You'll also need to redirect the output of GHC from stdout to stderr (and make sure that it doesn't mess up coloured error messages) plus maybe fix a few places where we're using putStr[Ln] instead of debug/info/notice/... wrappers.

[ocharles]

I agree that this should be in stderr - the output of cabal run is whatever the thing being run outputs. The fact that things have to happen before running is information for a side channel.

[athas]

I also encountered this issue today. Like others, I suggest making cabal run output its own meta-output to stderr and leaving stdout for the application. I don't particularly care whether this is consistent across all cabal commands; it may be that cabal run is a special case.

[Zankoku-Okuno]

Any movement on this? I encountered this error today and am slightly annoyed I had to discover the problem through google rather than the help pages. I guess my brain didn't think to search for "verbose" when I wanted the output to be "quiet" <.<

Incidentally, stderr was invented for the sole purpose of placing diagnostics on it. Before stderr, diagnostics would appear on stdout, which would then wreak havoc with unsuspecting downstream processes. If diagnostics were on stderr as Nature™ intended, we wouldn't have to choose between diagnostics and integration testing during development of a partly-Haskell script.

[phadej]

With #6929 you'll be able to say

cabal run your-program -vnormal+stderr

and (most of) cabal-install output will go to stderr. Not inherited pass-through output though (e.g. if GHC compiles something). This is a start.
#5956 is one, and a follow up to allow configuring verbosity flags separately from levels. (So you could always have nowrap e.g. and -v2 won't undo it).

[athas]

What will the default behaviour be?

[rihardsk]

This is especially painful when running a single-file cabal script with the #! /usr/bin/env cabal shebang. It seems that there isn't a way (at least i couldn't find any) to pass the verbosity option to cabal run this way. If that's really the case, it makes cabal scripts somewhat useless for use-cases involving outputting to stdout.

[travv0]

@rihardsk You can do #!/usr/bin/env -S cabal run -v0

[rihardsk]

@travv0 oh, that does indeed suppress the cabal output, thanks! I retract my previous statement about the problem being worse for cabal scripts, but it would be a lot nicer if cabal messages didn't go to stdout by default, imo.