Tools for working in the terminal window Bash commands by script, function or alias?
The beauty of working in the terminal: It is flexible, but can always be kept efficient and lean – especially thanks to various “abbreviations” for commands and command sequences. And here Bash offers at least three tools.
Companies on the topic
In the bash all possible commands and command sequences can be scripted, here we look at the possibilities.
(©LuckyStep – stock.adobe.com)
There are many ways to automate the work with and in Bash – but when is which variant announced? Does it have to be a script or is a function or even an alias sufficient?
Each of these tools has a very special purpose, but there is also a large intersection. So when does an alias lend itself, when a function and when a script? Or asked suggestively: When does a problem become too complex for an alias, when for a function?
Alias: No Function
An alias in Bash is basically exactly what an alias is in the real world as well: An alternative name. Even the Man page suggests that it is about replacing a word in a simple command.
This could mean starting a tool with a completely different, alternative call, such as “search” instead of”find”. Or simply abbreviate, for example” f “instead of”find”. In practice, it usually boils down to starting tools by default with certain options or creating explicit starters for such options, such as:
ll="ls -al"
ls="ls -F --color=auto –show-control-chars"
But there is also reality: pipes and chains of command quickly end up in the alias definitions. Usually it starts with short pipes, which are used again and again, for example, browsing the history:
history | grep
And there is an alias “hisgrep” or the like, for example via …
hisgrep sed
… list the used sed commands of the session. As a simple chain of command, ssh connections could be offered, which immediately bring a password hint:
sshcubi='echo MeinHinweis && ssh me@192.168.178.100'
Aliases, which are only available in interactive subshells by default, are also well suited for such trifles. And that’s where the limitation of aliases begins. Although they can be expanded via bash option and then also used in non-interactive subshells. The use in scripts is possible,but this is not useful.
Aliases are only available locally and can also be changed temporarily. For example, one could be in the Bash startup file “.bashrc ” simply temporarily redefine the stored alias for the current shell without having to undo something later. Aliases are also stored in the shell’s memory, so new subshells are not necessary to run.
It becomes critical at the latest when positional parameters are to be passed – this is not possible with aliases. But far from what may or may not work: aliases are meant for simple word substitutions.
To give it a try Gnu.org ” For almost every purpose, shell functions are preferred over aliases.”In this sense, you may not have to explore the topic exhaustively and can immediately move on to the function.
Function: One Function
Once again, the name reveals everything: A function definition provides a single function. Functions are also stored in the shell’s memory, but can be called up in all subshells via an export statement, i.e. also in scripts. And of course, functions are usually about the “.bashrc”, either directly or via a separate collection of functions included in it.
Despite all the similarities, aliases are likely to be much more common-be it. because they are enough or because some have built up a stately collection reminiscent of functions over the years. Function provides significant added value even for very simple tasks.
Again to the above SSH logins: Fixed logins for individual users are good and nice, but they are not flexible. In practice, however, you always log on to computers in your own network with different user names – what usually remains the same? The subnet mask and the@, so you can also replace it:
sl () { ssh $1@192.168.178.$2 ; }
From now on, the specification of user name and last digit of the IP address is sufficient to perform an SSH login:
sl me 100
In general, functions are more programmatic than aliases, they allow much more complex tasks, loops, queries and so on – and in regular notation they look much more familiar to anyone with programming experience. Here with additional export for subshells / scripts:
testing ()
{
for i in {1..10}; do echo Durchlauf $i
Sleep 1
done
}export -f testing
And finally, functions also have a kind of superpower over the even more powerful scripts: As I said, they are executed without their own subshell – and can therefore also change the environment of the current shell, for example environment variables such as the root directory.
But functions also have a” problem”: They are available in subshells, but only the one shell, the bash.
Script: Divisible function(s)
Bash scripts come into play if at least one of the following points is relevant: Many individual functions should be processed, it should be shareable with other users/shells/interpreters, memory should only be allocated if necessary.
Scripts are started in their own subshell when called-with the interpreter specified via the shebang. Alternatively, the script can also be started directly via the interpreter:
bash meinskript
sh meinskript
zsh meinskript
Which of course does not mean that scripts cannot be executed in the current shell, simply by source command. And here again briefly to the above mentioned export of functions: If in “meinskript” the two in the .bashrc defined functions “meinefunktion1 ” and” meinefunktion2 “are called and only” meinefunktion1 ” was exported, the call …
sh meinskript
… also executed only the first function, since the second is not available to the sh subshell. However, a …
source meinskript
… call both functions, because there is no subshell involved.
So when what?
Now it is possible to argue about when exactly which tool is used, how far functions and especially aliases can be exploited and how they could even be completely interlinked. But scripts that call exported functions that call expanded aliases … not a good idea. But you can definitely put yourself on the point: if it works, it’s okay.
Without such a firm point of view, probably shaped by experience, one actually drives well to use the tools as it is essential. And that means:
- Aliases as abbreviations and alternative calls for simple commands,
- Functions for delimited tasks that are only relevant to a user within a shell, and
- Scripts for anything that is more complex and/or to be executed by third party users / interpreters.
Apart from that, you could actually always elevate functions to independent scripts if they do a meaningful task on their own – even if they are only to be used at home on the second computer.
And yes, if you have gone into the topic quite unbiased, that just sounds obvious. Probably the most important finding: aliases should be reduced to a minimum, functions are much more powerful and also more elegant in spelling.
So far so theoretically-quite practically personal preferences and workflows are relevant, insofar again: What works is okay. Need a practical example? The following “alias”, and note the quotation marks, has been in use here for years, works perfectly:
alias ml_version='
tput setaf 1 && echo Systeminfo: && tput sgr0 &&
lsb_release -idrc &&
tput setaf 1 && echo Kernel:&& tput sgr0 &&
uname -r &&
tput setaf 1 && echo Devices: && tput sgr0 &&
lsblk -o NAME,SIZE,MOUNTPOINT &&
tput setaf 1 && echo Speicherplatz: && tput sgr0 &&
df -h --output=source,size,used,avail,target –exclude-type=tmpfs'
This” alias ” provides fix some nicely formatted system information on Debian, Ubuntu and their descendants. In order to be able to use this alias as a script on foreign systems, the code is also on a web server and can be wonderfully …
curl cli.help/version | sh
… use. Thus, one and the same code runs sometimes as an alias, sometimes as a script – this is not necessarily in the sense of the inventor and certainly not pretty. But it works.
But by the way: Even though there was always talk of Bash scripts here, scripts are of course not dependent on Bash as an interpreter-but anyone who knows Python, for example, probably doesn’t bother with too many Bash functions and scripts anyway, let alone overconstructed aliases.
(ID: 47485803)
