
In Bash, when to alias, when to script, and when to write a function? - colinprince
https://unix.stackexchange.com/questions/30925/in-bash-when-to-alias-when-to-script-and-when-to-write-a-function
======
ksaj
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.

------
just_myles
I use alias for simple day to day things that I have to do.

Simple 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.

------
dredmorbius
Covered in various parts of responses:

 _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.

