Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

All means are fair except solving the problem

yosefk.com

Post reply on HN
Print view View original

41–50 of 60 posts

Re: All means are fair except solving the problem

#41

Post by skydhash »

dylan604 wrote: post #37
anyfoo wrote: post #15

Does no one know what exit codes and stderr vs. stdout is anymore? I work with old and new code bases used by many clients in complicated setups, but adding a warning to stderr while stdout was left untouched, and proper exit codes maintained, was hardly, if ever, a problem so far. Of course, there's always some unpleasant exception, but it's rare. And of course, I also understand that the author might have found the…

> Does no one know what exit codes and stderr vs. stdout is anymore? Sounds like you don't use ffmpeg very often. Because ffmpeg is able to send its output to stdout to be piped to other apps, verbose text output can't use stdout as one would expect. Non-error text is sent to stderr instead. So when you want to trap the text output you have to route stderr to text file. It takes some getting used to, but it's now nor…

I've just checked the man page for ffmpeg and they have a `-report` flag to capture the log. There should be no need to redirect stderr.

Re: All means are fair except solving the problem

#42

Post by ramses0 »

anyfoo wrote: post #17
ryandrake wrote: post #12

Earlier quoted context omitted.

Another thing that gets screwed up a lot is: Comand line usage help/information should be printed to stderr if it was invoked because the user passed an invalid option to the command line (in other words, the usage text counts as diagnostic[1] info), but it should be printed to stdout if the user invoked the application with -h, --help or similar. Reasons: 1. If you mess up the command line to the program in a script…

Disagree. stdout is only reserved for actual processed command output. It may be empty, it may be invalid because the input was invalid (shit in, shit out), but it may never be things intended for a human to read. If one wants to use a pager (like I sometimes do, though most of the time I just scroll up), they'll just use `foo 2>&1 | less`.

In the case of `git log -100 | grep FOO`, the log output should go to stdout.

In the case of `git diff | grep FOO`, the diff output should go to stdout.

In the case of `git --help | grep FOO` the help output should go to stdout.

In the case of `git --omg-wtf | grep FOO`, it's fine if there is only output on stderr.

Re: All means are fair except solving the problem

#43

Post by anyfoo »

dylan604 wrote: post #37
anyfoo wrote: post #15

Does no one know what exit codes and stderr vs. stdout is anymore? I work with old and new code bases used by many clients in complicated setups, but adding a warning to stderr while stdout was left untouched, and proper exit codes maintained, was hardly, if ever, a problem so far. Of course, there's always some unpleasant exception, but it's rare. And of course, I also understand that the author might have found the…

> Does no one know what exit codes and stderr vs. stdout is anymore? Sounds like you don't use ffmpeg very often. Because ffmpeg is able to send its output to stdout to be piped to other apps, verbose text output can't use stdout as one would expect. Non-error text is sent to stderr instead. So when you want to trap the text output you have to route stderr to text file. It takes some getting used to, but it's now nor…

That is exactly what I expect, or did I misread you? I expect its text output on stderr, and stdout being reserved for its video (or whatever) output.

Maybe the name “stderr” is a bit misleading. It’s totally common for non-error output to be in stderr as well, like verbose/debug logging.

Re: All means are fair except solving the problem

#44

Post by shoo »

m463 wrote: post #30

I have seen this kind of thing go so many ways. - sometimes you can get the status code, sometimes you can't. - sometimes you can separate out stdout from stderr, sometimes you can't - sometimes the program generating the error message identifies itself, sometimes it doesn't - sometimes you don't know if you have a "good error" (ok to ignore) or a "bad error" (cannot ignore) I am a fan of the HARD FAIL. I think inter…

> I am a fan of the HARD FAIL.

It reads as if the change was made to some library code that was depended upon by someone else's program that would "yay, done", which was in turn depended on by some workflow.

It's probably a non-starter to change library code so it hard fails if it detects its being used incorrectly, in situations where it previously ran and did something. That's a severe breaking change in behaviour.

Easing it in by printing a warning message sounds like a reasonable step toward hard failing. But then we get the situation yosefk relates.

Re: All means are fair except solving the problem

#45

Post by hiAndrewQuinn »

PaulHoule wrote: post #2

Aren't you supposed to return a 0 status code when "yea done!" and some other status code when it wasn't done?

