Let's assume that in V1 your command has 2 options: start and stop. Thanks to Abbrev, your user take in the habit of calling "$command sta" and "$command sto" respectively. It all works. They start relying on that in scripting.
Then out comes V1.1. This should be a non-breaking release that simply adds the status command. Despite only adding a new command, you break the workflow of your users: "$command sta" does not work anymore because of the ambiguity.
Let's assume that in V1 your command has 2 options: start and stop. Thanks to Abbrev, your user take in the habit of calling "$command sta" and "$command sto" respectively. It all works. They start relying on that in scripting.
This really is a very weak position. More fool them for being so lazy and short-sighted that they can't be bothered to type out the command in a script in full. If I saw that, I would immediately make a change and submit a pull request or whatnot to get it changed for the better, in the cause of keeping the workspace safe, clean, and tidy.
In that case it would be the dev's fault for making a breaking change in a minor release. The correct thing would be to explicitly add 'sta' => 'start' to the Abbrev hash. (Or note in the documentation that the abbreviations are for convenience only, not stable and subject to change.)
Indeed, how could the dev know? Are you assuming the developer is omniscient and knows every abbreviation used worldwide? Realistically, he has not the slightest idea anyone is using 'sta' and so wouldn't know to hardwire an override.
My point was that the dev knows "sta" is currently available as an abbreviation for "start", and when he adds "status" it no longer will be. So if he wants to maintain strict backwards compatibility he should add it back in manually. It's no longer unambiguous, but it does maintain the previous behavior.
Of course I personally would go with option two, where its documented that the abbreviations exist but are subject to change and you shouldn't rely on them.
The dev also "knows" that 'star' is available as an abbreviation. And in a realistic set of options for a real tool like git, there might be combinatorially many possible abbreviations which he now has to "know" and think about every possible intersection or ambiguity.
Yeah, this would be good for tab-completion. It would also work with a time-delay, like git does. It'll print out the guessed command with a second delay, and then if the user doesn't interrupt, execute it.
I mean, okay… but… A lot of command line software already works that way, where you only need to type the minimum number of characters required to disambiguate a command, and as far as I know nobody has died yet as a result.
Abbreviated commands are fine for manual interaction, but a good engineer puts the full commands into source code for discoverability and specificity. If I saw a teammate putting abbreviated commands into source code, I would ask them to change it to the full commands, and I would feel entitled to.
Also, how would we know if no one has died from this? The practice of abbreviating commands literally makes forensics more difficult to accomplish, making it harder to know.
> A lot of command line software already works that way, where you only need to type the minimum number of characters required to disambiguate a command, and as far as I know nobody has died yet as a result.
Do you have an example? None of the command-line tools I use every day work that way. The usual workflow is 1- type a couple characters; 2- press <tab> to complete. The second step is crucial because it ensures you run the right command.
GDB is one software I use a lot that has this feature. You can abbreviate break, print, delete, and others.
For conflicts (does 'd' refer to delete or disable?) the more commonly used command is usually what the abbreviation will expand to (so GDB accepts 'd' for "delete").
No, `npm` has a couple aliases like "i" for "install", but you can’t use "in", "ins", "insta", etc. It has "view" and "version" but "v" is an alias for "view".
`gem` does work like this (#TIL), although it has some hard-coded aliases: while its help page says "Commands may be abbreviated, so long as they are unambiguous", `gem i` works as `gem install` even if there’s a command "info". If you try `gem in`, it does complain that it’s ambiguous.
If you're exposing `command sta` as your official API then you need to test it, so it fails in V1.1 and you fix it before releasing. If it's just a convenience, and you don't promise a stable API, I suppose it doesn't matter as much.
Let's assume that in V1 your command has 2 options: start and stop. Thanks to Abbrev, your user take in the habit of calling "$command sta" and "$command sto" respectively. It all works. They start relying on that in scripting.
Then out comes V1.1. This should be a non-breaking release that simply adds the status command. Despite only adding a new command, you break the workflow of your users: "$command sta" does not work anymore because of the ambiguity.