Comment by cocoto
15 hours ago
> The du options are: s to summarize and b to display bytes.
Small nitpick: Use long options and your code samples become self explanatory!
15 hours ago
> The du options are: s to summarize and b to display bytes.
Small nitpick: Use long options and your code samples become self explanatory!
This is one of my biggest pet peeves! I hate reading shell scripts which uses small options. It is okay to use short options when interactively using shell, but there is no excuse to not spend time and try converting a small options shell script to use long options if its going to be read by someone else, especially if you anyway have to write comments explaining it. The biggest part i hate is that, some utilities don’t have long option counterpart!
Another pain is when there's no long options to use and you want to leave comments to document the short options, bash doesn't have inline comments and multiline commands break if you try to comment a line. There's awkward and verbose workarounds like https://stackoverflow.com/questions/9522631/how-to-put-a-lin... but open to tips!
On the flip side, not everyone uses GNU coreutils (though I do on every machine that runs Git), and I wouldn't have been confident that "du -c" and "du --total" are fully interchangeable prior to reading the manual just now. For Git, he could have confidently used "git --message" instead of "git -m", but then again, I'm sure it would have surprised many Git users ("is that -m?").
I'd argue that short options aren't particularly more likely to be portable. Years ago I was debugging a CI issue that turned out to be caused by a script hard-coding the short option for base64 decoding, which was not compatible across the GNU and BSD versions (one of them used -d and the other used -D, I can't remember which was which, and that's basically the same issue honestly). I was trying to figure out if I needed to check MacOS versus Linux (I think I was fixing the newly-added MacOS job at the time) when I realized that they both used --decode as the long option, which meant that the long option being used originally would have prevented the issue in the first place.
That reminds me of a really horrible afternoon in pre-gpt devops when I learned to add
```bash
if [[ $OSTYPE == “darwin” ]]; then
fi
Assuming you have run `brew install gnutools` on your Mac that should enable local dev for scripts that run on Linux. Apple’s bsd sed fork is strange.
Not all short options are portable, but all POSIX options are short.
Yeah, we had "always use long options in scripts as self-documentation" in a style guide at my last place. (Sure they were often less familiar - "we don't expect you to know, we expect you to learn" was also developer guidance. Though I think we had one or two exceptions listed, I don't remember them off the top of my head...)
I always use long options when possible. I don’t need terseness, computers do. I wanna help future me figure out how to run something.