← Back to context

Comment by zetanor

11 hours ago

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?").

3 comments

zetanor

Reply
saghm  6 hours ago

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.

  • reilly3000  5 hours ago

    That reminds me of a really horrible afternoon in pre-gpt devops when I learned to add

    ```bash

    if [[ $OSTYPE == “darwin” ]]; then

      alias sed=gsed

    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.