I’ve done something similiar to this over the years for organization purposes and not having to change much between shells except add a path. You can also add cases that check your shell and do something slightly different if needed.
I’ve done something similiar to this over the years for organization purposes and not having to change much between shells except add a path. You can also add cases that check your shell and do something slightly different if needed.
I have never heard of anyone using aliases for anything but trivial one-liners. I don’t think people consider them as an alternative to scripts so I don’t really get the point of half of this post.
However, the part explaining the benefits of using scripts over aliases even for trivial one-liners is pretty neat.
I use aliases for renaming commands and making bash scripts look like real commands to the rest of my team.
That’s an anti-pattern if I’ve ever heard of one.
Which one?
Using aliases to rename commands.
Yeah, I can see how that could go wrong, in practice it’s used to alias a python version python2 to python and impacts about 10 build scripts. (Which should be rewritten, but no-one is going to prioritise that work)
Why not make them executable and stick them in bin
Mostly because there’s a profile everyone sources that’s relatively straightforward to that’s straightforward to get access to. Whereas I’d never get root level access.
You don’t need root level access though. What I usually do is stick a
PATH="$PATH:$HOME/.local/binand then place all the scripts in there.Wouldn’t that require me to have access to everyone’s home directory and need to dump the scripts in everyone’s?
Potentially I could set up an alt bin directory everyone has access to and configure that in the shared profile, the only drawback there is it might be less obvious whats going on if something breaks and someone else needs to take a look at it.