Noone should need 10 years for asking this question, like I did. If I were just starting out with Linux, I'd want to know: When to alias, when to script and when to write a function?

Where aliases are concerned, I use aliases for very simple operations that don't take arguments.

alias houston='cd /home/username/.scripts/'

That seems obvious. But some people do this:

alias command="bash bashscriptname"

(and add it to the .bashrc file).

Is there a good reason to do that? I didn't come across a circumstance for this. If there is an edge case where that would make a difference, please answer below.

That's where I would just put something in my PATH and chmod +x it, which is another thing that came after years of Linux trial-and-error.

Which brings me to the next topic. For instance, I added a hidden folder (.scripts/) in the home directory to my PATH by just adding a line to my .bashrc (PATH=$PATH:/home/username/.scripts/), so anything executable in there automagically autocompletes.

I don't really need that, do I? I would only use that for languages which are not the shell, like Python. If it's the shell, I can just write a function inside the very same .bashrc:

funcname () {
  somecommand -someARGS "$@"

Did I miss anything?
What would you tell a beginning Linux user about when to alias, when to script and when to write a function?

If it's not obvious, I'm assuming the people who answer this will make use of all three options. If you only use one or two of these three (aliases, scripts, functions), this question isn't really aimed at you.

  • 17
    +1 for the stating explicitly all the subsets of {alias, script, function} at which this question does not aim. +1 for the childlike faith that it was OK for you to omit the null subset. Commented Aug 26, 2013 at 15:16
  • 2
    Although the question specifically asked about bash, note that older Bourne shells had 'alias' but not functions. This might make a difference if you're worried about compatibility.
    – AndyB
    Commented Mar 4, 2016 at 5:53
  • 1
    If .bashrc really the best place, or at least a solid place, for this? There are so many ways to do the same thing in Linux, which I appreciate, however, all things being equal, I prefer to do things the most common way.
    – Kit10
    Commented Jun 10, 2016 at 13:33

16 Answers 16


The other answers provide some soft general guidelines based on personal taste, but ignore many pertinent facts that one should consider when deciding between scripts, functions, or aliases.

Aliases and Functions ¹

  • The entire contents of aliases and functions are stored in the shell's memory.
  • A natural consequence of this is aliases and functions can only be used by the current shell, and not by any other programs you may invoke from the shell like text editors, scripts, or even child instances of the same shell.
  • Aliases and functions are executed by the current shell, i.e. they run within and affect the shell's current environment.² No separate process is necessary to run an alias or function.


  • Shells do not keep scripts in memory. Instead, scripts are read from the files where they are stored every time they are needed. If the script is found via a $PATH search, many shells store a hash of its path name in memory to save time on future $PATH look-ups, but that is the extent of a script's memory footprint when not in use.
  • Scripts can be invoked in more ways than functions and aliases can. They can be passed as an argument to an interpreter, like sh script, or invoked directly as an executable, in which case the interpreter in the shebang line (e.g. #!/bin/sh) is invoked to run it. In both cases, the script is run by a separate interpreter process with its own environment separate from that of your shell, whose environment the script cannot affect in any way. Indeed, the interpreter shell does not even have to match the invoking shell. Because scripts invoked this way appear to behave like any ordinary executable, they can be used by any program.

    Finally, a script can be read and run by the current shell with ., or in some shells, source. In this case, the script behaves much like a function that is read on-demand instead of being constantly kept in memory.


Given the above, we can come up with some general guidelines for whether to make something a script or function / alias.

  • Do other programs besides your shell need to be able to use it? If so, it has to be a script.

  • Do you only want it to be available from an interactive shell? It's common to want to change the default behavior of many commands when run interactively without affecting external commands / scripts. For this case, use an alias / function set in the shell's "interactive-mode-only" rc file (for bash this is .bashrc).

  • Does it need to change the shell's environment? Both a function / alias or a sourced script are possible choices.

  • Is it something you use frequently? It's probably more efficient to keep it in memory, so make it a function / alias if possible.

  • Conversely, is it something you use only rarely? In that case, there's no sense having it hog memory when you don't need it, so make it a script.

¹ While functions and aliases have some important differences, they are grouped together because functions can do everything aliases can. Aliases can not have local variables nor can they process arguments, and they are inconvenient for anything longer than one line.

² Every running process in a Unix system has an environment consisting of a bunch of variable=value pairs which often contain global configuration settings, like LANG for the default locale and PATH for specifying executable search path.

  • 3
    @mikeserv - Perhaps you should write a blog post about those facts and variations. But it would be in an advanced bash scripting category, not this answer's basic guidelines category. Commented Nov 10, 2015 at 21:44
  • 1
    @mikeserv My "categories" are made up to describe the difference between this answer (which covers 80% of use cases), and your comment (which alludes to the other 20% not covered). (: Even those percentages are made up. :) Commented Nov 12, 2015 at 6:19
  • 8
    Worth noting: if two (or more) scripts need to share some code, it's probably best to put that code into a function which is itself located in a third file that both of those scripts import/source.
    – kbolino
    Commented Sep 21, 2016 at 19:40
  • 4
    Another item to add to that list of questions: Do you ever need to change functionality in the command on the fly? changes to a script will be reflected in all sessions, whereas functions and aliases must be reloaded or redefined on a per session basis.
    – Stratus3D
    Commented Apr 14, 2017 at 21:02
  • 1
    Another dimension to the discussion: External commands (scripts) can be more easily tested, reloaded, etc. There are entire development cultures and environments for building and testing external commands and their components but nothing for aliases and functions. Ksh93 has FPATH to try to make functions more like commands.
    – jrw32982
    Commented Oct 3, 2019 at 14:25

An alias should effectively not (in general) do more than change the default options of a command. It is nothing more than simple text replacement on the command name. It can't do anything with arguments but pass them to the command it actually runs. So if you simply need to add an argument at the front of a single command, an alias will work. Common examples are

# Make ls output in color by default.
alias ls="ls --color=auto"
# make mv ask before overwriting a file by default
alias mv="mv -i"

A function should be used when you need to do something more complex than an alias but that wouldn't be of use on its own. For example, take this answer on a question I asked about changing grep's default behavior depending on whether it's in a pipeline:

grep() { 
    if [[ -t 1 ]]; then 
        command grep -n "$@"
        command grep "$@"

It's a perfect example of a function because it is too complex for an alias (requiring different defaults based on a condition), but it's not something you'll need in a non-interactive script.

If you get too many functions or functions too big, put them into separate files in a hidden directory, and source them in your ~/.bashrc:

if [ -d ~/.bash_functions ]; then
    for file in ~/.bash_functions/*; do
        . "$file"

A script should stand on its own. It should have value as something that can be re-used, or used for more than one purpose.

  • 27
    It's also important to remember that – unless sourced with . or source – a script is executed by separate bash process and has its own environment. For this reason, anything that modifies the shell environment (e.g. functions, variables, etc.) will not persist in the shell environment from which you run the script. Commented Mar 5, 2015 at 11:02

I think it's up to each person's taste. For me the logic goes like this:

  • First I try to make an alias, because it's the simplest.
  • If the thing is too complicated to fit in one line, I try to make it a function.
  • When the function starts to grow beyond a dozen of lines I put it in a script.

There is really nothing to restrict you from doing something that works.

  • 7
    I often skip the function option, and make a script right away. But I agree that it is partly a matter of taste
    – Bernhard
    Commented Feb 5, 2012 at 15:00
  • 2
    A function begins to make sense if you need it in several scripts.
    – Nils
    Commented Feb 10, 2012 at 21:45
  • 8
    ... or if you need the side-effects to alter the current shell. Commented Jul 27, 2015 at 16:30

At least partially it's a matter of personal taste. On the other hand there are some clear functional distinctions:

  • aliases: only suitable for simple text replacements, no arguments/parameters
  • functions: easy to write/use, full shell scripting capability, only available inside bash
  • scripts: more or less like functions, but available (callable) outside of bash as well

Looking at shell scripting I've done the last few years I have more or less stopped writing aliases (because they all tend to grow into functions over time) and do scripts only if they need to be available also from non-bash environments.

PS: As for alias command="bash bashscriptname" I don't actually see any reason to do this. Even if bashscriptname is not in $PATH, a simple alias c=/path/to/script would be enough.

  • 2
    In alias command="bash bashscriptname" the script does not necessarily have to be executable; in the alias c=/path/to/script it has to. Commented Jul 24, 2018 at 16:29
  • It is not true at all that functions are "only available inside Bash". If you mean to say they are a Bash-only feature, that is simply false (Bourne shell and every compatible derivative has them); and if you mean to say they are a feature of interactive shells, that's not accurate either (though aliases, variables, and functions defined in a file which gets loaded at startup by interactive shells obviously will not be loaded by noninteractive shells).
    – tripleee
    Commented Aug 19, 2018 at 8:10
  • @tripleee The meaning was more like "you can't exec() shell functions" :-)
    – nohillside
    Commented Sep 17, 2018 at 8:50

When to write a script ...

  • Scripts assemble software components (aka. tools, commands, processes, executables, programs) into more complex components, which may themselves be assembled into still more complex components.
  • Scripts are usually made executable so they can be called by name. When called, a new subprocess is spawned for the script to run in. Copies of any exported variables and/or functions are passed by value to the script. Changes to those variables do not propagate back to the parent script.
  • Scripts may also be loaded(sourced) as if they were part of the calling script. This is analogous to what some other languages call "import" or "include". When sourced, they execute within the existing process. No subprocess is spawned.

When to write a function ...

  • Functions are effectively pre-loaded shell scripts. They perform a bit better than calling a separate script, but only if it must be read from mechanical disk. Today's proliferation of flashdrives, SSDs and Linux's normal caching in unused RAM make that improvement largely unmeasurable.
  • Functions serve as bash's principle means of achieving modularity, encapsulation and reuse. They improve the clarity, reliability and maintainability of scripts.
  • The syntax rules for calling a function are identical to that of calling an executable. A function with the same name as an executable would be invoked instead of the executable.
  • Functions are local to the script they are in.
  • Functions may be exported (copied by value) so they can be used inside called scripts. Thus, functions only propagate to child processes, never parents.
  • Functions create reusable commands that are often assembled into libraries (a script with only function definitions) to be sourced by other scripts.

When to write an alias ...

Within scripts like library scripts, sometimes an alias for a function is needed, such as when a function is renamed but backward compatibility is required. This can be accomplished by creating a simple function with the old name that passes all its arguments to the new function...

# A bash in-script 'alias'
function oldFunction () { newFunction "$@"; }

A comprehensive description of the alias command in bash and other shells can be found at Wikipedia/Alias (command)

  • 1
    "aliases don't work inside shell script constructs like if/then and for/do loops" does not appear to be the case in any shell I tried.
    – Mikel
    Commented May 2, 2020 at 16:02
  • 1
    The question was only about bash. Aliases can be of limited use by setting a shell option, shopt -s expand_aliases, but using functions is more robust. I've added a link to a Wikipedia article that may be helpful. Commented May 3, 2020 at 5:52
  • 1
    Ah! expand_aliases was on. Thanks for the clarification!
    – Mikel
    Commented May 3, 2020 at 16:40

Here are some additional points about aliases and functions:

  • Same-named alias and function can co-exist
  • alias namespace is looked up first (see first example)
  • aliases cannot be (un)set in subshells or non-interactive environment (see second example)

For example:

alias f='echo Alias'; f             # prints "Alias"
function f { echo 'Function'; }; f  # prints "Alias"
unalias f; f                        # prints "Function"

As we can see, there are separate namespaces for aliases and functions; more details can be found using declare -A -p BASH_ALIASES and declare -f f, which prints their definitions (both are stored in memory).

Example showing limitations of aliases:

alias a='echo Alias'
a        # OK: prints "Alias"
eval a;  # OK: prints "Alias"
( alias a="Nested"; a );  # prints "Alias" (not "Nested")
( unalias a; a );         # prints "Alias"
bash -c "alias aa='Another Alias'; aa"  # ERROR: bash: aa: command not found

As we can see aliases are not nestable, unlike functions. Also, their usage is limited to the interactive sessions.

Finally, note that you can have arbitrary computation in an alias by declaring a function a immediately calling it, like so:

alias a_complex_thing='f() { do_stuff_in_function; } f'

which is already in widespread use in case of Git aliases. The benefit of doing so over declaring a function is that your alias cannot be simply overwritten by source-ing (or using .) a script which happens to declare a same-named function.

  • bash won't expand aliases in non-interactive mode, unless expand_aliases is set:bash -c $'shopt -s expand_aliases;alias aa="echo Another Alias"\naa'. Commented Mar 24 at 12:54

One other thing that I don't believe has been brought up: a function executes in the context of the invoking process, whereas a script forks a new shell.

This could be important for performance -- a function is faster, since it doesn't fork() and exec(). In normal circumstances, the difference is trivial, but if you are debugging a system that is out of memory and is page-thrashing, it could make a big difference.

Also, if you want to modify your current shell environment, you should use a function. For example, a function could change the command lookup $PATH for the current shell, but a script cannot, because it operates on a fork/exec copy of $PATH.

  • How does this propagation of functions to children work?
    – HappyFace
    Commented Dec 16, 2018 at 21:27
  • 1
    @HappyFace In Bash you can export -f a function, though the precise inner workings of this are somewhat obscure. This is not portable to traditional Bourne shell I believe.
    – tripleee
    Commented Aug 5, 2019 at 16:53

Script and alias and script and function aren't mutually exclusive. You can and do store aliases and functions in scripts.

Scripts are just code which is made persistent. Useful functions and aliases which you like to use in the future are stored in scripts. However, a script is often a collection of more than one function.

Since aliases aren't parameterized, they are very limited; usually to define some default parameters.

A function is a separate unit of code, a well-defined concept of a few lines of code which can't separated into smaller, useful parts; one which can be reused directly or other by other functions.


If it should be very fast, make it an alias or a function.

If it should be usable outside your preferred shell, make it a script.1

If it takes arguments, make it a function or a script.

If it needs to contain special characters, make it an alias or a script.2

If it needs to work with sudo, make it an alias or a script.3

If you want to change it easily without logging out and in, a script is easier.4


1 Or make it an alias, put it in ~/.env and set export ENV="$HOME/.env", but it's complicated to make it work portably.

2 Function names must be identifiers, so they must start with a letter, and may only contain letters, digits, and underscores. For example, I have an alias alias +='pushd +1'. It can't be a function.

3 And add the alias alias sudo='sudo '. Ditto any other command such as strace, gdb, etc. that takes a command as its first argument.

4 See also: fpath. Of course you can also do source ~/.bashrc or similar, but this often has other side effects.

  • 1
    I didn't know you could alias + in bash. Interestingly, after testing I discovered that in bash you can make + an alias but not a function, as you say, but zsh is the reverse - + can be a function but not an alias.
    – Kevin
    Commented May 9, 2012 at 18:42
  • In zsh you have to write alias -- +='some command here'.
    – Mikel
    Commented May 10, 2012 at 1:07
  • Somehow, I don't think aliasing + is portable. See the POSIX spec on Alias Names
    – jw013
    Commented Aug 23, 2012 at 18:08
  • 4
    Upvote for covering sudo usage. Regarding footnote 4, I store my aliases in ~/.bash_aliases and function definitions in ~/.bash_functions so I can easily resource them (without any danger of side effects). Commented Nov 19, 2015 at 11:15

In a multi user ( or multi sysamin ) environment, I use scripts for everything, even if it just ends up being a short 'exec something....' wrapper.

Sure, it's technically slower/less efficient than an alias or function, but that almost never matters - and provided it's in the path, a script always works.

Your feature might be called from cron, from something with a reduced or modified environment like sudo or env, or the user may just be using a different shell to you - all or which is likely to break an alias or function.

If you have something performance sensitive, handle that as a special case, or better yet, consider that a trigger to rewrite in a more functional scripting language.

If we're talking about features that will only be used in other scripts, then you can also consider defining a standard shell, and writing a function library script that can just be . sourced I to all other scripts.



Just to add a few notes:

  • Only separate script can be used with sudo (like if you need to edit a system file), for example:
sudo v /etc/rc.conf  #where v runs vim in a new terminal window;
  • Only aliases or functions could replace system commands under same name (assuming that you add your scripts dir to the end of PATH, which I think is advisable for safety in case of accidental or malevolent creating of script with name identical to a system command), for example:
alias ls='ls --color=auto'  #enable colored output;
  • Aliases and functions take less memory and time for execution, but take time to load (since shell has to interpret them all before showing you prompt). Take this into account if you run new shell processes regularily, for example:
# pressing key to open new terminal
# waiting for a few seconds before shell prompt finally appears.

Other than that, you could use the simplest form possible, i.e. first consider alias, then function, then script.

  • 5
    Aliases can also be used with sudo. But first you need alias sudo='sudo '.
    – Mikel
    Commented May 9, 2012 at 15:32
  • While it is true that executing a script will momentarily consume more memory for the duration of the fork+exec, having a lot of code loaded into the memory of the current shell instance makes it consume more memory going forward, often to store code which only gets used fairly rarely.
    – tripleee
    Commented Aug 19, 2018 at 8:17
  • "Only separate script can be used with sudo" : NO. you can have sudo inside the alias or function or script. "Only aliases or functions could replace system commands under same name " : No again. You can have your own scripts that replace system commands.
    – ychaouche
    Commented Aug 15, 2022 at 11:55

My rule of thumb is:

  • aliases - one command, no parameters
  • functions - one command some parameters
  • script - several commands, no parameters

When to write a script

When you might want to run the command from a tool other than the shell.

This includes vim (for me): having written filters and other programs as scripts, I can do something like :%!my-filter to filter a file through the program from my editor.

If my-filter were a function or alias, that would not be possible.


I can only comment as to my personal use of aliases (especially if you're slow with the keyboard like me. Or can not touch type. Also like me) I find it much easier to use aliases to capture seldom used but complicated commands, especially ones like:
alias dockpurge='docker rmi $(docker images | grep "^<none>" | awk "{print $3}")'
which I rarely use but none-the-less find useful.
Or even commonly used commands that I find easier to alias to just a few key strokes like:
alias mcpi='mvn clean compile package install'
because I am just that lazy :) If I were to summarise, One's use of alias is a personal combination of one's own common sense and personal taste (best practices notwithstanding).


An Example for a Situation Where you Most Likely Would Like to use an Alias.

I know this is an old post but I would like to point out a situation where I almost had to use a combination of alias with a script and I chose not to use a function.

I have a script in ~/.bin/ called setup that does the following:1

  1. brings me to a certain directory.
  2. defines a few variables.
  3. prints messages about the state of the directory.2

The point is that if I would just run setup <project-name> I wouldn't have those variables defined and I wouldn't have gotten to the directory at all. The solution I found to be the best was to add this script to PATH and add alias setup=". ~/.bin/setup" to ~/.bashrc or whatever.


  1. I used a script for this task and not a function not because it's particularly long but because I can edit it and I don't have to source the file after an edit if I want to refresh it's usage.
  2. A similar case accoured to me when I created a script to reload all my dotfiles.3
  1. The script is available in my dotfiles repository under .bin/.
  2. About the script: I give this script an argument which is a name for the project I defined in advanced. Afterwards the script knows to bring to me to the right directory according to a certain csv file. The variables it defines are taken from the makefile in that directory. The script runs afterwards ls -l and git status to show me what's going on there.
  3. That script is also available in my dotfiles repository under .bin/ as well.
  • 1
    Hm, seems that should just be a function, not an alias-script combination. (BTW, environments is spelled "environments" not "enviorments.")
    – Wildcard
    Commented Apr 25, 2016 at 19:57
  • Thanks for commenting about the typo, I shall fix it on the next commit. As for using a function instead of a script - perhaps I'll use a function for this particular task and drop these aliases. The point is that sometimes it's quite easy to use a script and an alias if you edit that script from time to time. Commented Apr 25, 2016 at 22:46

This is not an answer but rather a lengthy comment about aliases.

Aliases don't have to be trivial

A few examples

# Window Identification
alias wid='ps $(xprop | (pid=$(command grep PID); echo ${pid##*=}))'

# puts the shrugg ASCII emoji in the clipboard
alias shrugg='echo -n "¯\_(ツ)_/¯" | xclip -i; echo "¯\_(ツ)_/¯ copied to the clipboard"'

# Capturing desktop with ffmpeg, video = wo/ sound, av = w/ sound.
alias desktop.capture.video='ffmpeg -f x11grab -r 25 -s 1900x1000 -i :0.0+0,24 -vcodec libx264  -threads 0'
alias desktop.capture.av='ffmpeg -f x11grab -r 25 -s 1900x1000 -i :0.0+0,24 -vcodec libx264  -threads 0 -f alsa -i hw:0 '

# how many days I've been working @ my current job.
# $ work
# 2828 days, 0:00:00
# $

alias work='python -c "import datetime; print datetime.date.today() - datetime.date(2014,11,17)"'

# grep an IP address
alias grep.ip="grep '\([[:digit:]]\{1,3\}\.\)\{3\}[[:digit:]]\{1,3\}'"

# Remove blanks and comments from text files
# Useful when you want to see that config file in a single terminal page
alias pretty.remove.blanks+comments="egrep -v '(^[[:space:]]*#|^$|^[[:space:]]*//|^[[:space:]]*;)'"

# +--------------------+
# | system information |
# +--------------------+
alias sys.distro="for file in /etc/{*issue*,*version*,*release*}; do [[ -f \$file ]] && cat \$file && break; done;"
alias sys.processes.cpu.highest="ps ux | sort -k3nr | head -1"
alias sys.processes.rss.highest="ps ux | sort -k6nr | head -1"
alias sys.processes.mem.highest="sys.processes.rss.highest"

Aliases can be used to suite your own way of thinking about things.

Why do I have to remember the command to print my local IP and the other command for my public IP? Let's have all IP related commands aliased with a net.ip prefix. This also leverages the power of tab completion when looking for such commands so I don't even have to remember them, I just access them.

alias net.ip.private="ifdata -pa $INTERFACE"
alias net.ip.public='curl ifconfig.me; echo'

# Have all package related commands under the package prefix
alias package.is.installed="dpkg-query -W"
alias package.search.byname="apt-cache search"
alias package.search.byfile="apt-file search"
alias package.install='_asroot apt-get install'
alias package.remove='_asroot apt-get remove'

Aliases don't have to be oneliners

See this example

# _extract_clean_line : used to parse postfix log files
#  $ _extract_mail_to_mail /var/log/mail.log | head -2
# Aug 15 06:30:02 messagerie amavis[52012]: (52012-17) Passed CLEAN {RelayedOpenRelay}, [] <[email protected]> -> <[email protected]>, Message-ID: <[email protected]>, mail_id: qJKvO_yRwa1V, Hits: -0.011, size: 1434, queued_as: BC2573A80097, 293 ms
# Aug 15 06:30:16 messagerie amavis[53456]: (53456-14) Passed CLEAN {RelayedOpenRelay}, [] <[email protected]> -> <[email protected]>, Message-ID: <[email protected]>, mail_id: V89PBpOj6gnr, Hits: -0.011, size: 13257, queued_as: 716C23A80097, 756 ms
#  $ _extract_mail_to_mail /var/log/mail.log | head -2 | _extract_clean_line
# Aug 15 06:30:02 [] <[email protected]> -> <[email protected]>, Hits: -0.011
# Aug 15 06:30:16 [] <[email protected]> -> <[email protected]>, Hits: -0.011
#  $

alias _extract_clean_line="
sed -u \"
# removes prefixes like
# messagerie amavis[31953]: (31953-20) Passed SPAMMY {RelayedTaggedInbound},
s/messagerie[^}]\+\}, //;

