The subshell execution parentheses and the colon are superfluous here, just:
< dataset.json && echo YES
> ( : >> result.json ) && echo YES # is result.json writable?
As a go-to idiom for a writability test, it gives me pause. If the file didn't exist, we created a zero-length one. That might be okay if we are going to write to it anyway as the next action.
If we are testing because we intend to overwrite it, why not just "> result.json" (which is by itself an idiom for truncating a file to zero length).
When would we every do this? Maybe before some command which takes the file name as a destination file argument rather than using output redirection, and which performs a lengthy computation before trying to open the file for writing. We can catch the permission error early.
I don't think I've ever coded such a test; normally you just do the operation that writes to the file and let that fail.
In POSIX C, there is a function access() for doing these kinds of tests. But it has a special purpose: it is meant to be used by a setuid root process to perform a permission test as if it were the real user/group (the one which elevated privilege to root). I.e. it's not can we do this operation, but should we do this operation (would we still be allowed, if we dropped privileges back to the original user).
zsh% echo "hello world" > data
zsh% < data && echo "READABLE" # <- will print the contents of data
hello world
READABLE
zsh% : < data && echo "READABLE" # <- this will not
READABLE
---
and given that we use the null-command, it _WILL_ behave different with or without subshell.. and all you need is `bash --posix` to prove it:
% cat subshell.sh
#!/bin/bash --posix
( : < missing.json ); echo AFTER # <- will echo AFTER
% ./subshell.sh
./subshell.sh: line 2: missing.json: No such file or directory
AFTER
% cat no-subshell.sh
#!/bin/bash --posix
: < missing.json; echo AFTER # <- this will not
% ./no-subshell.sh
./no-subshell.sh: line 2: missing.json: No such file or directory
% : ^- apparently.. there is a difference
---
One should never trust things just because they are written, but that also applies to comments on HN. Originally when I read your message I actually thought I made a mistake, I was very close to writing an apology comment and adding a note to the blog post, but not close enough - I had to test it again.
I'm thankful for the watchful eyes and scrutiny when reading things online, that's good - keep it up, but your message is factually wrong - on so many levels.
One of the reasons I stopped writing.
Fast-forward to seeing that comment climb up the ranks, posted by a person who has 270x my karma, who seemingly gets upvotes by just.. writing things? no proof? no rationale? nothing?
Yeah, feels bad. I'm super happy so many are enjoying the article, and this situation can't take too much away from that, but man.. discouraging for sure.
Or, you might not even write that something yourself; you just understand why it is that way and leave it alone in the refactoring that you are doing; then you get a review comment like "you can get rid of this from here", and you have to respond "no you can't, because ...".
> Yeah, feels bad. I'm super happy so many are enjoying the article, and this situation can't take too much away from that, but man.. discouraging for sure.
Again, don’t worry too much about that. The story got upvoted to the front page and lots of people will read it, that’s what matters. Not that a misguided post got a bunch of upvotes.