Examples of .bashrc files

File .bashrc is executed both in interactive sessions and non-interactive sessions. Some people put aliases in .bashrc -- that's wrong -- aliases are  used in interactive sessions only. Their proper place is .bash_profile or .profile.

Many people never manage understand the complex semantic of Unix "dot files".

For example the name of the file that  we are discussing  .bashrc is not fixed. It is just a default name.  It is so called $ENV file -- the file, the name of which is defined in in the environment variable ENV. The name is actually user selectable and can be set in /etc/profile. Or, for exteactive session, in the  user .profile or .bash_profile if it is used. the latter measn that you can use differene $ENV vlues for ineractive and non interactive sessions, although I do not see how it can useful.

And before .bashrc is sourced for the current session several other files are sourced before it. In Linux the process is so convoluted that it requires special tutorial

In case of interactive sessions at least three files and all application related chunks stored in /etc/profile.d directory are sourced:

1. /etc/profile -- system wide shell initialization script. Executed during login only for each user including root. .profile is a user customizable part of the profile.  Bash uses .bash_profile instead of .profile if it exists.  Within /etc/[profile there is a code fragment that executed all entries in /etc/profile.d those entries are usually created when you install packages, but sometimes sysadmins also create entries in this directory (and then forget about it and face possible negative consequences in a year or two). Generally you should not use /etc/profile.d for your custom "shell chunks" as this make your environment more complex then it should be. And it is already way too complex.

   It does five major things

   • sets  EUID and UID environment variables and then based on them constructs PATH variable using function pathmunge (which should be named concat ;-)  as a tool.
   • Sources all chunks from /etc/profile.d directory
   • set umask depending on you UID
   • set some shell history parameters
   • exports PATH USER LOGNAME MAIL HOSTNAME HISTSIZE and HISTCONTROL  env variables.
      
2. ~/.bash_profile or ~/.profile  (less commonly). This file should set inteactive environment for user sessions. It was commonly named .profile in is old ksh93 and ksh88 on all major Unixes, and to avoid conflicts, bash which in the past was upstart shell fighting for recognition, invented its own name    ~/.bash_profile, It runs exactly once per interactive session -- when you login, unless you source it manually from somewhere.
   As it runs after system wide /etc/profile script is sourced, this is the second dot file in the Linux chain of executions of dot files (we do not count /etc/profile.d chunks here; they just muddy the whole picture).  Here you put customarizations that are valuable for interactive sessions (and interactive sessions only) -- typically aliases and related environment variables. The default  code for ~/.bash_profile  that comes with Linux distributions just sources /etc/bashrc and adds to the PATH ~/bin directory.  That means that it also sources /etc/bashrc.
3. /etc/bashrc.  Sources if the default ~/.bash_profile is used (see above).

All in all I think that with that many files left hand often is not understanding what right is doing (that's why code in /etc/profile duplicates the code in /etc/bashrc despite the fact that /etc/bashrc is implicitly sourced in all interactive sessions that use the default .bash_profile file). So you probably need to keep things simple to avoid nasty surprises. That's why Environment modules packages recently became so popular, especially in HPC environment and "mass produced" virtual machines setups.   It address the core problem, the cancer of overcomplexity within the Linux system of dot files.

For non-interactive sessions the situation is simpler. but not by much: 

1. $ENV file (name is user selectable but in Linux typically is default --  .bashrc ). Executed upon each non-interactive invocation of the shell. If this variable contains a name of a file readable by a particular user it will be executed each time shell is invoked.
   Default file  ~/.bashrc supplied with Linux distributions sources /etc/bashrc file.
2. /etc/bashrc  -- This is unique to Linux file is a component similar to chunks in /etc/profile.d and is not independent. It can be called "Linux common settings for non-interactive sessions). It is is just a pervert convention that add complexity to the environment -- a chunk of code that sourced from the code contained in /etc/profile and also from the code in the default  ~/.bash_profile.The name /etc/bashrc is also slightly deceptive. In a pervert way it is used to set shell prompt (the perversion is connected with the fact that shell prompt is used only for interactive session, while the name bashrc implies non-interactive sessions. It also duplicates parts of /etc/profile code -- sets PATH. and UMASK (differently for users with UID less then 200 (system users) and the users with the UID above this threshold. It also sources all components stored in /etc/profile.d  -- so despite its name the directory /etc/profile.d is always sourced in non-interactive sessions.  That's by design.  So in reality /etc/profile.d should be properly named /etc/bashrc.d.
3. Anything sourced in this file

The main difference between your $HOME/.profile and $ENV is that $ENV is run every time a shell starts, while $HOME/.profile runs only when and if you login into interactive session. For this reason, the typical thing you want to do in this script is set, or modify all critical environment variable. but not aliases -- they belong to .bash_profile.

Do not set excessive number of environment variables (with possible exception of $PATH) in this file.  Please note that all exported environment variables are propagated to the child processes from the login shell.

IMHO this file should be minimal. Really minimal, if you use multiple application that requre thier own complex env setup.  Such things as aliases which are used only in interactive sessions are probably redundant , and while they do not hurt, they complicate the file and hamper understanding of what's going on.

NEWS CONTENTS

• 20210324 : What commands are missing from your bashrc file- - Enable Sysadmin ( Mar 24, 2021 , www.redhat.com )
• 20170729 : If processes inherit the parents environment, why do we need export? ( Jul 29, 2017 , unix.stackexchange.com )
• 20170729 : Why does subshell not inherit exported variable (PS1)? ( Jul 29, 2017 , superuser.com )
• 20170729 : Bash subshell mystery ( Jul 29, 2017 , stackoverflow.com )
• 20170729 : How To Read and Set Environmental and Shell Variables on a Linux VPS ( Mar 03, 2014 , www.digitalocean.com )
• 20170729 : shell - Whats the difference between .bashrc, .bash_profile, and .environment - Stack Overflow ( Jul 29, 2017 , stackoverflow.com )
• 20170728 : bash - About .bash_profile, .bashrc, and where should alias be written in - Stack Overflow ( Jul 28, 2017 , stackoverflow.com )
• 20170728 : jonty /.bashrc ( jonty /.bashrc , )
• 20170728 : cron0 /.bashrc ( cron0 /.bashrc , )
• 20170728 : brogers /.bashrc ( http://dotfiles.org/~brogers/.bashrc )
• 20170728 : An interesting example of .bashrc with the ability to extract files from archive on the base of imitation of a part of Norton Commander functionality ;-) ( http://dotfiles.org/~joephantom/.bashrc )
• 20170728 : A Sample .bashrc File ( tldp.org )
• 20071209 : Cool Solutions Bash - Making use of your .bashrc file ( Cool Solutions Bash - Making use of your .bashrc file, Dec 9, 2007 )
• 20071209 : Cool Solutions Bash - Making use of your .bashrc file ( Cool Solutions Bash - Making use of your .bashrc file, Dec 9, 2007 )
• 20071209 : Jamies Shell Stuff ( Jamie's Shell Stuff, )

Old News ;-)

Note: in a somewhat strange way most users below use .bashrc as a substitute for .bash_profile and put aliases and similar things valuable only for interactive sessions in it. For non-interactive session aliases are equivalent to comments and just complicate understanding of your .bashrc file. That be this is implicit trend toward simplification of overly complex Linux dot files environment and ignoring .bash_profile altogather.

[Mar 24, 2021] What commands are missing from your bashrc file- - Enable Sysadmin

Mar 24, 2021 | www.redhat.com

The idea was that sharing this would inspire others to improve their bashrc savviness. Take a look at what our Sudoers group shared and, please, borrow anything you like to make your sysadmin life easier.

[ You might also like: Parsing Bash history in Linux ]

Jonathan Roemer

# Require confirmation before overwriting target files. This setting keeps me from deleting things I didn't expect to, etc
alias cp='cp -i'
alias mv='mv -i'
alias rm='rm -i'

# Add color, formatting, etc to ls without re-typing a bunch of options every time
alias ll='ls -alhF'
alias ls="ls --color"
# So I don't need to remember the options to tar every time
alias untar='tar xzvf'
alias tarup='tar czvf'

# Changing the default editor, I'm sure a bunch of people have this so they don't get dropped into vi instead of vim, etc. A lot of distributions have system default overrides for these, but I don't like relying on that being around
alias vim='nvim'
alias vi='nvim'

Valentin Bajrami

Here are a few functions from my ~/.bashrc file:

# Easy copy the content of a file without using cat / selecting it etc. It requires xclip to be installed
# Example:  _cp /etc/dnsmasq.conf
_cp()
{
  local file="$1"
  local st=1
  if [[ -f $file ]]; then
    cat "$file" | xclip -selection clipboard
    st=$?
  else
    printf '%s\n' "Make sure you are copying the content of a file" >&2
  fi
  return $st    
}

# This is the function to paste the content. The content is now in your buffer.
# Example: _paste   

_paste()
{
  xclip -selection cliboard -o
}

# Generate a random password without installing any external tooling
genpw()
{
  alphanum=( {a..z} {A..Z} {0..9} ); for((i=0;i<=${#alphanum[@]};i++)); do printf '%s' "${alphanum[@]:$((RANDOM%255)):1}"; done; echo
}
# See what command you are using the most (this parses the history command)
cm() {
  history | awk ' { a[$4]++ } END { for ( i in a ) print a[i], i | "sort -rn | head -n10"}' | awk '$1 > max{ max=$1} { bar=""; i=s=10*$1/max;while(i-->0)bar=bar"#"; printf "%25s %15d %s %s", $2, $1,bar, "\n"; }'
}

Peter Gervase

For shutting down at night, I kill all SSH sessions and then kill any VPN connections:

#!/bin/bash
/usr/bin/killall ssh
/usr/bin/nmcli connection down "Raleigh (RDU2)"
/usr/bin/nmcli connection down "Phoenix (PHX2)"

Valentin Rothberg

alias vim='nvim'
alias l='ls -CF --color=always''
alias cd='cd -P' # follow symlinks
alias gits='git status'
alias gitu='git remote update'
alias gitum='git reset --hard upstream/master'

Steve Ovens

alias nano='nano -wET 4'
alias ls='ls --color=auto'
PS1="\[\e[01;32m\]\u@\h \[\e[01;34m\]\w  \[\e[01;34m\]$\[\e[00m\] "
export EDITOR=nano
export AURDEST=/var/cache/pacman/pkg
PATH=$PATH:/home/stratus/.gem/ruby/2.7.0/bin
alias mp3youtube='youtube-dl -x --audio-format mp3'
alias grep='grep --color'
alias best-youtube='youtube-dl -r 1M --yes-playlist -f 'bestvideo[ext=mp4]+bestaudio[ext=m4a]''
alias mv='mv -vv'
shopt -s histappend
HISTCONTROL=ignoreboth

Jason Hibbets

While my bashrc aliases aren't as sophisticated as the previous technologists, you can probably tell I really like shortcuts:

# User specific aliases and functions

alias q='exit'
alias h='cd ~/'
alias c='clear'
alias m='man'
alias lsa='ls -al'
alias s='sudo su -'

More Linux resources

• Advanced Linux Commands Cheat Sheet for Developers
• Get Started with Red Hat Insights
• Download Now: Basic Linux Commands Cheat Sheet
• Linux System Administration Skills Assessment

Bonus: Organizing bashrc files and cleaning up files

We know many sysadmins like to script things to make their work more automated. Here are a few tips from our Sudoers that you might find useful.

Chris Collins

I don't know who I need to thank for this, some awesome woman on Twitter whose name I no longer remember, but it's changed the organization of my bash aliases and commands completely.

I have Ansible drop individual <something>.bashrc files into ~/.bashrc.d/ with any alias or command or shortcut I want, related to any particular technology or Ansible role, and can manage them all separately per host. It's been the best single trick I've learned for .bashrc files ever.

Git stuff gets a ~/.bashrc.d/git.bashrc , Kubernetes goes in ~/.bashrc.d/kube.bashrc .

if [ -d ${HOME}/.bashrc.d ]
then
  for file in ~/.bashrc.d/*.bashrc
  do
    source "${file}"
  done
fi

Peter Gervase

These aren't bashrc aliases, but I use them all the time. I wrote a little script named clean for getting rid of excess lines in files. For example, here's nsswitch.conf with lots of comments and blank lines:

[pgervase@pgervase etc]$ head authselect/nsswitch.conf
# Generated by authselect on Sun Dec  6 22:12:26 2020
# Do not modify this file manually.

# If you want to make changes to nsswitch.conf please modify
# /etc/authselect/user-nsswitch.conf and run 'authselect apply-changes'.
#
# Note that your changes may not be applied as they may be
# overwritten by selected profile. Maps set in the authselect
# profile always take precedence and overwrites the same maps
# set in the user file. Only maps that are not set by the profile

[pgervase@pgervase etc]$ wc -l authselect/nsswitch.conf
80 authselect/nsswitch.conf

[pgervase@pgervase etc]$ clean authselect/nsswitch.conf
passwd:     sss files systemd
group:      sss files systemd
netgroup:   sss files
automount:  sss files
services:   sss files
shadow:     files sss
hosts:      files dns myhostname
bootparams: files
ethers:     files
netmasks:   files
networks:   files
protocols:  files
rpc:        files
publickey:  files
aliases:    files

[pgervase@pgervase etc]$ cat `which clean`
#! /bin/bash
#
/bin/cat $1 | /bin/sed 's/^[ \t]*//' | /bin/grep -v -e "^#" -e "^;" -e "^[[:space:]]*$" -e "^[ \t]+"

[ Free online course: Red Hat Enterprise Linux technical overview . ]

[Jul 29, 2017] If processes inherit the parents environment, why do we need export?

Notable quotes:

"... "Processes inherit their environment from their parent (the process which started them)." ..."

"... in the environment ..."

Jul 29, 2017 | unix.stackexchange.com

Amelio Vazquez-Reina asked May 19 '14

I read here that the purpose of export in a shell is to make the variable available to sub-processes started from the shell.

However, I have also read here and here that "Processes inherit their environment from their parent (the process which started them)."

If this is the case, why do we need export ? What am I missing?

Are shell variables not part of the environment by default? What is the difference?

Your assumption is that all shell variables are in the environment . This is incorrect. The export command is what defines a name to be in the environment at all. Thus:

a=1
b=2
export b

results in the current shell knowing that $a expands to 1 and $b to 2, but subprocesses will not know anything about a because it is not part of the environment (even in the current shell).

Some useful tools:

• set : Useful for viewing the current shell's parameters, exported-or-not
• set -k : Sets assigned args in the environment. Consider f() { set -k; env; }; f a=1
• export : Tells the shell to put a name in the environment. Export and assignment are two entirely different operations.
• env : As an external command, env can only tell you about the inherited environment, thus, it's useful for sanity checking.
• env -i : Useful for clearing the environment before starting a subprocess.

Alternatives to export :

1. name=val command # Assignment before command exports that name to the command.
2. declare/local -x name # Exports name, particularly useful in shell functions when you want to avoid exposing the name to outside scope.

====

There's a difference between shell variables and environment variables. If you define a shell variable without export ing it, it is not added to the processes environment and thus not inherited to its children.

Using export you tell the shell to add the shell variable to the environment. You can test this using printenv (which just prints its environment to stdout, since it's a child-process you see the effect of export ing variables):

#!/bin/sh
MYVAR="my cool variable"
echo "Without export:"
printenv | grep MYVAR
echo "With export:"
export MYVAR 
printenv | grep MYVAR

A variable, once exported, is part of the environment. PATH is exported in the shell itself, while custom variables can be exported as needed.

... ... ..

[Jul 29, 2017] Why does subshell not inherit exported variable (PS1)?

Jul 29, 2017 | superuser.com

up vote down vote favorite 1 I am using startx to start the graphical environment. I have a very simple .xinitrc which I will add things to as I set up the environment, but for now it is as follows:

catwm
&
# Just a basic window manager, for testing.


xterm

The reason I background the WM and foreground terminal and not the other way around as often is done, is because I would like to be able to come back to the virtual text console after typing exit in xterm . This appears to work as described.

The problem is that the PS1 variable that currently is set to my preference in /etc/profile.d/user.sh (which is sourced from /etc/profile supplied by distro), does not appear to propagate to the environment of the xterm mentioned above. The relevant process tree is as follows:

\_
bash
    \_ xinit
home
user
/.
xinitrc
--
etc
X11
xinit
xserverrc
auth
tmp
serverauth
ggJna3I0vx
        \_
usr
bin
nolisten tcp
auth
tmp
serverauth
ggJna3I0vx vt1
        \_ sh
home
user
/.
xinitrc
            \_
home
user
catwm
            \_ xterm
                \_ bash

The shell started by xterm appears to be interactive, the shell executing .xinitrc however is not. I am ok with both, the assumptions about interactivity seem to be perfectly valid, but now I have a non-interactive shell that spawns an interactive shell indirectly, and the interactive shell has no chance to automatically inherit the prompt, because the prompt was unset or otherwise made unavailable higher up the process tree.

How do I go about getting my prompt back? bash environment-variables sh

share improve this question

edited Oct 21 '13 at 11:39

asked Oct 21 '13 at 9:51 amn 453 12 29

down vote accepted

Commands env and export list only variables which are exported. $PS1 is usually not exported. Try echo $PS1 in your shell to see actual value of $PS1 .

Non-interactive shells usually do not have $PS1 . Non-interactive bash explicitly unsets $PS1 . ¹ You can check if bash is interactive by echo $- . If the output contains i then it is interactive. You can explicitly start interactive shell by using the option on the command line: bash -i . Shell started with -c is not interactive.

The /etc/profile script is read for a login shell. You can start the shell as a login shell by: bash -l .

With bash shell the scripts /etc/bash.bashrc and ~/.bashrc are usually used to set $PS1 . Those scripts are sourced when interactive non-login shell is started. It is your case in the xterm .

See Setting the PS? Strings Permanently

Possible solutions

• Start the shell inside xterm as a login shell bash -l . Check if /etc/profile and ~/.profile do not contain code which should be executed only after login. Maybe slight modifications of the scripts will be needed.
• Use a different shell. For example dash does not unset $PS1 . You can use such a shell just as the non-interactive shell which will run the scripts up to xterm .
• Give up the strict POSIX compliance and use the bash-standard place for setting $PS1 : /etc/bash.bashrc or ~/.bashrc .
• Give up the strict POSIX compliance and source your own startup script like: bash --rcfile <(echo "PS1=$PS1save") -i
• Start the intermediate shells from startx till xterm as interactive shells ( bash -i ). Unfortunately this can have some side-effect and I would not do this.

share improve this answer

edited Oct 22 '13 at 16:45

answered Oct 21 '13 at 11:19 pabouk 4,250 25 40

	I am specifically avoiding to set PS1 in .bashrc or /etc/bash.bashrc (which is executed as well), to retain POSIX shell compatibility. These do not set or unset PS1 . PS1 is set in /etc/profile.d/user.sh , which is sourced by /etc/profile . Indeed, this file is only executed for login shells, however I do export PS1 from /etc/profile.d/user.sh exactly because I want propagation of my preferred value down the process tree. So it shouldn't matter which subshells are login and/or interactive ones then, should it? – amn Oct 21 '13 at 11:32
	It seems that bash removes the PS1 variable. What exactly do you want to achieve by "POSIX shell compatibility"? Do you want to be able to replace bash by a different POSIX-compliant shell and retain the same functionality? Based on my tests bash removes PS1 when it is started as non-interactive. I think of two simple solutions: 1. start the shell as a login shell with the -l option (attention for actions in the startup scripts which should be started only at login) 2. start the intermediate shells as interactive with the -i option. – pabouk Oct 21 '13 at 12:00
	I try to follow interfaces and specifications, not implementations - hence POSIX compatibility. That's important (to me). I already have one login shell - the one started by /usr/bin/login . I understand that a non-interactive shell doesn't need prompt, but unsetting a variable is too much - I need the prompt in an interactive shell (spawned and used by xterm ) later on. What am I doing wrong? I guess most people set their prompt in .bashrc which is sourced by bash anyway, and so the prompt survives. I try to avoid .bashrc however. – amn Oct 22 '13 at 12:12
	@amn: I have added various possible solutions to the reply. – pabouk Oct 22 '13 at 16:46

[Jul 29, 2017] Bash subshell mystery

Notable quotes:

"... The subshell created using parentheses does not ..."

Jul 29, 2017 | stackoverflow.com

user3718463 , asked Sep 27 '14 at 21:41

The Learning Bash Book mention that a subshell will inherit only environment variabels and file descriptors , ...etc and that it will not inherit variables that are not exported of

$ var=15
$ (echo $var)
15
$ ./file # this file include the same command echo $var

$

As i know the shell will create two subshells for () case and for ./file, but why in () case the subshell identified the var variable although it is not exported and in the ./file case it did not identify it ?

...

I tried to use strace to figure out how this happens and surprisingly i found that bash will use the same arguments for the clone system call so this means that the both forked process in () and ./file should have the same process address space of the parent, so why in () case the variable is visible to the subshell and the same does not happen for ./file case although the same arguments is based with clone system call ?

Alfe , answered Sep 27 '14 at 23:16

The subshell created using parentheses does not use an execve() call for the new process, the calling of the script does. At this point the variables from the parent shell are handled differently: The execve() passes a deliberate set of variables (the script-calling case) while not calling execve() (the parentheses case) leaves the complete set of variables intact.

Your probing using strace should have shown exactly that difference; if you did not see it, I can only assume that you made one of several possible mistakes. I will just strip down what I did to show the difference, then you can decide for yourself where your error was.

... ... ...

Nicolas Albert , answered Sep 27 '14 at 21:43

You have to export your var for child process:

export var
15

Once exported, the variable is used for all children process at the launch time (not export time).

var
15



export var

is same as

export var
var
15

is same as

export var
15

Export can be cancelled using unset . Sample: unset var .

user3718463 , answered Sep 27 '14 at 23:11

The solution for this mystery is that subshells inherit everything from the parent shell including all shell variables because they are simply called with fork or clone so they share the same memory space with the parent shell , that's why this will work

$ var=15
$ (echo $var)
15

But in the ./file , the subshell will be later followed by exec or execv system call which will clear all the previous parent variables but we still have the environment variables you can check this out using strace using -f to monitor the child subshell and you will find that there is a call to execv

[Jul 29, 2017] How To Read and Set Environmental and Shell Variables on a Linux VPS

Mar 03, 2014 | www.digitalocean.com

Introduction

---

When interacting with your server through a shell session, there are many pieces of information that your shell compiles to determine its behavior and access to resources. Some of these settings are contained within configuration settings and others are determined by user input.

One way that the shell keeps track of all of these settings and details is through an area it maintains called the environment . The environment is an area that the shell builds every time that it starts a session that contains variables that define system properties.

In this guide, we will discuss how to interact with the environment and read or set environmental and shell variables interactively and through configuration files. We will be using an Ubuntu 12.04 VPS as an example, but these details should be relevant on any Linux system.

How the Environment and Environmental Variables Work

---

Every time a shell session spawns, a process takes place to gather and compile information that should be available to the shell process and its child processes. It obtains the data for these settings from a variety of different files and settings on the system.

Basically the environment provides a medium through which the shell process can get or set settings and, in turn, pass these on to its child processes.

The environment is implemented as strings that represent key-value pairs. If multiple values are passed, they are typically separated by colon (:) characters. Each pair will generally will look something like this:

KEY
value1
value2:...

If the value contains significant white-space, quotations are used:

KEY
="
value with spaces
"

The keys in these scenarios are variables. They can be one of two types, environmental variables or shell variables.

Environmental variables are variables that are defined for the current shell and are inherited by any child shells or processes. Environmental variables are used to pass information into processes that are spawned from the shell.

Shell variables are variables that are contained exclusively within the shell in which they were set or defined. They are often used to keep track of ephemeral data, like the current working directory.

By convention, these types of variables are usually defined using all capital letters. This helps users distinguish environmental variables within other contexts.

Printing Shell and Environmental Variables

---

Each shell session keeps track of its own shell and environmental variables. We can access these in a few different ways.

We can see a list of all of our environmental variables by using the env or printenv commands. In their default state, they should function exactly the same:

printenv

---

SHELL=/bin/bash
TERM=xterm
USER=demouser
LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:su=37;41:sg=30;43:ca:...
MAIL=/var/mail/demouser
PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
PWD=/home/demouser
LANG=en_US.UTF-8
SHLVL=1
HOME=/home/demouser
LOGNAME=demouser
LESSOPEN=| /usr/bin/lesspipe %s
LESSCLOSE=/usr/bin/lesspipe %s %s
_=/usr/bin/printenv

This is fairly typical of the output of both printenv and env . The difference between the two commands is only apparent in their more specific functionality. For instance, with printenv , you can requests the values of individual variables:

printenv SHELL

---

/bin/bash

On the other hand, env let's you modify the environment that programs run in by passing a set of variable definitions into a command like this:

env VAR1="blahblah" command_to_run command_options

Since, as we learned above, child processes typically inherit the environmental variables of the parent process, this gives you the opportunity to override values or add additional variables for the child.

As you can see from the output of our printenv command, there are quite a few environmental variables set up through our system files and processes without our input.

These show the environmental variables, but how do we see shell variables?

The set command can be used for this. If we type set without any additional parameters, we will get a list of all shell variables, environmental variables, local variables, and shell functions:

set

---

BASH=/bin/bash
BASHOPTS=checkwinsize:cmdhist:expand_aliases:extglob:extquote:force_fignore:histappend:interactive_comments:login_shell:progcomp:promptvars:sourcepath
BASH_ALIASES=()
BASH_ARGC=()
BASH_ARGV=()
BASH_CMDS=()
. . .

This is usually a huge list. You probably want to pipe it into a pager program to deal with the amount of output easily:

set | less

The amount of additional information that we receive back is a bit overwhelming. We probably do not need to know all of the bash functions that are defined, for instance.

We can clean up the output by specifying that set should operate in POSIX mode, which won't print the shell functions. We can execute this in a sub-shell so that it does not change our current environment:

(set -o posix; set)

This will list all of the environmental and shell variables that are defined.

We can attempt to compare this output with the output of the env or printenv commands to try to get a list of only shell variables, but this will be imperfect due to the different ways that these commands output information:

comm -23 <(set -o posix; set | sort) <(env | sort)

This will likely still include a few environmental variables, due to the fact that the set command outputs quoted values, while the printenv and env commands do not quote the values of strings.

This should still give you a good idea of the environmental and shell variables that are set in your session.

These variables are used for all sorts of things. They provide an alternative way of setting persistent values for the session between processes, without writing changes to a file.

Common Environmental and Shell Variables

---

Some environmental and shell variables are very useful and are referenced fairly often.

Here are some common environmental variables that you will come across:

• SHELL : This describes the shell that will be interpreting any commands you type in. In most cases, this will be bash by default, but other values can be set if you prefer other options.
• TERM : This specifies the type of terminal to emulate when running the shell. Different hardware terminals can be emulated for different operating requirements. You usually won't need to worry about this though.
• USER : The current logged in user.
• PWD : The current working directory.
• OLDPWD : The previous working directory. This is kept by the shell in order to switch back to your previous directory by running cd - .
• LS_COLORS : This defines color codes that are used to optionally add colored output to the ls command. This is used to distinguish different file types and provide more info to the user at a glance.
• MAIL : The path to the current user's mailbox.
• PATH : A list of directories that the system will check when looking for commands. When a user types in a command, the system will check directories in this order for the executable.
• LANG : The current language and localization settings, including character encoding.
• HOME : The current user's home directory.
• : The most recent previously executed command.

In addition to these environmental variables, some shell variables that you'll often see are:

• BASHOPTS : The list of options that were used when bash was executed. This can be useful for finding out if the shell environment will operate in the way you want it to.
• BASH_VERSION : The version of bash being executed, in human-readable form.
• BASH_VERSINFO : The version of bash, in machine-readable output.
• COLUMNS : The number of columns wide that are being used to draw output on the screen.
• DIRSTACK : The stack of directories that are available with the pushd and popd commands.
• HISTFILESIZE : Number of lines of command history stored to a file.
• HISTSIZE : Number of lines of command history allowed in memory.
• HOSTNAME : The hostname of the computer at this time.
• IFS : The internal field separator to separate input on the command line. By default, this is a space.
• PS1 : The primary command prompt definition. This is used to define what your prompt looks like when you start a shell session. The PS2 is used to declare secondary prompts for when a command spans multiple lines.
• SHELLOPTS : Shell options that can be set with the set option.
• UID : The UID of the current user.

Setting Shell and Environmental Variables

---

To better understand the difference between shell and environmental variables, and to introduce the syntax for setting these variables, we will do a small demonstration.

Creating Shell Variables

---

We will begin by defining a shell variable within our current session. This is easy to accomplish; we only need to specify a name and a value. We'll adhere to the convention of keeping all caps for the variable name, and set it to a simple string.

TEST_VAR='Hello World!'

Here, we've used quotations since the value of our variable contains a space. Furthermore, we've used single quotes because the exclamation point is a special character in the bash shell that normally expands to the bash history if it is not escaped or put into single quotes.

We now have a shell variable. This variable is available in our current session, but will not be passed down to child processes.

We can see this by grepping for our new variable within the set output:

set | grep TEST_VAR

---

TEST_VAR='Hello World!'

We can verify that this is not an environmental variable by trying the same thing with printenv :

printenv | grep TEST_VAR

No out should be returned.

Let's take this as an opportunity to demonstrate a way of accessing the value of any shell or environmental variable.

echo $TEST_VAR

---

Hello World!

As you can see, reference the value of a variable by preceding it with a $ sign. The shell takes this to mean that it should substitute the value of the variable when it comes across this.

So now we have a shell variable. It shouldn't be passed on to any child processes. We can spawn a new bash shell from within our current one to demonstrate:

bash
echo $TEST_VAR

If we type bash to spawn a child shell, and then try to access the contents of the variable, nothing will be returned. This is what we expected.

Get back to our original shell by typing exit :

exit

Creating Environmental Variables

---

Now, let's turn our shell variable into an environmental variable. We can do this by exporting the variable. The command to do so is appropriately named:

export TEST_VAR

This will change our variable into an environmental variable. We can check this by checking our environmental listing again:

printenv | grep TEST_VAR

---

TEST_VAR=Hello World!

This time, our variable shows up. Let's try our experiment with our child shell again:

bash
echo $TEST_VAR

---

Hello World!

Great! Our child shell has received the variable set by its parent. Before we exit this child shell, let's try to export another variable. We can set environmental variables in a single step like this:

export NEW_VAR="Testing export"

Test that it's exported as an environmental variable:

printenv | grep NEW_VAR

---

NEW_VAR=Testing export

Now, let's exit back into our original shell:

exit

Let's see if our new variable is available:

echo $NEW_VAR

Nothing is returned.

This is because environmental variables are only passed to child processes. There isn't a built-in way of setting environmental variables of the parent shell. This is good in most cases and prevents programs from affecting the operating environment from which they were called.

The NEW_VAR variable was set as an environmental variable in our child shell. This variable would be available to itself and any of its child shells and processes. When we exited back into our main shell, that environment was destroyed.

Demoting and Unsetting Variables

---

We still have our TEST_VAR variable defined as an environmental variable. We can change it back into a shell variable by typing:

export -n TEST_VAR

It is no longer an environmental variable:

printenv | grep TEST_VAR

However, it is still a shell variable:

set | grep TEST_VAR

---

TEST_VAR='Hello World!'

If we want to completely unset a variable, either shell or environmental, we can do so with the unset command:

unset TEST_VAR

We can verify that it is no longer set:

echo $TEST_VAR

Nothing is returned because the variable has been unset.

Setting Environmental Variables at Login

---

We've already mentioned that many programs use environmental variables to decide the specifics of how to operate. We do not want to have to set important variables up every time we start a new shell session, and we have already seen how many variables are already set upon login, so how do we make and define variables automatically?

This is actually a more complex problem than it initially seems, due to the numerous configuration files that the bash shell reads depending on how it is started.

The Difference between Login, Non-Login, Interactive, and Non-Interactive Shell Sessions

---

The bash shell reads different configuration files depending on how the session is started.

One distinction between different sessions is whether the shell is being spawned as a "login" or "non-login" session.

A login shell is a shell session that begins by authenticating the user. If you are signing into a terminal session or through SSH and authenticate, your shell session will be set as a "login" shell.

If you start a new shell session from within your authenticated session, like we did by calling the bash command from the terminal, a non-login shell session is started. You were were not asked for your authentication details when you started your child shell.

Another distinction that can be made is whether a shell session is interactive, or non-interactive.

An interactive shell session is a shell session that is attached to a terminal. A non-interactive shell session is one is not attached to a terminal session.

So each shell session is classified as either login or non-login and interactive or non-interactive.

A normal session that begins with SSH is usually an interactive login shell. A script run from the command line is usually run in a non-interactive, non-login shell. A terminal session can be any combination of these two properties.

Whether a shell session is classified as a login or non-login shell has implications on which files are read to initialize the shell session.

A session started as a login session will read configuration details from the /etc/profile file first. It will then look for the first login shell configuration file in the user's home directory to get user-specific configuration details.

It reads the first file that it can find out of ~/.bash_profile , ~/.bash_login , and ~/.profile and does not read any further files.

In contrast, a session defined as a non-login shell will read /etc/bash.bashrc and then the user-specific ~/.bashrc file to build its environment.

Non-interactive shells read the environmental variable called BASH_ENV and read the file specified to define the new environment.

Implementing Environmental Variables

---

As you can see, there are a variety of different files that we would usually need to look at for placing our settings.

This provides a lot of flexibility that can help in specific situations where we want certain settings in a login shell, and other settings in a non-login shell. However, most of the time we will want the same settings in both situations.

Fortunately, most Linux distributions configure the login configuration files to source the non-login configuration files. This means that you can define environmental variables that you want in both inside the non-login configuration files. They will then be read in both scenarios.

We will usually be setting user-specific environmental variables, and we usually will want our settings to be available in both login and non-login shells. This means that the place to define these variables is in the ~/.bashrc file.

Open this file now:

nano ~/.bashrc

This will most likely contain quite a bit of data already. Most of the definitions here are for setting bash options, which are unrelated to environmental variables. You can set environmental variables just like you would from the command line:

export VARNAME=value

We can then save and close the file. The next time you start a shell session, your environmental variable declaration will be read and passed on to the shell environment. You can force your current session to read the file now by typing:

source ~/.bashrc

If you need to set system-wide variables, you may want to think about adding them to /etc/profile , /etc/bash.bashrc , or /etc/environment .

Conclusion

---

Environmental and shell variables are always present in your shell sessions and can be very useful. They are an interesting way for a parent process to set configuration details for its children, and are a way of setting options outside of files.

This has many advantages in specific situations. For instance, some deployment mechanisms rely on environmental variables to configure authentication information. This is useful because it does not require keeping these in files that may be seen by outside parties.

There are plenty of other, more mundane, but more common scenarios where you will need to read or alter the environment of your system. These tools and techniques should give you a good foundation for making these changes and using them correctly.

By Justin Ellingwood

[Jul 29, 2017] shell - Whats the difference between .bashrc, .bash_profile, and .environment - Stack Overflow

Notable quotes:

"... "The following paragraphs describe how bash executes its startup files." ..."

Jul 29, 2017 | stackoverflow.com

up vote 130 down vote favorite 717

Adam Rosenfield , asked Jan 6 '09 at 3:58

I've used a number of different *nix-based systems of the years, and it seems like every flavor of Bash I use has a different algorithm for deciding which startup scripts to run. For the purposes of tasks like setting up environment variables and aliases and printing startup messages (e.g. MOTDs), which startup script is the appropriate place to do these?

What's the difference between putting things in .bashrc , .bash_profile , and .environment ? I've also seen other files such as .login , .bash_login , and .profile ; are these ever relevant? What are the differences in which ones get run when logging in physically, logging in remotely via ssh, and opening a new terminal window? Are there any significant differences across platforms (including Mac OS X (and its Terminal.app) and Cygwin Bash)?

Cos , answered Jan 6 '09 at 4:18

The main difference with shell config files is that some are only read by "login" shells (eg. when you login from another host, or login at the text console of a local unix machine). these are the ones called, say, .login or .profile or .zlogin (depending on which shell you're using).

Then you have config files that are read by "interactive" shells (as in, ones connected to a terminal (or pseudo-terminal in the case of, say, a terminal emulator running under a windowing system). these are the ones with names like .bashrc , .tcshrc , .zshrc , etc.

bash complicates this in that .bashrc is only read by a shell that's both interactive and non-login , so you'll find most people end up telling their .bash_profile to also read .bashrc with something like

[[ -r ~/.bashrc ]] && . ~/.bashrc

Other shells behave differently - eg with zsh , .zshrc is always read for an interactive shell, whether it's a login one or not.

The manual page for bash explains the circumstances under which each file is read. Yes, behaviour is generally consistent between machines.

.profile is simply the login script filename originally used by /bin/sh . bash , being generally backwards-compatible with /bin/sh , will read .profile if one exists.

Johannes Schaub - litb , answered Jan 6 '09 at 15:21

That's simple. It's explained in man bash :

... ... ... 

Login shells are the ones that are the one you login (so, they are not executed when merely starting up xterm, for example). There are other ways to login. For example using an X display manager. Those have other ways to read and export environment variables at login time.

Also read the INVOCATION chapter in the manual. It says "The following paragraphs describe how bash executes its startup files." , i think that's a spot-on :) It explains what an "interactive" shell is too.

Bash does not know about .environment . I suspect that's a file of your distribution, to set environment variables independent of the shell that you drive.

Jonathan Leffler , answered Jan 6 '09 at 4:13

Classically, ~/.profile is used by Bourne Shell, and is probably supported by Bash as a legacy measure. Again, ~/.login and ~/.cshrc were used by C Shell - I'm not sure that Bash uses them at all.

The ~/.bash_profile would be used once, at login. The ~/.bashrc script is read every time a shell is started. This is analogous to /.cshrc for C Shell.

One consequence is that stuff in ~/.bashrc should be as lightweight (minimal) as possible to reduce the overhead when starting a non-login shell.

I believe the ~/.environment file is a compatibility file for Korn Shell.

Filip Ekberg , answered Jan 6 '09 at 4:03

I found information about .bashrc and .bash_profile here to sum it up:

.bash_profile is executed when you login. Stuff you put in there might be your PATH and other important environment variables.

.bashrc is used for non login shells. I'm not sure what that means. I know that RedHat executes it everytime you start another shell (su to this user or simply calling bash again) You might want to put aliases in there but again I am not sure what that means. I simply ignore it myself.

.profile is the equivalent of .bash_profile for the root. I think the name is changed to let other shells (csh, sh, tcsh) use it as well. (you don't need one as a user)

There is also .bash_logout wich executes at, yeah good guess...logout. You might want to stop deamons or even make a little housekeeping . You can also add "clear" there if you want to clear the screen when you log out.

Also there is a complete follow up on each of the configurations files here

These are probably even distro.-dependant, not all distros choose to have each configuraton with them and some have even more. But when they have the same name, they usualy include the same content.

Rose Perrone , answered Feb 27 '12 at 0:22

According to Josh Staiger , Mac OS X's Terminal.app actually runs a login shell rather than a non-login shell by default for each new terminal window, calling .bash_profile instead of .bashrc.

He recommends:

Most of the time you don't want to maintain two separate config files for login and non-login shells ! when you set a PATH, you want it to apply to both. You can fix this by sourcing .bashrc from your .bash_profile file, then putting PATH and common settings in .bashrc.

To do this, add the following lines to .bash_profile:

if ~/.bashrc ]; then 
    source ~/.bashrc
fi

Now when you login to your machine from a console .bashrc will be called.

PolyThinker , answered Jan 6 '09 at 4:06

A good place to look at is the man page of bash. Here 's an online version. Look for "INVOCATION" section.

seismick , answered May 21 '12 at 10:42

I have used Debian-family distros which appear to execute .profile , but not .bash_profile , whereas RHEL derivatives execute .bash_profile before .profile .

It seems to be a mess when you have to set up environment variables to work in any Linux OS.

[Jul 28, 2017] bash - About .bash_profile, .bashrc, and where should alias be written in - Stack Overflow

Jul 28, 2017 | stackoverflow.com

Community May 23 at 12:17 ♦

Possible Duplicate: What's the difference between .bashrc, .bash_profile, and .environment?

It seems that if I use

alias ls
'ls -F'

inside of .bashrc on Mac OS X, then the newly created shell will not have that alias. I need to type bash again and that alias will be in effect.

And if I log into Linux on the hosting company, the .bashrc file has a comment line that says:

For non-login shell

and the .bash_profile file has a comment that says

for login shell

So where should aliases be written in? How come we separate the login shell and non-login shell?

Some webpage say use .bash_aliases , but it doesn't work on Mac OS X, it seems.

Maggyero edited Apr 25 '16 at 16:24

The reason you separate the login and non-login shell is because the .bashrc file is reloaded every time you start a new copy of Bash.

The .profile file is loaded only when you either log in or use the appropriate flag to tell Bash to act as a login shell.

Personally,

• I put my PATH setup into a .profile file (because I sometimes use other shells);
• I put my Bash aliases and functions into my .bashrc file;
• I put this

  
  #!/bin/bash
  # CRM .bash_profile Time-stamp: "2008-12-07 19:42"
  # echo "Loading ${HOME}/.bash_profile"
  
  source
  ~/.
  profile
  # get my PATH setup
  
  source
  ~/.
  bashrc
  # get my Bash aliases
  
  

  in my .bash_profile file.

Oh, and the reason you need to type bash again to get the new alias is that Bash loads your .bashrc file when it starts but it doesn't reload it unless you tell it to. You can reload the .bashrc file (and not need a second shell) by typing

source
~/.
bashrc

which loads the .bashrc file as if you had typed the commands directly to Bash.

lhunath answered May 24 '09 at 6:22

Check out http://mywiki.wooledge.org/DotFiles for an excellent resource on the topic aside from man bash .

Summary:

• You only log in once, and that's when ~/.bash_profile or ~/.profile is read and executed. Since everything you run from your login shell inherits the login shell's environment, you should put all your environment variables in there. Like LESS , PATH , MANPATH , LC_* , ... For an example, see: My .profile
  
• Once you log in, you can run several more shells. Imagine logging in, running X, and in X starting a few terminals with bash shells. That means your login shell started X, which inherited your login shell's environment variables, which started your terminals, which started your non-login bash shells. Your environment variables were passed along in the whole chain, so your non-login shells don't need to load them anymore. Non-login shells only execute ~/.bashrc , not /.profile or ~/.bash_profile , for this exact reason, so in there define everything that only applies to bash . That's functions, aliases, bash-only variables like HISTSIZE (this is not an environment variable, don't export it!) , shell options with set and shopt , etc. For an example, see: My .bashrc
  
• Now, as part of UNIX peculiarity, a login-shell does NOT execute ~/.bashrc but only ~/.profile or ~/.bash_profile , so you should source that one manually from the latter. You'll see me do that in my ~/.profile too: source ~/.bashrc .

Adam Rosenfield May 24 '09 at 2:46

From the bash manpage:

When bash is invoked as an interactive login shell, or as a non-interactive shell with the --login option, it first reads and executes commands from the file /etc/profile , if that file exists. After reading that file, it looks for ~/.bash_profile , ~/.bash_login , and ~/.profile , in that order, and reads and executes commands from the first one that exists and is readable. The --noprofile option may be used when the shell is started to inhibit this behavior.

When a login shell exits, bash reads and executes commands from the file ~/.bash_logout , if it exists.

When an interactive shell that is not a login shell is started, bash reads and executes commands from ~/.bashrc , if that file exists. This may be inhibited by using the --norc option. The --rcfile file option will force bash to read and execute commands from file instead of ~/.bashrc .

Thus, if you want to get the same behavior for both login shells and interactive non-login shells, you should put all of your commands in either .bashrc or .bash_profile , and then have the other file source the first one.

Adam Rosenfield May 24 '09 at 2:46

.bash_profile is loaded for a "login shell". I am not sure what that would be on OS X, but on Linux that is either X11 or a virtual terminal.

.bashrc is loaded every time you run Bash. That is where you should put stuff you want loaded whenever you open a new Terminal.app window.

I personally put everything in .bashrc so that I don't have to restart the application for changes to take effect.

jonty /.bashrc

Commands vi and man will launch in separate screens when called inside GNU screen. You need my scr file as well.

# $HOME/.bashrc - Jonty's own settings for all shells, not just login
# Jonty 28-Aug-2005

# Shorthands to launch 'vi' or 'man' in separate screens
# when we are running in 'screen'.

function vi() { scr vi $* ; }

function man() { scr man $* ; }

cron0 /.bashrc

An interesting idea of truncating maximum length of current path in prompt, which is viatl if you are wqorking with deeply nested directories. Implementation could be better.

cron0 /.bashrc 

#.bashrc
export PAGER=less
export EDITOR=vim
export PATH=$HOME/bin:/usr/local/bin:/usr/local/mysql/bin:/opt/local/bin:$PATH
export LESS='-R'

if [[ $- != *i* ]] ; then
         # Shell is non-interactive.  Be done now!
         return
fi


# Fancy PWD display function
# The home directory (HOME) is replaced with a ~
# /home/me/stuff          -> ~/stuff               if USER=me
# /usr/share/big_dir_name -> ../share/big_dir_name if pwdmaxlen=20
bash_prompt_command() {
    # How many characters of the $PWD should be kept
    local pwdmaxlen=15
    # Indicate that there has been dir truncation
    local trunc_symbol=".."
    local dir=${PWD##*/}
    pwdmaxlen=$(( ( pwdmaxlen < ${#dir} ) ? ${#dir} : pwdmaxlen ))
    NEW_PWD=${PWD/#$HOME/\~}
    local pwdoffset=$(( ${#NEW_PWD} - pwdmaxlen ))
    if [ ${pwdoffset} -gt "0" ]
    then
        NEW_PWD=${NEW_PWD:$pwdoffset:$pwdmaxlen}
        NEW_PWD=${trunc_symbol}/${NEW_PWD#*/}
    fi
}

bash_prompt() {
        case $TERM in
    xterm*|rxvt*)
        local TITLEBAR='\[\033]0;\u:${NEW_PWD}\007\]'
        ;;
    *)
        local TITLEBAR=""
        ;;
        esac
        
    local NONE="\[\033[0m\]"    # unsets color to term's fg color
    
    # regular colors
    local K="\[\033[0;30m\]"    # black
    local R="\[\033[0;31m\]"    # red
    local G="\[\033[0;32m\]"    # green
    local Y="\[\033[0;33m\]"    # yellow
    local B="\[\033[0;34m\]"    # blue
    local M="\[\033[0;35m\]"    # magenta
    local C="\[\033[0;36m\]"    # cyan
    local W="\[\033[0;37m\]"    # white
    
    # empahsized (bolded) colors
    local EMK="\[\033[1;30m\]"
    local EMR="\[\033[1;31m\]"
    local EMG="\[\033[1;32m\]"
    local EMY="\[\033[1;33m\]"
    local EMB="\[\033[1;34m\]"
    local EMM="\[\033[1;35m\]"
    local EMC="\[\033[1;36m\]"
    local EMW="\[\033[1;37m\]"
    
    # background colors
    local BGK="\[\033[40m\]"
    local BGR="\[\033[41m\]"
    local BGG="\[\033[42m\]"
    local BGY="\[\033[43m\]"
    local BGB="\[\033[44m\]"
    local BGM="\[\033[45m\]"
    local BGC="\[\033[46m\]"
    local BGW="\[\033[47m\]"
    
    local UC=$W                 # user's color
    [ $UID -eq "0" ] && UC=$R   # root's color
    
    PS1="$TITLEBAR${EMK}[${UC}\u${EMK}@${UC}\h ${EMB}\${NEW_PWD}${EMK}]${UC}\\$ ${NONE}"

}
PROMPT_COMMAND=bash_prompt_command
bash_prompt
unset bash_prompt

### Bash stuff
export HISTCONTROL=ignoredups
export HISTSIZE=1000
export HISTFILESIZE=1000

### Bash options
#fix spelling
shopt -s cdspell
#makes bash append to history rather than overwrite
shopt -s histappend
#make bash check window after each command
shopt -s checkwinsize

### Misc
# disable XON/XOFF flow control (^s/^q) 
stty -ixon

# Tab complete for sudo
complete -cf sudo

#prevent overwriting files with cat
set -o noclobber

#stops ctrl+d from logging me out
#set -o ignoreeof

#Treat undefined variables as errors
set -o nounset

### Aliases
#safety! ohnoes.
alias rm='rm -i'
alias cp='cp -i'
alias mv='mv -i'
alias mkdir='mkdir -p'
#colors
#alias ls='ls --color'
#alias ls='ls -hp --time-style=locale --color' 
alias ls='ls -G'
alias grep='grep --color=auto'
#alias ncmpc='ncmpc -c'
#unicode
#alias xterm='xterm -u8'
#alias screen='screen -U'
#sudo
#alias root='sudo su'
#alias pacman='sudo pacman'
#alias apt-get='sudo apt-get'
#alias aptitude='sudo aptitude'
#
alias cd..='cd ..'
alias more='less'
alias nano='nano -w'
alias vim='vim -X'
#alias xcomp='xcompmgr -cCfF -r7 -o.65 -l-10 -t-8 -D7'
alias servethis="python -c 'import SimpleHTTPServer; SimpleHTTPServer.test()'"
alias m='mate'
alias ss='./script/server'

###Console
#makes console terminal pretty
#slightly modified phraktured's
if [ "$TERM" = "linux" ]; then
    echo -en "\e]P0121212" #black
    echo -en "\e]P8474747" #darkgrey
    echo -en "\e]P1803232" #darkred
    echo -en "\e]P9982b2b" #red
    echo -en "\e]P25b762f" #darkgreen
    echo -en "\e]PA89b83f" #green
    echo -en "\e]P3AA9943" #dark yellow
    echo -en "\e]PBefef60" #yellow
    echo -en "\e]P4324c80" #darkblue
    echo -en "\e]PC2b4f98" #blue
    echo -en "\e]P55F5A90" #darkmagenta
    echo -en "\e]PD826ab1" #magenta
    echo -en "\e]P692b19e" #darkcyan
    echo -en "\e]PEa1cdcd" #cyan
    echo -en "\e]P7ffffff" #lightgrey
    echo -en "\e]PFdedede" #white
    clear #for background artifacting
fi


#more colors!
if [ -f ~/.dir_colors ]; then
            eval `dircolors ~/.dir_colors`
fi 
export EDITOR="/usr/bin/mate -w"

brogers /.bashrc

Some sources of addit0oona inspiration: LifehackerTerminalTweaks

http://dotfiles.org/~brogers/.bashrc

complete -C ~/bin/rake_tab_completion -o default rake
complete -C ~/bin/sake_tab_completion -o default sake

export RUBYOPT=rubygems

if [ -f ~/.LifehackerTerminalTweaks ]; then
  source ~/.LifehackerTerminalTweaks
fi

An interesting example of .bashrc with the ability to extract files from archive on the base of imitation of a part of Norton Commander functionality ;-)

http://dotfiles.org/~joephantom/.bashrc

joephantom /.bashrc 

extract () {
    if [ -f $1 ] ; then
        case $1 in
            *.tar.bz2)  tar xjf $1      ;;
            *.tar.gz)   tar xzf $1      ;;
            *.bz2)      bunzip2 $1      ;;
            *.rar)      unrar x $1      ;;
            *.gz)       gunzip $1       ;;
            *.tar)      tar xf $1       ;;
            *.tbz2)     tar xjf $1      ;;
            *.tgz)      tar xzf $1      ;;
            *.zip)      unzip $1        ;;
            *.Z)        uncompress $1   ;;
            *)          echo "'$1' cannot be extracted via extract()" ;;
        esac
    else
        echo "'$1' is not a valid file"
    fi
}
 
#
rmspaces() {
    ls | while read -r FILE
        do
        mv -v "$FILE" `echo $FILE | tr ' ' '_' | tr -d '[{}(),\!]' | tr -d "\'" | tr '[A-Z]' '[a-z]' | sed 's/_-_/_/g'`
        done
}
#
makepasswords() {
    perl <$%&()*^}));
        for (1..10) {
            print join "", map { \$a[rand @a] } (1..rand(3)+10);
            print qq{\n}
        }
EOPERL
}
 
#
alias ls='ls --color=auto'
#
#PS1="\[\e[36;1m\]\u @ \[\e[32;1m\]\H > \[\e[0m\]"
#
PS1='\[\033[0;36m\]\033(0l\033(B\[\033[0m\][\[\033[1;31m\]\u\[\033[0m\]]\[\033[0;36m\]\033(0q\033(B\[\033[0m\][\[\033[1;33m\]@\h\[\033[0m\]]\[\033[0;36m\]\033(0q\033(B\[\033[0m\][\[\033[0;37m\]\T\[\033[0m\]]\[\033[0;36m\]\033(0q\033(B\033(0q\033(B\033(0q\033(B\033(0q\033(B\033(0q\033(B\033(0q\033(B\033(0q\033(B\033(0q\033(B\[\033[0m\][\[\033[1;33m\]\w\[\033[0m\]]\n\[\033[0;36m\]\033(0m\033(B\[\033[0m\]>'
#
complete -cf sudo

alias pacs="pacsearch"

pacsearch () {
       echo -e "$(pacman -Ss $@ | sed \
       -e 's#core/.*#\\033[1;31m&\\033[0;37m#g' \
       -e 's#extra/.*#\\033[0;32m&\\033[0;37m#g' \
       -e 's#community/.*#\\033[1;35m&\\033[0;37m#g' \
       -e 's#^.*/.* [0-9].*#\\033[0;36m&\\033[0;37m#g' )"

A Sample .bashrc File

tldp.org

The ~/.bashrc file determines the behavior of interactive shells. A good look at this file can lead to a better understanding of Bash.

Emmanuel Rouat contributed the following very elaborate .bashrc file, written for a Linux system. He welcomes reader feedback on it.

Study the file carefully, and feel free to reuse code snippets and functions from it in your own .bashrc file or even in your scripts.

Example L-1. Sample .bashrc file

#============================================================= # # PERSONAL $HOME/.bashrc FILE for bash-3.0 (or later) # By Emmanuel Rouat <no-email> # # Last modified: Sun Nov 30 16:27:45 CET 2008 # This file is read (normally) by interactive shells only. # Here is the place to define your aliases, functions and # other interactive features like your prompt. # # The majority of the code here assumes you are on a GNU # system (most likely a Linux box) and is based on code found # on Usenet or internet. See for instance: # # http://tldp.org/LDP/abs/html/index.html # http://www.caliban.org/bash/ # http://www.shelldorado.com/scripts/categories.html # http://www.dotfiles.org/ # # This bashrc file is a bit overcrowded -- remember it is just # just an example. Tailor it to your needs. # # #============================================================= # --> Comments added by HOWTO author. #------------------------------------------------------------- # Source global definitions (if any) #------------------------------------------------------------- if [ -f /etc/bashrc ]; then . /etc/bashrc # --> Read /etc/bashrc, if present. fi #------------------------------------------------------------- # Automatic setting of $DISPLAY (if not set already). # This works for linux - your mileage may vary. ... # The problem is that different types of terminals give # different answers to 'who am i' (rxvt in particular can be # troublesome). # I have not found a 'universal' method yet. #------------------------------------------------------------- function get_xserver () { case $TERM in xterm ) XSERVER=$(who am i | awk '{print $NF}' | tr -d ')''(' ) # Ane-Pieter Wieringa suggests the following alternative: # I_AM=$(who am i) # SERVER=${I_AM#*(} # SERVER=${SERVER%*)} XSERVER=${XSERVER%%:*} ;; aterm | rxvt) # Find some code that works here. ... ;; esac } if [ -z ${DISPLAY:=""} ]; then get_xserver if [[ -z ${XSERVER} || ${XSERVER} == $(hostname) || \ ${XSERVER} == "unix" ]]; then DISPLAY=":0.0" # Display on local host. else DISPLAY=${XSERVER}:0.0 # Display on remote host. fi fi export DISPLAY #------------------------------------------------------------- # Some settings #------------------------------------------------------------- ulimit -S -c 0 # Don't want any coredumps. set -o notify set -o noclobber set -o ignoreeof set -o nounset #set -o xtrace # Useful for debuging. # Enable options: shopt -s cdspell shopt -s cdable_vars shopt -s checkhash shopt -s checkwinsize shopt -s sourcepath shopt -s no_empty_cmd_completion shopt -s cmdhist shopt -s histappend histreedit histverify shopt -s extglob # Necessary for programmable completion. # Disable options: shopt -u mailwarn unset MAILCHECK # Don't want my shell to warn me of incoming mail. export TIMEFORMAT=$'\nreal %3R\tuser %3U\tsys %3S\tpcpu %P\n' export HISTTIMEFORMAT="%H:%M > " export HISTIGNORE="&:bg:fg:ll:h" export HOSTFILE=$HOME/.hosts # Put list of remote hosts in ~/.hosts ... #------------------------------------------------------------- # Greeting, motd etc... #------------------------------------------------------------- # Define some colors first: red='\e[0;31m' RED='\e[1;31m' blue='\e[0;34m' BLUE='\e[1;34m' cyan='\e[0;36m' CYAN='\e[1;36m' NC='\e[0m' # No Color # --> Nice. Has the same effect as using "ansi.sys" in DOS. # Looks best on a terminal with black background..... echo -e "${CYAN}This is BASH ${RED}${BASH_VERSION%.*}\ ${CYAN} - DISPLAY on ${RED}$DISPLAY${NC}\n" date if [ -x /usr/games/fortune ]; then /usr/games/fortune -s # Makes our day a bit more fun.... :-) fi function _exit() # Function to run upon exit of shell. { echo -e "${RED}Hasta la vista, baby${NC}" } trap _exit EXIT #------------------------------------------------------------- # Shell Prompt #------------------------------------------------------------- if [[ "${DISPLAY%%:0*}" != "" ]]; then HILIT=${red} # remote machine: prompt will be partly red else HILIT=${cyan} # local machine: prompt will be partly cyan fi # --> Replace instances of \W with \w in prompt functions below #+ --> to get display of full path name. function fastprompt() { unset PROMPT_COMMAND case $TERM in *term | rxvt ) PS1="${HILIT}[\h]$NC \W > \[\033]0;\${TERM} [\u@\h] \w\007\]" ;; linux ) PS1="${HILIT}[\h]$NC \W > " ;; *) PS1="[\h] \W > " ;; esac } _powerprompt() { LOAD=$(uptime|sed -e "s/.*: \([^,]*\).*/\1/" -e "s/ //g") } function powerprompt() { PROMPT_COMMAND=_powerprompt case $TERM in *term | rxvt ) PS1="${HILIT}[\A - \$LOAD]$NC\n[\u@\h \#] \W > \ \[\033]0;\${TERM} [\u@\h] \w\007\]" ;; linux ) PS1="${HILIT}[\A - \$LOAD]$NC\n[\u@\h \#] \W > " ;; * ) PS1="[\A - \$LOAD]\n[\u@\h \#] \W > " ;; esac } powerprompt # This is the default prompt -- might be slow. # If too slow, use fastprompt instead. ... #=============================================================== # # ALIASES AND FUNCTIONS # # Arguably, some functions defined here are quite big. # If you want to make this file smaller, these functions can # be converted into scripts and removed from here. # # Many functions were taken (almost) straight from the bash-2.04 # examples. # #=============================================================== #------------------- # Personnal Aliases #------------------- alias rm='rm -i' alias cp='cp -i' alias mv='mv -i' # -> Prevents accidentally clobbering files. alias mkdir='mkdir -p' alias h='history' alias j='jobs -l' alias which='type -a' alias ..='cd ..' alias path='echo -e ${PATH//:/\\n}' alias libpath='echo -e ${LD_LIBRARY_PATH//:/\\n}' alias print='/usr/bin/lp -o nobanner -d $LPDEST' # Assumes LPDEST is defined (default printer) alias pjet='enscript -h -G -fCourier9 -d $LPDEST' # Pretty-print using enscript alias du='du -kh' # Makes a more readable output. alias df='df -kTh' #------------------------------------------------------------- # The 'ls' family (this assumes you use a recent GNU ls) #------------------------------------------------------------- alias ll="ls -l --group-directories-first" alias ls='ls -hF --color' # add colors for filetype recognition alias la='ls -Al' # show hidden files alias lx='ls -lXB' # sort by extension alias lk='ls -lSr' # sort by size, biggest last alias lc='ls -ltcr' # sort by and show change time, most recent last alias lu='ls -ltur' # sort by and show access time, most recent last alias lt='ls -ltr' # sort by date, most recent last alias lm='ls -al |more' # pipe through 'more' alias lr='ls -lR' # recursive ls alias tree='tree -Csu' # nice alternative to 'recursive ls' # If your version of 'ls' doesn't support --group-directories-first try this: # function ll(){ ls -l "$@"| egrep "^d" ; ls -lXB "$@" 2>&-| \ # egrep -v "^d|total "; } #------------------------------------------------------------- # tailoring 'less' #------------------------------------------------------------- alias more='less' export PAGER=less export LESSCHARSET='latin1' export LESSOPEN='|/usr/bin/lesspipe.sh %s 2>&-' # Use this if lesspipe.sh exists export LESS='-i -N -w -z-4 -g -e -M -X -F -R -P%t?f%f \ :stdin .?pb%pb\%:?lbLine %lb:?bbByte %bb:-...' #------------------------------------------------------------- # spelling typos - highly personnal and keyboard-dependent :-) #------------------------------------------------------------- alias xs='cd' alias vf='cd' alias moer='more' alias moew='more' alias kk='ll' #------------------------------------------------------------- # A few fun ones #------------------------------------------------------------- function xtitle() # Adds some text in the terminal frame. { case "$TERM" in *term | rxvt) echo -n -e "\033]0;$*\007" ;; *) ;; esac } # aliases that use xtitle alias top='xtitle Processes on $HOST && top' alias make='xtitle Making $(basename $PWD) ; make' alias ncftp="xtitle ncFTP ; ncftp" # .. and functions function man() { for i ; do xtitle The $(basename $1|tr -d .[:digit:]) manual command man -F -a "$i" done } #------------------------------------------------------------- # Make the following commands run in background automatically: #------------------------------------------------------------- function te() # Wrapper around xemacs/gnuserv ... { if [ "$(gnuclient -batch -eval t 2>&-)" == "t" ]; then gnuclient -q "$@"; else ( xemacs "$@" &); fi } function soffice() { command soffice "$@" & } function firefox() { command firefox "$@" & } function xpdf() { command xpdf "$@" & } #------------------------------------------------------------- # File & string-related functions: #------------------------------------------------------------- # Find a file with a pattern in name: function ff() { find . -type f -iname '*'$*'*' -ls ; } # Find a file with pattern $1 in name and Execute $2 on it: function fe() { find . -type f -iname '*'${1:-}'*' -exec ${2:-file} {} \; ; } # Find a pattern in a set of files and highlight them: # (needs a recent version of egrep) function fstr() { OPTIND=1 local case="" local usage="fstr: find string in files. Usage: fstr [-i] \"pattern\" [\"filename pattern\"] " while getopts :it opt do case "$opt" in i) case="-i " ;; *) echo "$usage"; return;; esac done shift $(( $OPTIND - 1 )) if [ "$#" -lt 1 ]; then echo "$usage" return; fi find . -type f -name "${2:-*}" -print0 | \ xargs -0 egrep --color=always -sn ${case} "$1" 2>&- | more } function cuttail() # cut last n lines in file, 10 by default { nlines=${2:-10} sed -n -e :a -e "1,${nlines}!{P;N;D;};N;ba" $1 } function lowercase() # move filenames to lowercase { for file ; do filename=${file##*/} case "$filename" in */*) dirname==${file%/*} ;; *) dirname=.;; esac nf=$(echo $filename | tr A-Z a-z) newname="${dirname}/${nf}" if [ "$nf" != "$filename" ]; then mv "$file" "$newname" echo "lowercase: $file --> $newname" else echo "lowercase: $file not changed." fi done } function swap() # Swap 2 filenames around, if they exist { #(from Uzi's bashrc). local TMPFILE=tmp.$$ [ $# -ne 2 ] && echo "swap: 2 arguments needed" && return 1 [ ! -e $1 ] && echo "swap: $1 does not exist" && return 1 [ ! -e $2 ] && echo "swap: $2 does not exist" && return 1 mv "$1" $TMPFILE mv "$2" "$1" mv $TMPFILE "$2" } function extract() # Handy Extract Program. { if [ -f $1 ] ; then case $1 in *.tar.bz2) tar xvjf $1 ;; *.tar.gz) tar xvzf $1 ;; *.bz2) bunzip2 $1 ;; *.rar) unrar x $1 ;; *.gz) gunzip $1 ;; *.tar) tar xvf $1 ;; *.tbz2) tar xvjf $1 ;; *.tgz) tar xvzf $1 ;; *.zip) unzip $1 ;; *.Z) uncompress $1 ;; *.7z) 7z x $1 ;; *) echo "'$1' cannot be extracted via >extract<" ;; esac else echo "'$1' is not a valid file" fi } #------------------------------------------------------------- # Process/system related functions: #------------------------------------------------------------- function my_ps() { ps $@ -u $USER -o pid,%cpu,%mem,bsdtime,command ; } function pp() { my_ps f | awk '!/awk/ && $0~var' var=${1:-".*"} ; } function killps() # Kill by process name. { local pid pname sig="-TERM" # Default signal. if [ "$#" -lt 1 ] || [ "$#" -gt 2 ]; then echo "Usage: killps [-SIGNAL] pattern" return; fi if [ $# = 2 ]; then sig=$1 ; fi for pid in $(my_ps| awk '!/awk/ && $0~pat { print $1 }' pat=${!#} ) ; do pname=$(my_ps | awk '$1~var { print $5 }' var=$pid ) if ask "Kill process $pid <$pname> with signal $sig?" then kill $sig $pid fi done } function my_ip() # Get IP adresses. { MY_IP=$(/sbin/ifconfig ppp0 | awk '/inet/ { print $2 } ' | \ sed -e s/addr://) MY_ISP=$(/sbin/ifconfig ppp0 | awk '/P-t-P/ { print $3 } ' | \ sed -e s/P-t-P://) } function ii() # Get current host related info. { echo -e "\nYou are logged on ${RED}$HOST" echo -e "\nAdditionnal information:$NC " ; uname -a echo -e "\n${RED}Users logged on:$NC " ; w -h echo -e "\n${RED}Current date :$NC " ; date echo -e "\n${RED}Machine stats :$NC " ; uptime echo -e "\n${RED}Memory stats :$NC " ; free my_ip 2>&- ; echo -e "\n${RED}Local IP Address :$NC" ; echo ${MY_IP:-"Not connected"} echo -e "\n${RED}ISP Address :$NC" ; echo ${MY_ISP:-"Not connected"} echo -e "\n${RED}Open connections :$NC "; netstat -pan --inet; echo } #------------------------------------------------------------- # Misc utilities: #------------------------------------------------------------- function repeat() # Repeat n times command. { local i max max=$1; shift; for ((i=1; i <= max ; i++)); do # --> C-like syntax eval "$@"; done } function ask() # See 'killps' for example of use. { echo -n "$@" '[y/n] ' ; read ans case "$ans" in y*|Y*) return 0 ;; *) return 1 ;; esac } function corename() # Get name of app that created a corefile. { for file ; do echo -n $file : ; gdb --core=$file --batch | head -1 done } #========================================================================= # PROGRAMMABLE COMPLETION - ONLY SINCE BASH-2.04 # Most are taken from the bash 2.05 documentation and from Ian McDonald's # 'Bash completion' package (http://www.caliban.org/bash/#completion). # You will in fact need bash more recent than 3.0 for some features. #========================================================================= if [ "${BASH_VERSION%.*}" \< "3.0" ]; then echo "You will need to upgrade to version 3.0 \ for full programmable completion features." return fi shopt -s extglob # Necessary, #set +o nounset # otherwise some completions will fail. complete -A hostname rsh rcp telnet rlogin r ftp ping disk complete -A export printenv complete -A variable export local readonly unset complete -A enabled builtin complete -A alias alias unalias complete -A function function complete -A user su mail finger complete -A helptopic help # Currently, same as builtins. complete -A shopt shopt complete -A stopped -P '%' bg complete -A job -P '%' fg jobs disown complete -A directory mkdir rmdir complete -A directory -o default cd # Compression complete -f -o default -X '*.+(zip|ZIP)' zip complete -f -o default -X '!*.+(zip|ZIP)' unzip complete -f -o default -X '*.+(z|Z)' compress complete -f -o default -X '!*.+(z|Z)' uncompress complete -f -o default -X '*.+(gz|GZ)' gzip complete -f -o default -X '!*.+(gz|GZ)' gunzip complete -f -o default -X '*.+(bz2|BZ2)' bzip2 complete -f -o default -X '!*.+(bz2|BZ2)' bunzip2 complete -f -o default -X '!*.+(zip|ZIP|z|Z|gz|GZ|bz2|BZ2)' extract # Documents - Postscript,pdf,dvi..... complete -f -o default -X '!*.+(ps|PS)' gs ghostview ps2pdf ps2ascii complete -f -o default -X '!*.+(dvi|DVI)' dvips dvipdf xdvi dviselect dvitype complete -f -o default -X '!*.+(pdf|PDF)' acroread pdf2ps complete -f -o default -X \ '!*.@(@(?(e)ps|?(E)PS|pdf|PDF)?(.gz|.GZ|.bz2|.BZ2|.Z))' gv ggv complete -f -o default -X '!*.texi*' makeinfo texi2dvi texi2html texi2pdf complete -f -o default -X '!*.tex' tex latex slitex complete -f -o default -X '!*.lyx' lyx complete -f -o default -X '!*.+(htm*|HTM*)' lynx html2ps complete -f -o default -X \ '!*.+(doc|DOC|xls|XLS|ppt|PPT|sx?|SX?|csv|CSV|od?|OD?|ott|OTT)' soffice # Multimedia complete -f -o default -X \ '!*.+(gif|GIF|jp*g|JP*G|bmp|BMP|xpm|XPM|png|PNG)' xv gimp ee gqview complete -f -o default -X '!*.+(mp3|MP3)' mpg123 mpg321 complete -f -o default -X '!*.+(ogg|OGG)' ogg123 complete -f -o default -X \ '!*.@(mp[23]|MP[23]|ogg|OGG|wav|WAV|pls|m3u|xm|mod|s[3t]m|it|mtm|ult|flac)' xmms complete -f -o default -X \ '!*.@(mp?(e)g|MP?(E)G|wma|avi|AVI|asf|vob|VOB|bin|dat|vcd|\ ps|pes|fli|viv|rm|ram|yuv|mov|MOV|qt|QT|wmv|mp3|MP3|ogg|OGG|\ ogm|OGM|mp4|MP4|wav|WAV|asx|ASX)' xine complete -f -o default -X '!*.pl' perl perl5 # This is a 'universal' completion function - it works when commands have # a so-called 'long options' mode , ie: 'ls --all' instead of 'ls -a' # Needs the '-o' option of grep # (try the commented-out version if not available). # First, remove '=' from completion word separators # (this will allow completions like 'ls --color=auto' to work correctly). COMP_WORDBREAKS=${COMP_WORDBREAKS/=/} _get_longopts() { #$1 --help | sed -e '/--/!d' -e 's/.*--\([^[:space:].,]*\).*/--\1/'| \ #grep ^"$2" |sort -u ; $1 --help | grep -o -e "--[^[:space:].,]*" | grep -e "$2" |sort -u } _longopts() { local cur cur=${COMP_WORDS[COMP_CWORD]} case "${cur:-*}" in -*) ;; *) return ;; esac case "$1" in \~*) eval cmd="$1" ;; *) cmd="$1" ;; esac COMPREPLY=( $(_get_longopts ${1} ${cur} ) ) } complete -o default -F _longopts configure bash complete -o default -F _longopts wget id info a2ps ls recode _tar() { local cur ext regex tar untar COMPREPLY=() cur=${COMP_WORDS[COMP_CWORD]} # If we want an option, return the possible long options. case "$cur" in -*) COMPREPLY=( $(_get_longopts $1 $cur ) ); return 0;; esac if [ $COMP_CWORD -eq 1 ]; then COMPREPLY=( $( compgen -W 'c t x u r d A' -- $cur ) ) return 0 fi case "${COMP_WORDS[1]}" in ?(-)c*f) COMPREPLY=( $( compgen -f $cur ) ) return 0 ;; +([^Izjy])f) ext='tar' regex=$ext ;; *z*f) ext='tar.gz' regex='t\(ar\.\)\(gz\|Z\)' ;; *[Ijy]*f) ext='t?(ar.)bz?(2)' regex='t\(ar\.\)bz2\?' ;; *) COMPREPLY=( $( compgen -f $cur ) ) return 0 ;; esac if [[ "$COMP_LINE" == tar*.$ext' '* ]]; then # Complete on files in tar file. # # Get name of tar file from command line. tar=$( echo "$COMP_LINE" | \ sed -e 's|^.* \([^ ]*'$regex'\) .*$|\1|' ) # Devise how to untar and list it. untar=t${COMP_WORDS[1]//[^Izjyf]/} COMPREPLY=( $( compgen -W "$( echo $( tar $untar $tar \ 2>/dev/null ) )" -- "$cur" ) ) return 0 else # File completion on relevant files. COMPREPLY=( $( compgen -G $cur\*.$ext ) ) fi return 0 } complete -F _tar -o default tar _make() { local mdef makef makef_dir="." makef_inc gcmd cur prev i; COMPREPLY=(); cur=${COMP_WORDS[COMP_CWORD]}; prev=${COMP_WORDS[COMP_CWORD-1]}; case "$prev" in -*f) COMPREPLY=($(compgen -f $cur )); return 0 ;; esac; case "$cur" in -*) COMPREPLY=($(_get_longopts $1 $cur )); return 0 ;; esac; # make reads `GNUmakefile', then `makefile', then `Makefile' if [ -f ${makef_dir}/GNUmakefile ]; then makef=${makef_dir}/GNUmakefile elif [ -f ${makef_dir}/makefile ]; then makef=${makef_dir}/makefile elif [ -f ${makef_dir}/Makefile ]; then makef=${makef_dir}/Makefile else makef=${makef_dir}/*.mk # Local convention. fi # Before we scan for targets, see if a Makefile name was # specified with -f ... for (( i=0; i < ${#COMP_WORDS[@]}; i++ )); do if [[ ${COMP_WORDS[i]} == -f ]]; then # eval for tilde expansion eval makef=${COMP_WORDS[i+1]} break fi done [ ! -f $makef ] && return 0 # deal with included Makefiles makef_inc=$( grep -E '^-?include' $makef | \ sed -e "s,^.* ,"$makef_dir"/," ) for file in $makef_inc; do [ -f $file ] && makef="$makef $file" done # If we have a partial word to complete, restrict completions to # matches of that word. if [ -n "$cur" ]; then gcmd='grep "^$cur"' ; else gcmd=cat ; fi COMPREPLY=( $( awk -F':' '/^[a-zA-Z0-9][^$#\/\t=]*:([^=]|$)/ \ {split($1,A,/ /);for(i in A)print A[i]}' \ $makef 2>/dev/null | eval $gcmd )) } complete -F _make -X '+($*|*.[cho])' make gmake pmake _killall() { local cur prev COMPREPLY=() cur=${COMP_WORDS[COMP_CWORD]} # get a list of processes (the first sed evaluation # takes care of swapped out processes, the second # takes care of getting the basename of the process) COMPREPLY=( $( /usr/bin/ps -u $USER -o comm | \ sed -e '1,1d' -e 's#[]\[]##g' -e 's#^.*/##'| \ awk '{if ($0 ~ /^'$cur'/) print $0}' )) return 0 } complete -F _killall killall killps # A meta-command completion function for commands like sudo(8), which need to # first complete on a command, then complete according to that command's own # completion definition - currently not quite foolproof, # but still quite useful (By Ian McDonald, modified by me). _meta_comp() { local cur func cline cspec COMPREPLY=() cur=${COMP_WORDS[COMP_CWORD]} cmdline=${COMP_WORDS[@]} if [ $COMP_CWORD = 1 ]; then COMPREPLY=( $( compgen -c $cur ) ) else cmd=${COMP_WORDS[1]} # Find command. cspec=$( complete -p ${cmd} ) # Find spec of that command. # COMP_CWORD and COMP_WORDS() are not read-only, # so we can set them before handing off to regular # completion routine: # Get current command line minus initial command, cline="${COMP_LINE#$1 }" # split current command line tokens into array, COMP_WORDS=( $cline ) # set current token number to 1 less than now. COMP_CWORD=$(( $COMP_CWORD - 1 )) # If current arg is empty, add it to COMP_WORDS array # (otherwise that information will be lost). if [ -z $cur ]; then COMP_WORDS[COMP_CWORD]="" ; fi if [ "${cspec%%-F *}" != "${cspec}" ]; then # if -F then get function: func=${cspec#*-F } func=${func%% *} eval $func $cline # Evaluate it. else func=$( echo $cspec | sed -e 's/^complete//' -e 's/[^ ]*$//' ) COMPREPLY=( $( eval compgen $func $cur ) ) fi fi } complete -o default -F _meta_comp nohup \ eval exec trace truss strace sotruss gdb complete -o default -F _meta_comp command type which man nice time # Local Variables: # mode:shell-script # sh-shell:bash # End:

[Dec 9, 2007] Cool Solutions Bash - Making use of your .bashrc file

Too big but some ideas probably can be borrowed...

Details

I was playing with my .bashrc file again, and was once again impressed by how you can tweak Linux to do what YOU want it to do so easily. I am sure there are tons of other tweaks you can do to your .bashrc file, but I really like some of mine, and thought I would share them. Some of the alias's I created, some I found on the net, and some things in my .bashrc file are just there for fun, like the "# WELCOME SCREEN", although it does serve a purpose for me at the same time, it might not be something everyone would want or need.

For those that don't know what a .bashrc file does: "The ~/.bashrc file determines the behavior of interactive shells." Quoted From: The Advanced Bash Scripting Guide 

Basically , it allows you to create shortcuts (alias's) and interactive programs (functions) that run on the startup of the bash shell or that are used when running an interactive shell. For example, it's much easier to just type: ebrc instead of pico ~/.bashrc (I used the alias ebrc , and it stands for "Edit Bash RC file". I could have also aliased it to just use one letter, making it a VERY fast short cut. The bashrc file allows you to create alias's (shortcuts) to almost anything you want. My list is pretty long, but I'm sure there is someone with a longer list ;)

I have my .bashrc file setup in sections. The following is the breakdown by section of how I keep my list of alias's and functions separated. This is just how I do this, your .bashrc file can be modified to suit YOUR needs, that's the interesting part about the .bashrc file. It's VERY customizable and very easy to change.

Header (So I know when i modified it last and what i was running it on)
Exports (So I can set history size, paths , editors, define colors, etc,)
Sourced Alias's (So I can find those hidden alias's faster)
Workstation Alias's (so i can ssh to local machines quickly)
Remote Server Alias's (so i can ssh to remote servers easily)
Script Alias's (quick links to some of my bashscripts)
Hardware control alias's (so I can control cd/dvd/scanners/audio/etc)
Modified commands (Alias's to normal linux commands with special flags)
Chmod Alias's (makes changing permissions faster)
Alias's for GUI programs (start firefox, etc from command line)
Alias's for xterm and others (open xterm with special settings)
Alias's for Lynx (open lynx with urls - kind of a bash bookmark ;) )
UNused Alias's (Alias's that aren't in use on the system, but that i might use later)
Special functions (more of a function than just an alias..it goes here)
Notes (that should be self explanatory ;) )
Welcome Screen (code to make my bash shell display some stuff as it starts up)

That's how I lay out my .bashrc files. It may not be perfect, but it works well for me. I like making changes in just my .bashrc file and not the global files. I like the .bashrc file because you don't need root permissions to make changes that make your life easier at the bash shell.

The following is my .bashrc file (with some things obviously commented out for security... but most of it should be self explanatory). Anyone with comments/suggestions/ideas feel free to let me know. I'm always looking for new and interesting things to do with the .bashrc file.

Want to know what alias's your bash shell has? Simply type the word alias at the command line. The shell will then print out the list of active alias's to the standard output (normally your screen).

#######################################################
# Dave Crouse's .bashrc file
# www.bashscripts.org
# www.usalug.org
#
# Last Modified 04-08-2006
# Running on OpenSUSE 10
#######################################################


# EXPORTS
#######################################################

PATH=$PATH:/usr/lib/festival/ ;export PATH
export PS1="[\[\033[1;34m\w\[\033[0m]\n[\t \u]$ "
export EDITOR=/usr/bin/pico
export HISTFILESIZE=3000 # the bash history should save 3000 commands
export HISTCONTROL=ignoredups #don't put duplicate lines in the history.
alias hist='history | grep $1' #Requires one input

# Define a few Color's
BLACK='\e[0;30m'
BLUE='\e[0;34m'
GREEN='\e[0;32m'
CYAN='\e[0;36m'
RED='\e[0;31m'
PURPLE='\e[0;35m'
BROWN='\e[0;33m'
LIGHTGRAY='\e[0;37m'
DARKGRAY='\e[1;30m'
LIGHTBLUE='\e[1;34m'
LIGHTGREEN='\e[1;32m'
LIGHTCYAN='\e[1;36m'
LIGHTRED='\e[1;31m'
LIGHTPURPLE='\e[1;35m'
YELLOW='\e[1;33m'
WHITE='\e[1;37m'
NC='\e[0m'              # No Color
# Sample Command using color: echo -e "${CYAN}This is BASH
${RED}${BASH_VERSION%.*}${CYAN} - DISPLAY on ${RED}$DISPLAY${NC}\n"


# SOURCED ALIAS'S AND SCRIPTS
#######################################################

### Begin insertion of bbips alias's ###
source ~/.bbips/commandline/bbipsbashrc
### END bbips alias's ###

# Source global definitions
if [ -f /etc/bashrc ]; then
    . /etc/bashrc
fi

# enable programmable completion features
if [ -f /etc/bash_completion ]; then
    . /etc/bash_completion
fi


# ALIAS'S OF ALL TYPES SHAPES AND FORMS ;)
#######################################################

# Alias's to local workstations
alias tom='ssh 192.168.2.102 -l root'
alias jason='ssh 192.168.2.103 -l root'
alias randy='ssh 192.168.2.104 -l root'
alias bob='ssh 192.168.2.105 -l root'
alias don='ssh 192.168.2.106 -l root'
alias counter='ssh 192.168.2.107 -l root'

# ALIAS TO REMOTE SERVERS
alias ANYNAMEHERE='ssh YOURWEBSITE.com -l USERNAME -p PORTNUMBERHERE'
# My server info removed from above for obvious reasons ;)

# Alias's to TN5250 programs. AS400 access commands.
alias d1='xt5250 env.TERM = IBM-3477-FC env.DEVNAME=D1 192.168.2.5 &'
alias d2='xt5250 env.TERM = IBM-3477-FC env.DEVNAME=D2 192.168.2.5 &'
alias tn5250j='nohup java -jar /home/crouse/tn5250j/lib/tn5250j.jar
2>>error.log &'

# Alias's to some of my BashScripts
alias bics='sh /home/crouse/scripts/bics/bics.sh'
alias backup='sh /home/crouse/scripts/usalugbackup.sh'
alias calc='sh /home/crouse/scripts/bashcalc.sh'
alias makepdf='sh /home/crouse/scripts/makepdf.sh'
alias phonebook='sh /home/crouse/scripts/PHONEBOOK/baps.sh'
alias pb='sh /home/crouse/scripts/PHONEBOOK/baps.sh'
alias ppe='/home/crouse/scripts/passphraseencryption.sh'
alias scripts='cd /home/crouse/scripts'

# Alias's to control hardware
alias cdo='eject /dev/cdrecorder'
alias cdc='eject -t /dev/cdrecorder'
alias dvdo='eject /dev/dvd'
alias dvdc='eject -t /dev/dvd'
alias scan='scanimage -L'
alias playw='for i in *.wav; do play $i; done'
alias playo='for i in *.ogg; do play $i; done'
alias playm='for i in *.mp3; do play $i; done'
alias copydisk='dd if=/dev/dvd of=/dev/cdrecorder' # Copies bit by bit
from dvd to cdrecorder drives.
alias dvdrip='vobcopy -i /dev/dvd/ -o ~/DVDs/ -l'

# Alias's to modified commands
alias ps='ps auxf'
alias home='cd ~'
alias pg='ps aux | grep'  #requires an argument
alias un='tar -zxvf'
alias mountedinfo='df -hT'
alias ping='ping -c 10'
alias openports='netstat -nape --inet'
alias ns='netstat -alnp --protocol=inet | grep -v CLOSE_WAIT | cut
-c-6,21-94 | tail +2'
alias du1='du -h --max-depth=1'
alias da='date "+%Y-%m-%d %A    %T %Z"'
alias ebrc='pico ~/.bashrc'

# Alias to multiple ls commands
alias la='ls -Al'               # show hidden files
alias ls='ls -aF --color=always' # add colors and file type extensions
alias lx='ls -lXB'              # sort by extension
alias lk='ls -lSr'              # sort by size
alias lc='ls -lcr'      # sort by change time
alias lu='ls -lur'      # sort by access time
alias lr='ls -lR'               # recursive ls
alias lt='ls -ltr'              # sort by date
alias lm='ls -al |more'         # pipe through 'more'

# Alias chmod commands
alias mx='chmod a+x'
alias 000='chmod 000'
alias 644='chmod 644'
alias 755='chmod 755'

# Alias Shortcuts to graphical programs.
alias kwrite='kwrite 2>/dev/null &'
alias firefox='firefox 2>/dev/null &'
alias gaim='gaim 2>/dev/null &'
alias kate='kate 2>/dev/null &'
alias suk='kdesu konqueror 2>/dev/null &'

# Alias xterm and aterm
alias term='xterm -bg AntiqueWhite -fg Black &'
alias termb='xterm -bg AntiqueWhite -fg NavyBlue &'
alias termg='xterm -bg AntiqueWhite -fg OliveDrab &'
alias termr='xterm -bg AntiqueWhite -fg DarkRed &'
alias aterm='aterm -ls -fg gray -bg black'
alias xtop='xterm -fn 6x13 -bg LightSlateGray -fg black -e top &'
alias xsu='xterm -fn 7x14 -bg DarkOrange4 -fg white -e su &'

# Alias for lynx web browser
alias bbc='lynx -term=vt100 http://news.bbc.co.uk/text_only.stm'
alias nytimes='lynx -term=vt100 http://nytimes.com'
alias dmregister='lynx -term=vt100 http://desmoinesregister.com'


# SOME OF MY UNUSED ALIAS's
#######################################################

# alias d=`echo "Good Morning Dave. today's date is" | festival --tts;
date +'%A %B %e' | festival --tts`
# alias shrink84='/home/crouse/shrink84/shrink84.sh'
# alias tl='tail -f /var/log/apache/access.log'
# alias te='tail -f /var/log/apache/error.log'


# SPECIAL FUNCTIONS
#######################################################

netinfo ()
{
echo "--------------- Network Information ---------------"
/sbin/ifconfig | awk /'inet addr/ {print $2}'
echo ""
/sbin/ifconfig | awk /'Bcast/ {print $3}'
echo ""
/sbin/ifconfig | awk /'inet addr/ {print $4}'

# /sbin/ifconfig | awk /'HWaddr/ {print $4,$5}'
echo "---------------------------------------------------"
}

spin ()
{
echo -ne "${RED}-"
echo -ne "${WHITE}\b|"
echo -ne "${BLUE}\bx"
sleep .02
echo -ne "${RED}\b+${NC}"
}

scpsend ()
{
scp -P PORTNUMBERHERE "$@"
[email protected]:/var/www/html/pathtodirectoryonremoteserver/;
}


# NOTES
#######################################################

# To temporarily bypass an alias, we preceed the command with a \
# EG:  the ls command is aliased, but to use the normal ls command you would
# type \ls

# mount -o loop /home/crouse/NAMEOFISO.iso /home/crouse/ISOMOUNTDIR/
# umount /home/crouse/NAMEOFISO.iso
# Both commands done as root only.


# WELCOME SCREEN
#######################################################

clear
for i in `seq 1 15` ; do spin; done ;echo -ne "${WHITE} USA Linux Users
Group ${NC}"; for i in `seq 1 15` ; do spin; done ;echo "";
echo -e ${LIGHTBLUE}`cat /etc/SUSE-release` ;
echo -e "Kernel Information: " `uname -smr`;
echo -e ${LIGHTBLUE}`bash --version`;echo ""
echo -ne "Hello $USER today is "; date
echo -e "${WHITE}"; cal ; echo "";
echo -ne "${CYAN}";netinfo;
mountedinfo ; echo ""
echo -ne "${LIGHTBLUE}Uptime for this computer is ";uptime | awk /'up/
{print $3,$4}'
for i in `seq 1 15` ; do spin; done ;echo -ne "${WHITE} http://usalug.org
${NC}"; for i in `seq 1 15` ; do spin; done ;echo "";
echo ""; echo ""The following belong under the "function" section in my .bashrc. Useable as seperate programs, I've integrated them simply as functions for my .bashrc file in order to make them quick to use and easy to modify and find. These are functions that are used to symetrically encrypt and to decrypt files and messages. Some are completely command line, and the last two create gui interfaces to locate the files to encrypt/decrypt. If you create a program out of the functions creating a link via a shortcut/icon on the desktop would create a completely gui based interface to locate and encrypt/decrypt files. Either way, it's an easy way to use gpg.

Requires: zenity, gpg

################### Begin gpg functions ##################
encrypt ()
{
# Use ascii armor
gpg -ac --no-options "$1"
}

bencrypt ()
{
# No ascii armor
# Encrypt binary data. jpegs/gifs/vobs/etc.
gpg -c --no-options "$1"
}

decrypt ()
{
gpg --no-options "$1"
}

pe ()
{
# Passphrase encryption program
# Created by Dave Crouse 01-13-2006
# Reads input from text editor and encrypts to screen.
clear
echo "         Passphrase Encryption Program";
echo "--------------------------------------------------"; echo "";
which $EDITOR &>/dev/null
 if [ $? != "0" ];
     then
     echo "It appears that you do not have a text editor set in your
.bashrc file.";
     echo "What editor would you like to use ? " ;
     read EDITOR ; echo "";
 fi
echo "Enter the name/comment for this message :"
read comment
$EDITOR passphraseencryption
gpg --armor --comment "$comment" --no-options --output
passphraseencryption.gpg --symmetric passphraseencryption
shred -u passphraseencryption ; clear
echo "Outputting passphrase encrypted message"; echo "" ; echo "" ;
cat passphraseencryption.gpg ; echo "" ; echo "" ;
shred -u passphraseencryption.gpg ;
read -p "Hit enter to exit" temp; clear
}

keys ()
{
# Opens up kgpg keymanager
kgpg -k
}

encryptfile ()
{
zenity --title="zcrypt: Select a file to encrypt" --file-selection > zcrypt
encryptthisfile=`cat zcrypt`;rm zcrypt
# Use ascii armor
#  --no-options (for NO gui usage)
gpg -acq --yes ${encryptthisfile}
zenity --info --title "File Encrypted" --text "$encryptthisfile has been
encrypted"
}

decryptfile ()
{
zenity --title="zcrypt: Select a file to decrypt" --file-selection > zcrypt
decryptthisfile=`cat zcrypt`;rm zcrypt
# NOTE: This will OVERWRITE existing files with the same name !!!
gpg --yes -q ${decryptthisfile}
zenity --info --title "File Decrypted" --text "$encryptthisfile has been
decrypted"
}

################### End gpg functions ##################

[Dec 9, 2007] Cool Solutions Bash - Making use of your .bashrc file

Good sample bashrc file

Details

I was playing with my .bashrc file again, and was once again impressed by how you can tweak Linux to do what YOU want it to do so easily. I am sure there are tons of other tweaks you can do to your .bashrc file, but I really like some of mine, and thought I would share them. Some of the alias's I created, some I found on the net, and some things in my .bashrc file are just there for fun, like the "# WELCOME SCREEN", although it does serve a purpose for me at the same time, it might not be something everyone would want or need.

For those that don't know what a .bashrc file does: "The ~/.bashrc file determines the behavior of interactive shells." Quoted From: The Advanced Bash Scripting Guide 

Basically , it allows you to create shortcuts (alias's) and interactive programs (functions) that run on the startup of the bash shell or that are used when running an interactive shell. For example, it's much easier to just type: ebrc instead of pico ~/.bashrc (I used the alias ebrc , and it stands for "Edit Bash RC file". I could have also aliased it to just use one letter, making it a VERY fast short cut. The bashrc file allows you to create alias's (shortcuts) to almost anything you want. My list is pretty long, but I'm sure there is someone with a longer list ;)

I have my .bashrc file setup in sections. The following is the breakdown by section of how I keep my list of alias's and functions separated. This is just how I do this, your .bashrc file can be modified to suit YOUR needs, that's the interesting part about the .bashrc file. It's VERY customizable and very easy to change.

Header (So I know when i modified it last and what i was running it on)
Exports (So I can set history size, paths , editors, define colors, etc,)
Sourced Alias's (So I can find those hidden alias's faster)
Workstation Alias's (so i can ssh to local machines quickly)
Remote Server Alias's (so i can ssh to remote servers easily)
Script Alias's (quick links to some of my bashscripts)
Hardware control alias's (so I can control cd/dvd/scanners/audio/etc)
Modified commands (Alias's to normal linux commands with special flags)
Chmod Alias's (makes changing permissions faster)
Alias's for GUI programs (start firefox, etc from command line)
Alias's for xterm and others (open xterm with special settings)
Alias's for Lynx (open lynx with urls - kind of a bash bookmark ;) )
UNused Alias's (Alias's that aren't in use on the system, but that i might use later)
Special functions (more of a function than just an alias..it goes here)
Notes (that should be self explanatory ;) )
Welcome Screen (code to make my bash shell display some stuff as it starts up)

That's how I lay out my .bashrc files. It may not be perfect, but it works well for me. I like making changes in just my .bashrc file and not the global files. I like the .bashrc file because you don't need root permissions to make changes that make your life easier at the bash shell.

The following is my .bashrc file (with some things obviously commented out for security... but most of it should be self explanatory). Anyone with comments/suggestions/ideas feel free to let me know. I'm always looking for new and interesting things to do with the .bashrc file.

Want to know what alias's your bash shell has? Simply type the word alias at the command line. The shell will then print out the list of active alias's to the standard output (normally your screen).

#######################################################
# Dave Crouse's .bashrc file
# www.bashscripts.org
# www.usalug.org
#
# Last Modified 04-08-2006
# Running on OpenSUSE 10
#######################################################


# EXPORTS
#######################################################

PATH=$PATH:/usr/lib/festival/ ;export PATH
export PS1="[\[\033[1;34m\w\[\033[0m]\n[\t \u]$ "
export EDITOR=/usr/bin/pico
export HISTFILESIZE=3000 # the bash history should save 3000 commands
export HISTCONTROL=ignoredups #don't put duplicate lines in the history.
alias hist='history | grep $1' #Requires one input

# Define a few Color's
BLACK='\e[0;30m'
BLUE='\e[0;34m'
GREEN='\e[0;32m'
CYAN='\e[0;36m'
RED='\e[0;31m'
PURPLE='\e[0;35m'
BROWN='\e[0;33m'
LIGHTGRAY='\e[0;37m'
DARKGRAY='\e[1;30m'
LIGHTBLUE='\e[1;34m'
LIGHTGREEN='\e[1;32m'
LIGHTCYAN='\e[1;36m'
LIGHTRED='\e[1;31m'
LIGHTPURPLE='\e[1;35m'
YELLOW='\e[1;33m'
WHITE='\e[1;37m'
NC='\e[0m'              # No Color
# Sample Command using color: echo -e "${CYAN}This is BASH
${RED}${BASH_VERSION%.*}${CYAN} - DISPLAY on ${RED}$DISPLAY${NC}\n"


# SOURCED ALIAS'S AND SCRIPTS
#######################################################

### Begin insertion of bbips alias's ###
source ~/.bbips/commandline/bbipsbashrc
### END bbips alias's ###

# Source global definitions
if [ -f /etc/bashrc ]; then
    . /etc/bashrc
fi

# enable programmable completion features
if [ -f /etc/bash_completion ]; then
    . /etc/bash_completion
fi


# ALIAS'S OF ALL TYPES SHAPES AND FORMS ;)
#######################################################

# Alias's to local workstations
alias tom='ssh 192.168.2.102 -l root'
alias jason='ssh 192.168.2.103 -l root'
alias randy='ssh 192.168.2.104 -l root'
alias bob='ssh 192.168.2.105 -l root'
alias don='ssh 192.168.2.106 -l root'
alias counter='ssh 192.168.2.107 -l root'

# ALIAS TO REMOTE SERVERS
alias ANYNAMEHERE='ssh YOURWEBSITE.com -l USERNAME -p PORTNUMBERHERE'
# My server info removed from above for obvious reasons ;)

# Alias's to TN5250 programs. AS400 access commands.
alias d1='xt5250 env.TERM = IBM-3477-FC env.DEVNAME=D1 192.168.2.5 &'
alias d2='xt5250 env.TERM = IBM-3477-FC env.DEVNAME=D2 192.168.2.5 &'
alias tn5250j='nohup java -jar /home/crouse/tn5250j/lib/tn5250j.jar
2>>error.log &'

# Alias's to some of my BashScripts
alias bics='sh /home/crouse/scripts/bics/bics.sh'
alias backup='sh /home/crouse/scripts/usalugbackup.sh'
alias calc='sh /home/crouse/scripts/bashcalc.sh'
alias makepdf='sh /home/crouse/scripts/makepdf.sh'
alias phonebook='sh /home/crouse/scripts/PHONEBOOK/baps.sh'
alias pb='sh /home/crouse/scripts/PHONEBOOK/baps.sh'
alias ppe='/home/crouse/scripts/passphraseencryption.sh'
alias scripts='cd /home/crouse/scripts'

# Alias's to control hardware
alias cdo='eject /dev/cdrecorder'
alias cdc='eject -t /dev/cdrecorder'
alias dvdo='eject /dev/dvd'
alias dvdc='eject -t /dev/dvd'
alias scan='scanimage -L'
alias playw='for i in *.wav; do play $i; done'
alias playo='for i in *.ogg; do play $i; done'
alias playm='for i in *.mp3; do play $i; done'
alias copydisk='dd if=/dev/dvd of=/dev/cdrecorder' # Copies bit by bit
from dvd to cdrecorder drives.
alias dvdrip='vobcopy -i /dev/dvd/ -o ~/DVDs/ -l'

# Alias's to modified commands
alias ps='ps auxf'
alias home='cd ~'
alias pg='ps aux | grep'  #requires an argument
alias un='tar -zxvf'
alias mountedinfo='df -hT'
alias ping='ping -c 10'
alias openports='netstat -nape --inet'
alias ns='netstat -alnp --protocol=inet | grep -v CLOSE_WAIT | cut
-c-6,21-94 | tail +2'
alias du1='du -h --max-depth=1'
alias da='date "+%Y-%m-%d %A    %T %Z"'
alias ebrc='pico ~/.bashrc'

# Alias to multiple ls commands
alias la='ls -Al'               # show hidden files
alias ls='ls -aF --color=always' # add colors and file type extensions
alias lx='ls -lXB'              # sort by extension
alias lk='ls -lSr'              # sort by size
alias lc='ls -lcr'      # sort by change time
alias lu='ls -lur'      # sort by access time
alias lr='ls -lR'               # recursive ls
alias lt='ls -ltr'              # sort by date
alias lm='ls -al |more'         # pipe through 'more'

# Alias chmod commands
alias mx='chmod a+x'
alias 000='chmod 000'
alias 644='chmod 644'
alias 755='chmod 755'

# Alias Shortcuts to graphical programs.
alias kwrite='kwrite 2>/dev/null &'
alias firefox='firefox 2>/dev/null &'
alias gaim='gaim 2>/dev/null &'
alias kate='kate 2>/dev/null &'
alias suk='kdesu konqueror 2>/dev/null &'

# Alias xterm and aterm
alias term='xterm -bg AntiqueWhite -fg Black &'
alias termb='xterm -bg AntiqueWhite -fg NavyBlue &'
alias termg='xterm -bg AntiqueWhite -fg OliveDrab &'
alias termr='xterm -bg AntiqueWhite -fg DarkRed &'
alias aterm='aterm -ls -fg gray -bg black'
alias xtop='xterm -fn 6x13 -bg LightSlateGray -fg black -e top &'
alias xsu='xterm -fn 7x14 -bg DarkOrange4 -fg white -e su &'

# Alias for lynx web browser
alias bbc='lynx -term=vt100 http://news.bbc.co.uk/text_only.stm'
alias nytimes='lynx -term=vt100 http://nytimes.com'
alias dmregister='lynx -term=vt100 http://desmoinesregister.com'


# SOME OF MY UNUSED ALIAS's
#######################################################

# alias d=`echo "Good Morning Dave. today's date is" | festival --tts;
date +'%A %B %e' | festival --tts`
# alias shrink84='/home/crouse/shrink84/shrink84.sh'
# alias tl='tail -f /var/log/apache/access.log'
# alias te='tail -f /var/log/apache/error.log'


# SPECIAL FUNCTIONS
#######################################################

netinfo ()
{
echo "--------------- Network Information ---------------"
/sbin/ifconfig | awk /'inet addr/ {print $2}'
echo ""
/sbin/ifconfig | awk /'Bcast/ {print $3}'
echo ""
/sbin/ifconfig | awk /'inet addr/ {print $4}'

# /sbin/ifconfig | awk /'HWaddr/ {print $4,$5}'
echo "---------------------------------------------------"
}

spin ()
{
echo -ne "${RED}-"
echo -ne "${WHITE}\b|"
echo -ne "${BLUE}\bx"
sleep .02
echo -ne "${RED}\b+${NC}"
}

scpsend ()
{
scp -P PORTNUMBERHERE "$@"
[email protected]:/var/www/html/pathtodirectoryonremoteserver/;
}


# NOTES
#######################################################

# To temporarily bypass an alias, we preceed the command with a \
# EG:  the ls command is aliased, but to use the normal ls command you would
# type \ls

# mount -o loop /home/crouse/NAMEOFISO.iso /home/crouse/ISOMOUNTDIR/
# umount /home/crouse/NAMEOFISO.iso
# Both commands done as root only.


# WELCOME SCREEN
#######################################################

clear
for i in `seq 1 15` ; do spin; done ;echo -ne "${WHITE} USA Linux Users
Group ${NC}"; for i in `seq 1 15` ; do spin; done ;echo "";
echo -e ${LIGHTBLUE}`cat /etc/SUSE-release` ;
echo -e "Kernel Information: " `uname -smr`;
echo -e ${LIGHTBLUE}`bash --version`;echo ""
echo -ne "Hello $USER today is "; date
echo -e "${WHITE}"; cal ; echo "";
echo -ne "${CYAN}";netinfo;
mountedinfo ; echo ""
echo -ne "${LIGHTBLUE}Uptime for this computer is ";uptime | awk /'up/
{print $3,$4}'
for i in `seq 1 15` ; do spin; done ;echo -ne "${WHITE} http://usalug.org
${NC}"; for i in `seq 1 15` ; do spin; done ;echo "";
echo ""; echo ""The following belong under the "function" section in my .bashrc. Useable as seperate programs, I've integrated them simply as functions for my .bashrc file in order to make them quick to use and easy to modify and find. These are functions that are used to symetrically encrypt and to decrypt files and messages. Some are completely command line, and the last two create gui interfaces to locate the files to encrypt/decrypt. If you create a program out of the functions creating a link via a shortcut/icon on the desktop would create a completely gui based interface to locate and encrypt/decrypt files. Either way, it's an easy way to use gpg.

Requires: zenity, gpg

################### Begin gpg functions ##################
encrypt ()
{
# Use ascii armor
gpg -ac --no-options "$1"
}

bencrypt ()
{
# No ascii armor
# Encrypt binary data. jpegs/gifs/vobs/etc.
gpg -c --no-options "$1"
}

decrypt ()
{
gpg --no-options "$1"
}

pe ()
{
# Passphrase encryption program
# Created by Dave Crouse 01-13-2006
# Reads input from text editor and encrypts to screen.
clear
echo "         Passphrase Encryption Program";
echo "--------------------------------------------------"; echo "";
which $EDITOR &>/dev/null
 if [ $? != "0" ];
     then
     echo "It appears that you do not have a text editor set in your
.bashrc file.";
     echo "What editor would you like to use ? " ;
     read EDITOR ; echo "";
 fi
echo "Enter the name/comment for this message :"
read comment
$EDITOR passphraseencryption
gpg --armor --comment "$comment" --no-options --output
passphraseencryption.gpg --symmetric passphraseencryption
shred -u passphraseencryption ; clear
echo "Outputting passphrase encrypted message"; echo "" ; echo "" ;
cat passphraseencryption.gpg ; echo "" ; echo "" ;
shred -u passphraseencryption.gpg ;
read -p "Hit enter to exit" temp; clear
}

keys ()
{
# Opens up kgpg keymanager
kgpg -k
}

encryptfile ()
{
zenity --title="zcrypt: Select a file to encrypt" --file-selection > zcrypt
encryptthisfile=`cat zcrypt`;rm zcrypt
# Use ascii armor
#  --no-options (for NO gui usage)
gpg -acq --yes ${encryptthisfile}
zenity --info --title "File Encrypted" --text "$encryptthisfile has been
encrypted"
}

decryptfile ()
{
zenity --title="zcrypt: Select a file to decrypt" --file-selection > zcrypt
decryptthisfile=`cat zcrypt`;rm zcrypt
# NOTE: This will OVERWRITE existing files with the same name !!!
gpg --yes -q ${decryptthisfile}
zenity --info --title "File Decrypted" --text "$encryptthisfile has been
decrypted"
}

################### End gpg functions ##################

Jamie's Shell Stuff

bashrc :

#
# Jamie's Common .bashrc file for all platforms
# ---------------------------------------------
#
# See myenv/bashrc.$ARCH for platform specific .bashrc files.
#
 
# Work out ARCH name from platforms we use.
ARCH=`uname`
case $ARCH in
  Linux*)
    ARCH=linux
    ;;
  SunOS*)
    ARCH=solaris
    ;;
  OSF1*)
    ARCH=osf1
    ;;
  IRIX64*)
    ARCH=irix
    ;;
  *)
    ;;
esac
export ARCH

# Load platform specific bashrc file if one exists.
if test -e ~/myenv/bashrc.$ARCH ; then
  source ~/myenv/bashrc.$ARCH
fi

# Set up common paths. This is where I put general executables 
# and scripts
if [ -n "$PATH" ]; then
  PATH=$PATH:~/bin:~/bin/$ARCH
else
  PATH=~/bin:~/bin/$ARCH
fi

# Set up GNU paths if they exist. For some of the machines I use I
# don't have root access to install my own software, so I build it 
# and install it in ~/gnu/$ARCH. ~/gnu is for stuff that is common
# across all platforms (e.g. scripts).
for DIR in ~/gnu/bin \
           ~/gnu/bin/$ARCH ; do
  if [ -n "$PATH" ]; then
    test -d $DIR && PATH=$DIR:$PATH
  else
    test -d $DIR && PATH=$DIR
  fi
done
PATH=$PATH:/usr/local/bin
export PATH

# Set up man/info paths for above. Some of the software installed in
# the above may have man/info pages and I'd quite like access to
# these
for DIR in ~/gnu/man \
           ~/gnu/$ARCH/man ; do
  if [ -n "$MANPATH" ]; then
    test -d $DIR && MANPATH=$MANPATH:$DIR
  else
    test -d $DIR && MANPATH=$DIR
  fi
done
for DIR in ~/gnu/info \
           ~/gnu/$ARCH/info ; do
  if [ -n "$INFODIR" ]; then
    test -d $DIR && INFODIR=$INFODIR:$DIR
  else
    test -d $DIR && INFODIR=$DIR
  fi
done
INFOPATH=$INFORDIR
export MANPATH INFODIR INFOPATH

# set X display if we are on remote host.
DISPLAY=
if [ -n "$REMOTEHOST" ]; then
    DISPLAY=$REMOTEHOST:0.0
elif [ $TERM != linux ]; then
    DISPLAY=:0.0
fi
export DISPLAY

# Load any aliases.
source ~/myenv/bash.aliases

Recommended Links

Softpanorama Recommended

Top articles

Sites

Top articles

Sites

Internal

• Customizing Shell Dot Files: .profile, RC-file, and history

External

• csh.startup.faq
• UnixWorld Online Tutorial Article No. 018 -- Getting the Most From Your Shell -- good intro article
• Bash module for the Dotfile Generator -- reference manual
• Advanced Systems - March 1995 - Column

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: April, 23, 2019