# removes trailing info like
# Queue-ID: DFFC83A800A5, Message-ID: <[email protected]>, mail_id: UXj46jSTdsyC, Hits: 7.857,
# becomes :
# Hits: 7.857,

# removes trailing line after Hits w/o removing Hits itself
# Hits: 7.857, size: 25552, queued_as: 7286B3A800A7, 5432 ms
# becomes
# Hits: 7.857
s/, size.*//;

# puts e-mail addresses on their own lines, instead of all in one line.
s/,<\([[:alnum:]\.@-]\+\)>/\n                 <\1>/g\""

Aliases can be combined

mail.exchange.live is an alias composed of aliases

alias _extract_mail_to_mail="egrep --line-buffered \"<$REGX_EMAIL> -> <$REGX_EMAIL>\""
alias mail.exchange.live='tail -f /var/log/mail.log | _extract_mail_to_mail | _extract_clean_line'

_extract_clean_line was already pasted above

both _extract_clean_line and _extract_mail_to_mail are used in many other aliases and functions

 alias mail.spam.report="_extract_mail_to_mail  /var/log/mail.log  | grep SPAM | _extract_clean_line"
 alias mail.exchange.from.outside="_extract_mail_to_mail  /var/log/mail.log  | grep -v 'mydomain.tld> ->' | _extract_clean_line"

