moonscript
moonscript copied to clipboard
Print output to stdout (not stderr)
When building large numbes of files, I wanted to redirect the output to /dev/null, and I discovered it was actually being printed to stderr, not stdout. Is there any reason for this? I don't see any. Please print regular operation logs on stdout, and leave stderr for actual errors.
I assume you're talking about the compilation process. Since I sometimes use the option of printing the compiled Lua on stdout, how do you suggest that should work if it is intermixed with logs?
@johnae Well with that option, it should obviously keep printing to stderr or another stream (if that's even possible).
Definitely stderr should be for errors only when possible.
Using gcc as an example, it only writes to stderr. If you -need- to redirect to stdout just use 2>&1
.
@Guard13007 That seems unnecessarily complicated. There's no law here that says a program must print only errors on stderr.
@LudwikJaniuk What problem would this solve or does this improve some use case in any way?
Generally, for a program, I think silence is golden when there's nothing interesting to say (unless you're debugging). If there's anything meaningful to say, say it on stderr, if there's a fatal error, just exit.
Piping commands together doesn't work very well if the output is mixed with diagnostics.
@johnae The whole point of having stderr is for errors. There are no laws, but there are standards, and usually it causes problems to not follow standards.
I'm not saying diagnostics should be mixed with output, but there is a stream for errors, and a stream for standard output.
@Guard13007 Well, there are many examples out there of other uses. Ffmpeg for example prints all diagnostics on stderr.
What problem would a change like this solve? I'm not against using stderr for errors and stdout for diagnostics but I believe it depends on what the program actually does. GCC was also brought up as an example of diagnostics on stderr by @ChickenNuggers.
What problem would a change like this solve?
You can just check stderr for errors, and know if anything goes there, there's been an error.
As far as standards, well, I believe that throws my argument right out, that GCC and ffmpeg have this kind of behavior as well. I would expect them to get it right, so the fact that they don't leads me to believe there must be a reason for it. shrugs
Well, I didn't consider the situation of compilation output being printed to stdout. As some people say, I just assumed it was the standard to put only errors on stderr, and I had no idea that GCC for example did otherwise.
@johnae What problem would it solve? Less confusion. I think users writing shell scripts with it would face less confusion if the output was on stdout. But ultimately, yes, it's easy to work around, so no big deal.
moonc -p /path/to/file
seems to print to stdout for me.
@aleclarson that's not related; the supposed issue is that MoonScript errors are printed to stderr instead of stdout; however, printing MoonScript errors to stdout would actually break the -p
flag.
@RyanSquared I just read it again. It seems the problem is that "regular operation logs" are printed to stderr. It's not an issue that errors are printed to stderr, since that's what stderr is for. Either way, my bad! :)