Went to try to update some of my scripts and stuff and found that most of OS X/macOS uses BSD utils which don't have the long flags found in linux versions. For example check out xargs:
Use long flags when scripting (2013)
121–130 of 197 posts
Re: Use long flags when scripting (2013)
#122It’s not just “easier for a human” but more stable over time as commands evolve, and less likely to do weird things across Unix variants. Some command-line parsers will auto-complete partial options so you’re less likely to see ambiguity errors in future versions if you picked long-form options. (This isn’t completely foolproof, e.g. a command could have "--foo" and later add "--foobar" but it does help in most cases…
Unfortunately, this isn't quite true. At least if by Unix you mean POSIX, i.e. you include macOS in your considerations.
1. Sadly, short options are in fact more portable than long options if you're targeting POSIX. For instance, macOS ships with versions of ls, rm, et cetera that only support short flags. This is because long options don't exist at all in POSIX (they're formalized here: https://pubs.opengroup.org/onlinepubs/009695399/functions/ge...).
2. Auto-completing partial options only happens for long flags, and it's a bit more than "some" parsers; the canonical implementation of "long" options, GNU's getopt_long, has it as a documented feature:
> Long option names may be abbreviated if the abbreviation is unique or is an exact match for some defined option.
https://linux.die.net/man/3/getopt_long
I 100% agree it's a poor feature. You basically entirely preclude yourself from adding features in a backwards-compatible way.
Re: Use long flags when scripting (2013)
#123This is how I write PowerShell scripts. I use full cmdlet names, full argument switch names, and I even specify argument switches to positional arguments. I also do my best to honor common flags like `-WhatIf`, `-Verbose`, and `-ErrorAction`. So I end up with scripts like this: if (-not $(Test-Path -Path "$Path" -PathType Container)) { Write-Error -Message "Path ($Path) does not exist or is not a directory." -Categor…
PS has another reason to use full names of parameters in long-lived scripts. If you use short names like `-Ver` expecting it to match `-Verbose`, a future version of the commandlet can add `-Version` and now `-Ver` is ambiguous. On the other hand, I've seen some people eschew `%` and `?` in favor of writing `ForEach-Object` and `Where-Object`, which in my opinion is too extreme in the other direction. BTW, in: if (-n…
To me this isn't just another reason, it's THE reason to not use the short form in scripts. Although unlikely, the worst case of this could be pretty nasty. It's possible for someone to remove a flag that was deemed useless and add another flag that matches the same prefix and has a very different effect.
I don't know how to feel about % and ?. The thought with not using them is that they are just aliases and could be changed. But that reasoning sort of breaks down since any command could be aliased to something dumb like `Set-Alias Get-Content Remove-Item`.
Re: Use long flags when scripting (2013)
#124Earlier quoted context omitted.
Recent (as in, within the last ~3-5 years) versions of GNU tar automatically detect the type of compression and apply the appropriate tool, so you can often get away with `tar xvf`.
Actually close to 12 years, GNU tar 1.21 https://www.gnu.org/software/tar/ Another "recent" (much more recent IIRC) change is that you don't need the dot anymore in find to search in the current directory.
I think the dot actually gives you issues on Mac? Or something like that. I remember encountering issues with it.
Re: Use long flags when scripting (2013)
#125This is how I write PowerShell scripts. I use full cmdlet names, full argument switch names, and I even specify argument switches to positional arguments. I also do my best to honor common flags like `-WhatIf`, `-Verbose`, and `-ErrorAction`. So I end up with scripts like this: if (-not $(Test-Path -Path "$Path" -PathType Container)) { Write-Error -Message "Path ($Path) does not exist or is not a directory." -Categor…
While developing a script I write them in short form then when it’s close to done I let vs-code help me convert them to long form. This way I write fast but leave a nicer product.
Re: Use long flags when scripting (2013)
#126never thought about that. I usually try to keep my code short to try to impress other programmers, but that's really good advice
Re: Use long flags when scripting (2013)
#127Re: Use long flags when scripting (2013)
#128Earlier quoted context omitted.
Does anyone care about the standard? Let's be honest it's outdated, has a bad UX and is with the standards I would hold such a standard against today generally not so good. Sure systems seen try to somewhat be POSIX compliance but from my experience not because they care about POSIX but because that happen to overlap with the idea to be somewhat compiland with other similar systems so that porting software/scripts is…
Yes, if you care about portability. Anything that's not Linux likely won't have GNU grep installed by default. This includes macOS and the BSDs. If this is your own dotfiles or utilities, sure, but if I'm working on something collaborative, yes, I care about the standard.
I stick to POSIX in my dotfiles precisely because I carry it around on many different systems and that’s the only thing that can keep it sane.
Re: Use long flags when scripting (2013)
#129If you're trying to stick to the POSIX standard, you have to use short options for standard commands like grep, since the long options are GNU extensions.
Does anyone care about the standard? Let's be honest it's outdated, has a bad UX and is with the standards I would hold such a standard against today generally not so good. Sure systems seen try to somewhat be POSIX compliance but from my experience not because they care about POSIX but because that happen to overlap with the idea to be somewhat compiland with other similar systems so that porting software/scripts is…
fish shell has been burned in the few places it strictly implements POSIX.
The most vivid example is test, aka /bin/[. POSIX specifies that, if test is invoked with one argument, you must "Exit true (0) if $1 is not null; otherwise, exit false" [1].
This means that `test --help` is forbidden from printing any help. It means that `test -d $argv` expands to `test -d` if $argv is empty, which then must "succeed" because "-d" is not null. It bites users over and over again [2].
Implementing this POSIX piece has resulted in more headaches, not fewer. I regret implementing a POSIX-conformant test, I wish I had just picked mostly-compatible but also-sane semantics.
1: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/t...
2: https://stackoverflow.com/questions/29635083/fish-shell-chec...
Re: Use long flags when scripting (2013)
#130I have been following this advice for about five years with my scripts and the best result has been compliments from co-workers and others who have picked up the scripts and felt like they had a much better understanding of what the scripts were doing. Combined with use of shellcheck and shfmt working in shell scripting has come a long way in the last couple years. I still feel like BASH is a dead end--the quoting an…
It's so unfortunate about Bash + Apple. Bash probably deserves to die out, but Apple has really pulled a bait-and-switch on OSX's *nix/bsd underpinnings over the years.
Die out and be replaced by what?