[judofyr]

It's a bit of a strange choice, but if you read the full documentation (man codesign) it's not too confusing actually:

    NAME
           codesign — Create and manipulate code signatures
    
    SYNOPSIS
           codesign -s identity [-i identifier] [-r requirements] [-fv] path ...
           codesign -v [-R requirement] [-v] [path|pid ...]
           codesign -d [-v] [path|pid ...]
           codesign -h [-v] [pid ...]
           codesign --validate-constraint path ...

The first argument to codesign has to be one of -s, -v, -d, -h, --validate-constraint and in reality it's closer to a subcommand (similar to how git as pull, push, merge etc). After that "-v" works as a regular option.

EDIT: I read the man page even further, and I was slightly wrong: It appears to be possible to pass regular options before the operation, but you're required to have one (and only) one operation.

[ahoka]

No, it's very confusing, especially for people who are used to tools built with GNU getopt.

[judofyr]

I too wish that command-line arguments were standardized, but alas, we were given `char *argv[]` and I've finally accepted (yes, I'm looking at you Go) that the only way is to read the documentation and type the command exactly as described, with dashes and equals intact :(

[MawKKe]

If you think about it, a CLI argument parser takes in a sequence of tokens and transforms the information into some kind of internal repsentation, which is then later interpreted. Just like what a compiler/interpreter does, except now the input is already tokenized. So there does not seem to be a practical way to "standardize" this interface any more than you can standardize a compiler for all languages.

It's kinda whacky to think about that every sufficiently complicated CLI app out there implements its own ad-hoc, informally-specified, bug-ridden, slow implementation of half of common lisp _just_ to prepare running the actual program payload...

[paulmd]

this isn’t a gnu userland, macos adheres to BSD style where order does sometimes matter. Sometimes specific things have to be first or last arguments etc, it’s not quite as freeform.

it’s understandable if you find it different/jarring but that’s the price of maintaining a consistent style - you don’t change tools that are already working fine just to chase fads.

[paulmd]

PS: not saying reusing a flag is a good idea, but like, macOS is not Linux, it’s Unix, and mostly it’s the exact same differences on FreeBSD or illumos or openbsd, because the syntax comes from AT&T Research Unix in the 1970s (the oldest known code in FreeBSD is around 1979 iirc, and there is a direct lineage back to sys-v). Obviously it’s a little different, but on the flip side this is how you avoid churn - you don’t change things just for change’s sake, and you fit into the existing style even if you don’t like it.

From the BSD perspective it’s like you’re coming in and shouting about rewriting everything in rust on your first day, especially since BSD does place a much higher emphasis on interface stability etc. For example unlike linux, BSD offers ABI stability, and that is one of the selling points for building something on top of it. Nor is there any systemd or upstart - or a million different directories and styles for conf files. rc.conf basically does almost everything you need for OS conf.

One net benefit is that it’s actually possible to write and maintain documentation, and it doesn’t bitrot in every single major release. Those FreeBSD forum posts from 2007 are still valid. And if you need to build some appliance that will be running unattended for years… BSD doesn’t churn like that.

But the price is you have to learn new syntax (really, the old syntax) for a half dozen system commands. Or just install the gnu version of those packages (“brew/portmaster install findutils gtar greputils” mostly covers it). It’s pretty much the first speedbump everyone hits on their first Unix, and it’s ultimately a trivial one, but yeah, there’s no desire or real reason to churn it either.

It’s the bazaar vs the cathedral, and the cathedral has some advantages too. You’d say code smell, I’d say fine patina. A lot of Unix code has had 30 or 40 years to work out the bugs and edge-cases in a controlled manner. It’s not worth losing that so newbies can have a little easier time their first week. Use gnu versions if there’s a pain point.

[KolenCh]

Portmaster?

[paulmd]

portmaster is a freebsd "package manager" for managing installation and uninstallation of ports. Sort of analogous to the "formula" function of brew where it's compiled in-situ... with your local march!

https://man.freebsd.org/cgi/man.cgi?portmaster

https://github.com/freebsd/portmaster

[KolenCh]

Oh, wow. Glad I asked. I thought you mean port but while they are related it is something I’ve never heard of.

Brew has transitioned into primarily bottled (pre-compiled binary). Compiling with the local march sounds great and it is quite difficult to find one consistently do that. On top of that, I’m trying to look for one that can be installed on arbitrary prefix too and recently I’ve been eyeing on pkgsrc, gentoo prefix, and spack.