5 ms·

I use short custom command names like aa, st, di, dp, cm and le in some thin wrappers around git. One of these names actually collides with a utility that is i

I use short custom command names like aa, st, di, dp, cm and le in some thin wrappers around git. One of these names actually collides with a utility that is installed by default on some systems. Doesn’t matter to me. I have my own bin dirs before the system dirs in my path, so mine “win”, and I’m not really interested at all in the tool that mine has a name collision with. If someone were to make a useful to me tool that collided with one of my own tools, I’d probably sooner alias that other tool to a new name that didn’t collide with mine, than to change any of my own tool names. It’s just too comfortable to use these two-character tools of mine.

oguz-ismail 2y ago
This. 1-3 character names should be reserved for user aliases/functions/scripts and standard utilities.
- deleted 2y ago
  [deleted]
jmclnx 2y ago
All my personal commands begin with 'j'. Got real fun when java came around. Using commas is a rather interesting idea. But at least I did not start them with a 'k' (KDE) :)
setopt 2y ago
I tend to make all my git aliases into two-letter combos starting with g. So `gs` is `git status`, for example. Once in a while I actually really need GhostScript though, it’s brilliant for e.g. embedding fonts into PDF files. Usually I then go with `env gs`.
- MathMonkeyMan 2y ago
  I have `alias s='git status'` and I feel like I'm missing a finger when it's not there.
MaulingMonkey 2y ago
This approach can lead to issues like `apt-get upgrade` launching dwarf fortress: https://askubuntu.com/questions/938606/dwarf-fortress-starting-during-apt-get-upgrade https://askubuntu.com/questions/938606/dwarf-fortress-starti...
- owl57 2y ago
  I hope that tools like apt-get run subcommands in a predictable environment and never leak interactive session's $PATH. Then nothing in $HOME will break them — that user just put his df executable in /usr/bin or somewhere like that.
diego_sandoval 2y ago
Hot take: system commands shouldn't be as accessible as user commands. There should be some sort of namespacing. For example, mkfs should be invoked with `sys::mkfs` or something like that. The line that separates system and user commands may be defined in different ways, and it may be fuzzy in some places, but if a user accidentally invokes a command that they don't even know why is there, and they didn't explicitly install, then that's clearly a command that shouldn't be directly available in the global namespace.
- genewitch 2y ago
  i am unsure if RHEL/Cent did this, but at one of the places i worked you had to do /bin/ls. I expect this is much more common at places that do lots of acquisitions. that way if some random cron job relies on UB from some tool in order to not start the DC on fire, it doesn't matter. Admins use latest tooling, the software gets whatever it came with and was working until actual competent devs can look at it and move it to ansible or whatever puppet/chef i forget what they all used.
- fukawi2 2y ago
  This is the original reason for having /bin vs /sbin The sbin directories are supposed to contain "system" (or superuser) commands, and regular users should NOT have those directories in their PATH. This has been broken for a long time on every distribution I've looked at though.

oguz-ismail 2y ago

This. 1-3 character names should be reserved for user aliases/functions/scripts and standard utilities.

deleted 2y ago
[deleted]

jmclnx 2y ago

All my personal commands begin with 'j'. Got real fun when java came around. Using commas is a rather interesting idea. But at least I did not start them with a 'k' (KDE) :)

setopt 2y ago

I tend to make all my git aliases into two-letter combos starting with g. So `gs` is `git status`, for example. Once in a while I actually really need GhostScript though, it’s brilliant for e.g. embedding fonts into PDF files. Usually I then go with `env gs`.

MathMonkeyMan 2y ago
I have `alias s='git status'` and I feel like I'm missing a finger when it's not there.

MaulingMonkey 2y ago

This approach can lead to issues like `apt-get upgrade` launching dwarf fortress: https://askubuntu.com/questions/938606/dwarf-fortress-starting-during-apt-get-upgrade https://askubuntu.com/questions/938606/dwarf-fortress-starti...

owl57 2y ago
I hope that tools like apt-get run subcommands in a predictable environment and never leak interactive session's $PATH. Then nothing in $HOME will break them — that user just put his df executable in /usr/bin or somewhere like that.

diego_sandoval 2y ago

Hot take: system commands shouldn't be as accessible as user commands. There should be some sort of namespacing. For example, mkfs should be invoked with `sys::mkfs` or something like that. The line that separates system and user commands may be defined in different ways, and it may be fuzzy in some places, but if a user accidentally invokes a command that they don't even know why is there, and they didn't explicitly install, then that's clearly a command that shouldn't be directly available in the global namespace.

genewitch 2y ago
i am unsure if RHEL/Cent did this, but at one of the places i worked you had to do /bin/ls. I expect this is much more common at places that do lots of acquisitions. that way if some random cron job relies on UB from some tool in order to not start the DC on fire, it doesn't matter. Admins use latest tooling, the software gets whatever it came with and was working until actual competent devs can look at it and move it to ansible or whatever puppet/chef i forget what they all used.
fukawi2 2y ago
This is the original reason for having /bin vs /sbin The sbin directories are supposed to contain "system" (or superuser) commands, and regular users should NOT have those directories in their PATH. This has been broken for a long time on every distribution I've looked at though.