There is a parallel universe where the convention is that 0 is used for when something went wrong, and 1-127 are reserved for all the myriad and beautiful ways in which things went right.

Re: All means are fair except solving the problem

#46

Post by JanneVee »

We even have the options around in our compilers to treat warnings as errors. As continuation on that idea I for one was lucky earlier in my career to work with the brilliant idea of just asserting in production. Straight up crash the software when something was wrong. Wrong preconditions that could mess something in the future. "empty array where it isn't supposed to be empty, sorry crash - fix your bug". even when it kind of worked, which is the real issue... it kind of works until it doesn't. I've silently introduced this mindset into my work ever since and the quality of the result is so much better. Warnings are something that will be deferred when given the option so don't warn it is an error.

Re: All means are fair except solving the problem

#47

Post by IsTom »

dylan604 wrote: post #38
ryandrake wrote: post #12

Earlier quoted context omitted.

Another thing that gets screwed up a lot is: Comand line usage help/information should be printed to stderr if it was invoked because the user passed an invalid option to the command line (in other words, the usage text counts as diagnostic[1] info), but it should be printed to stdout if the user invoked the application with -h, --help or similar. Reasons: 1. If you mess up the command line to the program in a script…

> 3. Generally, you can always tell if something is going wrong by grepping for errors or warnings a single stream (stderr), or by looking for a nonzero exit code. I'll use ffmpeg as an example of being an edge case. It's hard to get ffmpeg to give a nonzero exit code. What might be a problem for the user wasn't necessarily a problem for the app, so the app thinks it is completed and does its thing exiting with zero.…

Last time I had that problem -xerror helped.

Re: All means are fair except solving the problem

#48

Post by bitwize »

XorNot wrote: post #5
PaulHoule wrote: post #4

Earlier quoted context omitted.

I can say up until 2005 or so I was a real believer in printf() debugging but I deliberately switched to using a debugger as much as possible around that time. I found that no matter how hard people "try" if they modifying the code to do debugging there is some chance these get checked in -- whereas you can investigate many things with the debugger without checking anything it. Some applications have more trouble wit…

We still seem to have fairly bad tooling for advanced debugging use cases. There's no good reason you shouldn't be able to have an IDE maintain a text overlay of debugging points which is solely supplied as breakpoint scripts to the debugger instead. IDEs seem to conk out at click to set breakpoint.

That has literally been table stakes for Windows development since the 90s.

Not having the debugger fully integrated into your integrated development environment is strictly a problem of the commercial Unix and open source crowd and their "Real Programmers are fine with stone knives and bearskins" machismo.

Re: All means are fair except solving the problem

#49

Post by archargelod »

anyfoo wrote: post #17
ryandrake wrote: post #12

Earlier quoted context omitted.

Another thing that gets screwed up a lot is: Comand line usage help/information should be printed to stderr if it was invoked because the user passed an invalid option to the command line (in other words, the usage text counts as diagnostic[1] info), but it should be printed to stdout if the user invoked the application with -h, --help or similar. Reasons: 1. If you mess up the command line to the program in a script…

Disagree. stdout is only reserved for actual processed command output. It may be empty, it may be invalid because the input was invalid (shit in, shit out), but it may never be things intended for a human to read. If one wants to use a pager (like I sometimes do, though most of the time I just scroll up), they'll just use `foo 2>&1 | less`.

> stdout is only reserved for actual processed command output

If user asks a program to print help message, the help text is the processed command output!

Re: All means are fair except solving the problem

#50

Post by ninkendo »

One should always imagine a 1000:1 ratio of “person who reads a warning message” to “person who can do anything about it”.

You drop a little stderr print in your library saying “foo is deprecated, please use bar”, but then that library is included in another library which included in a CLI called by a script somewhere and, now the output goes to someone’s terminal when they’re running some management CLI. They never wrote the call to foo, they don’t even know what a foo is, they are 3 layers removed from who the target audience is.

Runtime is never the time to alert to things like deprecations or “this shouldn’t be used this way” notices. For deprecations, use your language’s built-in way of making functions deprecated. If your language doesn’t have that, use a real programming language. For other types of warnings, if you’re not 100% sure your message will only be seen by the developer who can fix it, just don’t write it.

Post reply on HN