221–230 of 262 posts
Earlier quoted context omitted.
given that the sole purpose of software is to do what people want, "it didn't do what i want" is automatically incorrect behavior
So that would mean as soon as your software has 2 users, it is broken because it doesn’t conform to their 2 (different) imaginary specs?
This is interesting because it's not clear "who owns" that error, the program itself or the shell that sets up the redirection.
I find the argument that the code obviously ignores the error so that's obviously the program's intent to be completely spurious. The code "obviously" intends to print the string, too, and yet in some cases, it doesn't actually do that. It's clearly a bug. I don't think it's particularly useful to harp on this bug in the most introductory program ever, but it's definitely a bug.
Earlier quoted context omitted.
For didactic reasons it’s preferable to consider it a bug.
hello.c is meant as the first program a new student encounters when learning C. At that point, the student has enough to worry about; writing code to a file, checking for syntactic errors, basic program structure, using the compiler, executing the binary, understanding what `#include ` means,... Sure, we could update it: // hello_v2.0.c #include #include #include int main(void) { printf("Hello, World!\n"); fflush(std…
Earlier quoted context omitted.
> some other people disagree and say you should never use `set -e` outside of development I'm really interested. What are their arguments? And how do they handle errors?
See https://mywiki.wooledge.org/BashFAQ/105 for examples of side effects. I think the idea is you use set -e during development to find where you should catch errors, but in production you may want it off to reduce strange side-effects (or explicitly check for success in the way you expect; so not that the command returned 0 but that the file it made exists and is the right length, etc).
Earlier quoted context omitted.
See https://mywiki.wooledge.org/BashFAQ/105 for examples of side effects. I think the idea is you use set -e during development to find where you should catch errors, but in production you may want it off to reduce strange side-effects (or explicitly check for success in the way you expect; so not that the command returned 0 but that the file it made exists and is the right length, etc).
> not that the command returned 0 but that the file it made exists and is the right length If a command returns 0 when it didn't really do its job. Shouldn't we fix the command instead of the script?
0. https://www.grammar-monster.com/lessons/commas_with_vocative...
Earlier quoted context omitted.
hello.c is meant as the first program a new student encounters when learning C. At that point, the student has enough to worry about; writing code to a file, checking for syntactic errors, basic program structure, using the compiler, executing the binary, understanding what `#include ` means,... Sure, we could update it: // hello_v2.0.c #include #include #include int main(void) { printf("Hello, World!\n"); fflush(std…
Your usage of errno can cause failure on success if errno was set any time before the call to fflush. Might need a bump to v3 for robustness...
> The value of errno is 0 at program startup, and although library functions are allowed to write positive integers to errno whether or not an error occurred, library functions never store 0 in errno.
https://en.cppreference.com/w/c/error/errno
So this program correctly tests whether printf or fflush wrote to errno. You just can't refactor it into a function you call not at startup... I suppose that is unless you're keeping to a convention where you always set errno back to 0 after any call that might have set it...
The author missed another bug, which many others do. You need a comma after Hello, as in "Hello, World!" because it's a direct address. Very, and I mean VERY few books get this right. 0. https://www.grammar-monster.com/lessons/commas_with_vocative...
You all joke that this doesn’t happen in practice, but something like this literally just bit me and it took me a few too many minutes to figure out what was going on. I use a bash script as my BROWSER which calls another bash script to launch or communicate with my browser that I run inside a container. The script that my BROWSER script calls has some debug output that it prints to stderr. I use mutt as my email cli…
If we accept the idea that the function (non-coding use of the word) of an language's indication of success should - indicate success (or its absence) - of a piece of code, then surely the creators of the languages should make it do just that. That's their job right no? What am I missing?