Aliases: Use where a simple textual expansion of command arguments, but no other input parsing, is required. Typical examples are to create an "ll" alias for "ls -l":
alias ll='ls -l'
You can shorten commands or supply arguments. If you're doing the latter, you can also look at commands' ENVIRONMENT options, e.g., for less(1), the $LESS environment variable can carry arguments such as "-X", which avoids clearing the terminal on exit (one I employ).
Renaming commands is another common hack, e.g., "alias vi=vim" or "alias awk=gawk" if you want to use a specific variant of a tool or utility. In many cases, your distro's alternatives feature is a better place for this, though individual users on a multi-user system may need to use aliases or other mechanisms. (/etc/aliases is a Debian feature.)
Scripts: These can be of any length, invoke multiple other utilities, run in a separate shell, create their own environment, run as a child of the invoking shell, and exist in their own independent executable file(s). They don't occupy shell memory, and support complex logic incluing if/then, while/do, case, and other branching logic.
Functions: are largely equivalent to scripts, but with some key differences:
- Functions run in the executing shell. Which means functions can change the shell environment, either as an intended or unintended side effect. If you want to change environment variables or the current working directory ($PWD) of the invoking shell, you must use a bash function. Similarly: a command sequence which changes the environment or current working directory, if run as a function, may unexpectedly or unintentionally change the invoking shell's (that is, its own) context.
Scripts and functions are not mutually exclusive. Defining, referencing, and/or using functions within scripts is an excellent way to 1) modularise scripts and 2) achieve results such as changing the environment within the script.
Generally:
- For simple text substitutions, I use aliases.
- Short or simple commands involving arguments and/or branching logic, or specifically intended to change environment, I'll use a function.
- For long-running, complex, batch/cron, or commands in which I don't want the invoking environment to change, I'll use a shell script. That script will often include defined functions.
I think this would be more complete if the author also discussed variables. Then the justification for using functions versus external scripts becomes a little more clear.
I use functions for things that don't (or don't always / don't necessarily) need to do a disk read, and has something to do with the overall environment. For example, configuring directory and file colours depending on whether its a regular login or ssh. I choose what becomes a function by whether I think I can use it for more than one purpose. Ie: if it is reusable for something else. I grew up on Lisp, so it's a habit with plenty of advantages for my way of thinking of compute environments.
I use scripts for things that are more involved and don't get used often enough to justify living constantly in memory. Needless to say, my scripts assume nothing about what's in the .bashrc file unless I source them directly, so of course they could easily have their own variables and maybe even functions. And they are practical outside of the general shell environmental needs. For example, neofetch is the exact kind of thing I would script and never write as a standalone function in my bashrc. Some people might only want to see its output upon logging in. Others might happen to be curious at some given time, and run it just for the lolz. But neither justifies living in the shell's memory in between those occasions. So it stays as an external script.
3 comments
[ 2.0 ms ] story [ 16.3 ms ] threadSimple use cases: alias la='ls -al' alias somefolder='cd blah/blah/blah'
Less typing. Nothing too crazy. What he is doing with more complex features, I wouldn't look to simplify with .bashrc.
Aliases: Use where a simple textual expansion of command arguments, but no other input parsing, is required. Typical examples are to create an "ll" alias for "ls -l":
You can shorten commands or supply arguments. If you're doing the latter, you can also look at commands' ENVIRONMENT options, e.g., for less(1), the $LESS environment variable can carry arguments such as "-X", which avoids clearing the terminal on exit (one I employ).Renaming commands is another common hack, e.g., "alias vi=vim" or "alias awk=gawk" if you want to use a specific variant of a tool or utility. In many cases, your distro's alternatives feature is a better place for this, though individual users on a multi-user system may need to use aliases or other mechanisms. (/etc/aliases is a Debian feature.)
Scripts: These can be of any length, invoke multiple other utilities, run in a separate shell, create their own environment, run as a child of the invoking shell, and exist in their own independent executable file(s). They don't occupy shell memory, and support complex logic incluing if/then, while/do, case, and other branching logic.
Functions: are largely equivalent to scripts, but with some key differences:
- Functions run in the executing shell. Which means functions can change the shell environment, either as an intended or unintended side effect. If you want to change environment variables or the current working directory ($PWD) of the invoking shell, you must use a bash function. Similarly: a command sequence which changes the environment or current working directory, if run as a function, may unexpectedly or unintentionally change the invoking shell's (that is, its own) context.
Scripts and functions are not mutually exclusive. Defining, referencing, and/or using functions within scripts is an excellent way to 1) modularise scripts and 2) achieve results such as changing the environment within the script.
Generally:
- For simple text substitutions, I use aliases.
- Short or simple commands involving arguments and/or branching logic, or specifically intended to change environment, I'll use a function.
- For long-running, complex, batch/cron, or commands in which I don't want the invoking environment to change, I'll use a shell script. That script will often include defined functions.
I use functions for things that don't (or don't always / don't necessarily) need to do a disk read, and has something to do with the overall environment. For example, configuring directory and file colours depending on whether its a regular login or ssh. I choose what becomes a function by whether I think I can use it for more than one purpose. Ie: if it is reusable for something else. I grew up on Lisp, so it's a habit with plenty of advantages for my way of thinking of compute environments.
I use scripts for things that are more involved and don't get used often enough to justify living constantly in memory. Needless to say, my scripts assume nothing about what's in the .bashrc file unless I source them directly, so of course they could easily have their own variables and maybe even functions. And they are practical outside of the general shell environmental needs. For example, neofetch is the exact kind of thing I would script and never write as a standalone function in my bashrc. Some people might only want to see its output upon logging in. Others might happen to be curious at some given time, and run it just for the lolz. But neither justifies living in the shell's memory in between those occasions. So it stays as an external script.