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

npm and gem behave like this, although I don't know if they use this exact method to figure out the abbreviations.

git has something similar, although it's disabled by default (help.autocorrect option).

Thanks.

> npm and gem behave like this

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.