function mail.exchange.from(){
_extract_mail_to_mail /var/log/mail.log | grep -- "$1.*->" | _extract_clean_line

function mail.exchange.to(){
_extract_mail_to_mail /var/log/mail.log | grep -- "->.*$1" | _extract_clean_line 

if you're curious about what these do, here are two examples :

1/ mail.exchange.to

$ mail.exchange.to [email protected] | tail -5
Aug 16 11:07:03 []:15043 [] <[email protected]> -> <[email protected]>, Hits: -1.557
Aug 16 11:49:34 LOCAL []:64801 <[email protected]> -> <[email protected]>, Hits: -0.769
Aug 16 12:17:49 []:60799 [2604:8d00:189::2] <[email protected]> -> <[email protected]>, Hits: -1.557
Aug 16 12:22:10 []:55331 [2604:8d00:189::2] <[email protected]> -> <[email protected]>, Hits: -1.557
Aug 16 12:33:56 []:33725 [2a04:b900::1:0:0:15] <[email protected]> -> <[email protected]>, Hits: -3.412

2/ mail.spam.report

$ mail.spam.report | tail -5
Aug 16 10:21:52 []:17337 [] <[email protected]> -> <[email protected]>, Hits: 8.538
Aug 16 12:07:45 LOCAL []:36104 <[email protected]> -> <[email protected]>, Hits: 7.891
Aug 16 12:17:30 []:39282 [] <[email protected]> -> <[email protected]>, Hits: 5.907
Aug 16 12:19:05 []:59942 [] <[email protected]> -> <[email protected]>, Hits: 5.907
Aug 16 12:34:44 []:43976 [] <[email protected]> -> <[email protected]>, quarantine: e/spam-eaU9U0MofNq1.gz, Hits: 17.991

Aliases may contain loops and variables

You just have to be careful to escape the dollar sign when creating and using variables inside aliases. For example :

alias flow.tasks.list="for file in ~/NOTES/LOG/TASKS/*.flow; do echo file \$file; echo '---------------------------------------------------'; egrep -h '^\*\* \[[0-9]' \$file; echo; done | less"

This produces the following output

** [1] dns query taking too long
** [1.1] query time

** [1] see if savefrom.net works again
** [2] search for alternatives to savefrom.net

** [1] erreur
** [2] copy-heading.flow

** [1] joins
** [2] requêtes sur la table contacts
** [3] cacher le mot de pass

Aliases may be called like commands

Consider this example

alias sys.window.pid="pid=\$(xprop | grep PID); echo \${pid##*=}; unset pid"
alias sys.window.trace="_asroot strace -p \$(sys.window.pid)"

Use sys.window.trace to run strace on any window by point and click. This uses sys.window.pid, also an alias that returns the pid of any window by point and click.

Notice how sys.window.pid is called like a command substitution. Without the $, you'd get strace complaining that sys.window.pid is an invalid pid.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .