clever bash tricks
Author: dhart
Date: Fri Apr 8 23:56:26 2005
Subject: clever bash tricks
One thing that has always bothered me is having to type in long pathnames. I guess I should have read the documentation since there is indeed a better way.
As an example, if you have virtual hosts joe, fred and bob setup in /var/www/html/fred you might try this:
# export CDPATH=/var/www/html:
# cd fred
/var/www/html/fred
# cd bob
/var/www/html/bob
One of the nice things about changing directories on an OpenServer system is that you don't have to be a goo d sepller.
# shopt -s cdspell
# cd /vra
/var
Both CDPATH and shopt are things that you would put in your .bashrc but not your .bash_profile.
Enter your email address for automatic notification of new posts here
(be sure to whitelist 'feedburner.com' if you use spam filtering)
| Views for this page |
| Today | This Week | This Month | This Year | Overall |
| 3 | 18 | 106 | 2,568 | 8,518 |
/Blog2005/dhart1.html copyright April 2005 dhart All Rights Reserved
Have you tried Searching this site?
Unix/Linux/Mac OS X support by phone, email or on-site:
Support Rates
This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more. We appreciate comments and article submissions.
Publishing your articles here
Sat Apr 9 11:26:26 2005: Subject: TonyLawrence
I don't like cedspell because it just does what it thinks is right rather than ask a question as the sh on Openserver does. For example, if I have directories "fred" and "fref", then "cd fres" takes me to "fref". If this were implemented based on keyboard proximity, I think it would be much more useful - the "s" is right beside "d", so is more likely what I was trying to do - assuming, of course, that directory mismatches are bad typing rather than bad spelling. That may not always be the best assumption, but it's probably not a bad place to start.
The "cd fred?" question that the OpenServer sh does also has the side effect of eating a keystroke, which could help prevent a terrible mistake in a directory you didn't mean to be in. The "cdspell" option asks no question.
Fortunately, neither of these things work unless the shell is interactive (a script won't behave this way) and I do like that the default bash doesn't have this set.
Sat Apr 9 18:49:48 2005: Subject: drag
There are some more tips here:
http://www.caliban.org/bash/
that are similar to what you have posted above..
One of the things that I think is VERY neat with newer versions of Bash is their programmable autocompletion. As I understand it, it's been possible to do this with ksh forever, but it's a new feature for bash. (versions 2.04, 2.05 and newer).
Sat Apr 9 19:37:44 2005: Subject: TonyLawrence
See http://aplawrence.com/Unix/customtab.html for more on tab autocompletion
Sun Apr 10 05:53:40 2005: Subject: when to use .bashrc vs. .bash_profile anonymous
As a newcomer to bash (OS X) I would like to know the subtle in and outs of when to use .bashrc and when to use .bash_profile - and while I am asking - when to use .profile....
Sun Apr 10 11:22:00 2005: Subject: TonyLawrence
You aren't the first person to be confused by .bash_profile vs. .bashrc. This comes up regularly, and the difference is simply this:
Your .bash_profile runs once, when you login ( in Mac OS X, when you do Terminal->New Shell). The .bashrc is executed for every bash shell script run by you from then on. Use .bashrc to set variables etc. that you want to be set for every script you run from the shell. Set aliases in .bashrc also.
Examples: you might set PATH in .bashrc so that every script starts out with the same setting. If you had some file that logs backups and you want to see that every time you login, you'd put that command in .bash_profile.
The .bashrc runs BEFORE .bash_profile at login. Also, (as shown above in the excerpt from the man page), .bash_profile is bash's first choice, but if that doesn't exist, it will read .bash_login or try ~/.profile if neither exists - but it only uses ONE of those three. So bash will NEVER use .profile if you have .bash_profile.
Technically, .bash_profile runs for "interactive" shells. From the manual:
An interactive shell is one started without non-option arguments and
without the -c option whose standard input and output are both con-
nected to terminals (as determined by isatty(3)), or one started with
the -i option. PS1 is set and $- includes i if bash is interactive,
allowing a shell script or a startup file to test this state.
So you COULD get .bash_profile to run again if you needed it to with "-i", though that's more than unusual.
Mon Apr 11 19:41:00 2005: Subject: useless appreciation posting anonymous
This is exactly the information I was looking for! Many thanks!
Fri Jan 25 07:53:53 2008: Subject: anonymous
It is actually not so cut and dry...
Version 3.1.17(1)-release on Suse linux sources .bashrc followed by .bash_profile for login and for all subshells, only .bashrc
Version 3.2.0(2)-release on Irix sources only .bash_profile on login, and only .bashrc for subshells.
Version 3.2.17(6)-release on Solaris sources only .bashrc for logins and only .bashrc for subshells
With this level of inconsistency across platforms, no wonder people are confused!
Fri Jan 25 12:49:55 2008: Subject: TonyLawrence
When implementors get confused, how can users avoid it?
Add your comments