31–40 of 64 posts
I think it's clever that Apple uses the `-v` flag for both verbose and verify options. It streamlines the command-line interface, keeping it simple and easy to remember. Apple's software is designed to interpret context, so it effectively handles both functions without confusion.
Add this to the growing list of Apple bs that has developed over the past 10 years. Used to be in deep in the ecosystem. Now have been winding down significantly, hardware hasn’t been upgraded since 2017. Various iDevices aging out until bust. Services reduced to bare bones iCloud. Whatever the 200G plan is for keeping basic backups. Otherwise, have self hosted most of their services - iTunes/Music/TV transitioned to…
What? They switched architecture to an amazing new chip series since then. I’d go even further and say that the era before then was the lost era of rubbish keyboards and strange gimmicks (looking at you, touchbar).
Earlier quoted context omitted.
As a user, I don’t want to have to type the full option name every time I use it.
Your shell should be smart enough autocomplete it anyway.
I know that approaches like Powershell which has understanding of all the Microsoft commands and the ability to define a structure that defines the options ... but how would bash figure out the structure of the arguments for dd or tar or that a.out that I just compiled?
Earlier quoted context omitted.
As a user, I don’t want to have to type the full option name every time I use it.
As a user I almost never use short flags because it’s super confusing and inscrutable. But I admit I’m probably in the minority on this!
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 t…
No, it's very confusing, especially for people who are used to tools built with GNU getopt.
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.
Add this to the growing list of Apple bs that has developed over the past 10 years. Used to be in deep in the ecosystem. Now have been winding down significantly, hardware hasn’t been upgraded since 2017. Various iDevices aging out until bust. Services reduced to bare bones iCloud. Whatever the 200G plan is for keeping basic backups. Otherwise, have self hosted most of their services - iTunes/Music/TV transitioned to…
> hardware hasn’t been upgraded since 2017 What? They switched architecture to an amazing new chip series since then. I’d go even further and say that the era before then was the lost era of rubbish keyboards and strange gimmicks (looking at you, touchbar).
It was interesting. I put it in the "you don't know if it works until you try it... and for most people it wasn't useful."
It might have been something that would have caught on more if they had a Touch Bar only USB device that could fit reasonably with a 109 key 3rd party keyboard (yea, heresy) and be used independently.
Something that could be used like a stream deck ( https://www.elgato.com/us/en/p/stream-deck-mk2-black )
There is utility for a special purpose keyboard... just not the way the Touch Bar was done (and in so limited a way). It is something that was designed for professional workflows (like IntelliJ, Final Cut Pro) but it was only on the laptop and I use my Mac Pro for more "professional" uses and it wasn't there.
Earlier quoted context omitted.
Your shell should be smart enough autocomplete it anyway.
How would a shell interrogate the valid parameters from a complied binary? I know that approaches like Powershell which has understanding of all the Microsoft commands and the ability to define a structure that defines the options ... but how would bash figure out the structure of the arguments for dd or tar or that a.out that I just compiled?
Applications already come with lots of metadata: man pages, icon, readable name, ... adding formal shell-completion information is just another one.
Besides that, the built-in command line tools already have auto-completion for their arguments. Though I think they do it by running scripts at shell startup, which isn't exactly the mechanism I would have used... but it works.
In your case, "that a.out I just compiled", this metadata would be missing, so no shell completion for you. But that is a niche use case anyway, and not at all what this post is about.
Earlier quoted context omitted.
Plus while it’s very convenient for tools that support autocomplete of their parameters, but not all do. So sometimes you just fall in the habit of assuming they don’t.
My experience with flag autocomplete is like 90% it completing a huge filename that I then have to backspace annoyedly. Not entirely sure which shell I encountered it on but wow. I just can't afford to rely on it because of cases like those.