51–60 of 60 posts
Was this FOSS or commercial? If it's commercial software, you're paid to make it work, no matter how stupid that may be, and forced stupidity isn't your problem. If it's FOSS, you can tell the user to deal with it and close the ticket.
Earlier quoted context omitted.
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`.
I see you've never tried to run command --help | less
But the whole idea is that a warning is a warning. Solving a warning can be deferred, and a warning doesn't cause execution to fail. Your warning was transmuting itself into an error. I feel like "All means are fair except solving the problem" is the wrong conclusion to draw here. If it should have been solved immediately, it should have been an error in the first place. (And then you should have politely bumped the…
The warning was only "transmuting" itself into an error because another team took a dependency in their test on the exact ordering of writes of certain data to a globally shared resource.
But the whole idea is that a warning is a warning. Solving a warning can be deferred, and a warning doesn't cause execution to fail. Your warning was transmuting itself into an error. I feel like "All means are fair except solving the problem" is the wrong conclusion to draw here. If it should have been solved immediately, it should have been an error in the first place. (And then you should have politely bumped the…
The warning was only "transmuting" itself into an error because another team took a dependency in their test on the exact ordering of writes of certain data to a globally shared resource.
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.
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…
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…
I also include the runtime of the previous command which is useful to find out how long commands take without having to remember to time each one.
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…
I always change my bash PS1 prompt to include the exit code of the previous command, makes experimenting to write scripts so much easier. I also include the runtime of the previous command which is useful to find out how long commands take without having to remember to time each one.
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.
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…
> I was a real believer in printf() debugging but I deliberately switched to using a debugger This really does not need to be an either/or. They have different uses. You can stick in 20 printfs and get a quick feel for where the bug is far quicker than stepping through the code - especially if you set a breakpoint and hit run, only to realise that you've overshot. You can run the program 10 times with different param…