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.
Aliasing anything always seems like an unnecessary abstraction in just about every instance.
Glad I don’t come across it or much other unnecessary stuff in my work.
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 honestly thought he was kidding when I came across the g=git example.
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.
It was just an example of what I’m doing for my particular situation where I don’t have root access and I want some personal scripts for myself, I’m not saying you should choose the same location. If everyone is already sourcing the same file, I expect there’s already a shared storage you are maintaining that everyone has access to.
About something breaking, I guess it’s up to you and your team if you prefer functions, but it also means not everyone will need to be annoyed when someone else’s code has a small syntax error. And also I expect the only errors you are able to get feedback about right now would be only structural syntax errors for the function declaration (I expect you don’t have unit tests or anything like that for your bash functions…) so technically a function could still be broken and you wouldn’t know until you use it.
Scripts also give the advantage of being able to use other languages beyond bash, if perl/python or others are available.
Anyway, you are free to have your reasons, I was just saying that root access is not necessarily needed.
Functions are best for this.
It still limits where / how you use them.
For example, it’s easier / more efficient to call a shell script from sway (or whichever other software that might be running without a bash login session behind) than to try and force it to load a whole shell login session that includes those functions (which might also slow down the startup of the program and make it need a bit more ram without much of a benefit).
Scripts can reliably be run from everywhere (specially if placed somewhere in
$PATH), functions require some preloading for every single new shell process and making sure the program invoking the shell (be it a terminal emulator or something else) is actually loading it. So as someone who likes to automate everything and often assigns hotkeys to particular commandline oneliners, scripts are much better… even a symlink might be more reliable than an alias.I agree. My
.zshrcis littered with functions. Most useful ones are mypackandextractI made ~10 years ago, they just recognize file extension and use the correct tool.I even wrote a function to parse a json for some configuration details, and loop through it to dynamically create more named functions from that json profile. I use it at work for automating my cloud account logins with a single profile name from the command line. :)
I like fish abbreviations. They are like aliases but expand when you press space or enter. That way you can edit it, and also still see the full command so you are less likely to forget it when you don’t have your aliases. Of course I have some scripts as well.
And: Fish implements aliases as scripts! When you use alias —save, fish creates as script with a function in it.
I actually use both in fish. I use aliases for some longer commands. For example I have
laas an alias foreza -la --icons=auto --group-directories-firstbecause I don’t really want to see it every time I runla. I use abbreviations for some shorter commands. For examplesystemctlabbreviated tosysandsystemctl --userabbreviated tosysu.I use ZSH with plugins but back when I switched away from bash, I also looked at fish. I didn’t use it back then because people say it doesn’t follow the POSIX standard but is that really an issue? It probably only extends it instead of taking things away, right?
All POSIX compatible shells have their quirks and differences because the common POSIX part is rather small, so you will need to learn them anyway when switching from one to another. Fish is not that different from them (to much less extent than something like nushell) and it benefits from having less ancient baggage.
Unless you have a particular reason for sticking to POSIX, who cares? I’ll take the user experience improvement without worry.
The thing is that, if you are not sticking to POSIX, you might as well use more widely available alternative scripting languages like perl or python, which are often included in most workspaces by default, so I’d say it’s more useful to get experienced in those than to get experienced in fish.
I still write most scripts for bash, but for interactive use fish is just so much better out of the box.
this is my sticking point with fish. I still need to know bash for writing portable scripts, so its hard to justify scripting in fish.
that’s actually a really good argument for not using either.
Taking a step back discussing shells seems like a never ending hell loop.
Sometimes the only way to win is not to play the game.
Use python and stop being stuck in the distant past.
No issues except that if you want to source files to set env vars you might have to use a plugin (foreignenv in my case)
I still write scripts in bash. But fish’s command completion is incredible. Idk, maybe other shells can be that good as well, but fish does out of the box.
Edit: Also some people used to bash wondered what that nice shell is on a server we administrate together. They had no problems using it coming from bash.
And sticking with POSIX is good if you want to stay portable, but my shell mustn’t be portable. It should be friendly and reduce mental load.
Thanks for this info! Didn’t know about it! 😃
I use zsh with aliases, and Atuin which I find very convenient.
I’ll definitely try out fish abbr in combo with aliases. Logic in aliases is great.
Just recently I learned that one can also define functions in .bash_aliases. Very handy.
Yep. And if you edit it you can reload it with “. ~/.bash_aliases” and if you do it frequently you can create an alias for it.
Nice!
I also switched to scripts. Aliases tend to break in loops with modified IFS
