Introduction to Unix shell(matt.might.net)
matt.might.net
Introduction to Unix shell
http://matt.might.net/articles/settling-into-unix/
22 comments
I skip a beat, but any shell user will need this at some point in his life : http://mywiki.wooledge.org/
So many 'I wish I'd known earlier'
Other links straight from #bash@freenode
Topic for #bash is: FAQ: http://mywiki.wooledge.org/BashFAQ | Guide: http://mywiki.wooledge.org/BashGuide | ref: http://xrl.us/bhk9ww | http://wiki.bash-hackers.org/ | USE MORE QUOTES!: http://www.grymoire.com/Unix/Quote.html | Scripts and more: http://www.shelldorado.com/ | New official help mailing list: http://tx0.org/31f
They're all deeply useful
So many 'I wish I'd known earlier'
Other links straight from #bash@freenode
Topic for #bash is: FAQ: http://mywiki.wooledge.org/BashFAQ | Guide: http://mywiki.wooledge.org/BashGuide | ref: http://xrl.us/bhk9ww | http://wiki.bash-hackers.org/ | USE MORE QUOTES!: http://www.grymoire.com/Unix/Quote.html | Scripts and more: http://www.shelldorado.com/ | New official help mailing list: http://tx0.org/31f
They're all deeply useful
Only slightly on topic, but the choice of shell discussion always interests me.
Within the open source world, I hear about sh, bash, zsh, fish, and occasionally scsh.
It is _only_ in the academic world that I ever hear discussion about things like csh or tcsh.
Anyone know why?
Within the open source world, I hear about sh, bash, zsh, fish, and occasionally scsh.
It is _only_ in the academic world that I ever hear discussion about things like csh or tcsh.
Anyone know why?
Probably just a historical artifact; it's common at places with long Unix histories.
The first UNIX machine that I used (circa 1985-1986) had one shell: /bin/sh. No command history, no anything. If you made a typo you had to re-type the whole line, being more careful this time (of course this is before we had graphical terminals with cut&paste) In fact, it was a common habit that if you were going to run a complicated command you'd write a one-off shell script, just so you could edit it if it didn't work.
After some months we managed to get a copy of /bin/csh, and it was a godsend. Now we had a history buffer.. you couldn't do anything "modern" like editing the command line with arrow keys (and certainly no tab-completion yet; some later versions of csh supported completion using the escape key however) However you had things like "!!", "!$", "^foo^bar" for at least modifying the last command run. All of these csh-isms later appeared in bash, btw.
csh was simply such a huge improvement for interactive use you could hardly not use it. The only downside was that it had its own incompatible scripting language which was supposed to be more C-like but actually was just fairly busted. Worse, this was before "#!/bin/sh" was understood by the kernel so scripts just broke: for some reason anything that started with a comment, csh would decide to run itself and fail. However there was a hack where if you started the script with a line that just had ":" it would pass it to /bin/sh instead. So we updated all our scripts and life was good.
A few years later when tcsh was getting popular, migrating to it was natural. You could keep your existing .cshrc/.login files and get all of the modern tab-competing, line-editing goodness. There was a time in the 1990s when just about everybody seemed to be running tcsh except for a handful of ksh fans.
Once you're on tcsh the motivation to move to bash is smaller.. after all, most things work OK. Personally I only converted about 5 years ago: I got sick of having to install tcsh on new machines so I sat down and rewrote my 800-line .cshrc that I'd accumulated over 20 years.
I'm glad I did though. There are often times when I just want to write a short script on the command line (something a simple as "for x in a b c; do blah; done") but I could never remember the csh syntax. So I was always dropping from csh to sh to run them or even doing "sh -c '...'" It's much nicer just being able to type that at my shell prompt.
The first UNIX machine that I used (circa 1985-1986) had one shell: /bin/sh. No command history, no anything. If you made a typo you had to re-type the whole line, being more careful this time (of course this is before we had graphical terminals with cut&paste) In fact, it was a common habit that if you were going to run a complicated command you'd write a one-off shell script, just so you could edit it if it didn't work.
After some months we managed to get a copy of /bin/csh, and it was a godsend. Now we had a history buffer.. you couldn't do anything "modern" like editing the command line with arrow keys (and certainly no tab-completion yet; some later versions of csh supported completion using the escape key however) However you had things like "!!", "!$", "^foo^bar" for at least modifying the last command run. All of these csh-isms later appeared in bash, btw.
csh was simply such a huge improvement for interactive use you could hardly not use it. The only downside was that it had its own incompatible scripting language which was supposed to be more C-like but actually was just fairly busted. Worse, this was before "#!/bin/sh" was understood by the kernel so scripts just broke: for some reason anything that started with a comment, csh would decide to run itself and fail. However there was a hack where if you started the script with a line that just had ":" it would pass it to /bin/sh instead. So we updated all our scripts and life was good.
A few years later when tcsh was getting popular, migrating to it was natural. You could keep your existing .cshrc/.login files and get all of the modern tab-competing, line-editing goodness. There was a time in the 1990s when just about everybody seemed to be running tcsh except for a handful of ksh fans.
Once you're on tcsh the motivation to move to bash is smaller.. after all, most things work OK. Personally I only converted about 5 years ago: I got sick of having to install tcsh on new machines so I sat down and rewrote my 800-line .cshrc that I'd accumulated over 20 years.
I'm glad I did though. There are often times when I just want to write a short script on the command line (something a simple as "for x in a b c; do blah; done") but I could never remember the csh syntax. So I was always dropping from csh to sh to run them or even doing "sh -c '...'" It's much nicer just being able to type that at my shell prompt.
This is a bit chicken-and-egg, but every account I've been given on shared UNIX systems at universities (n >= 7) has used (t)csh as the default shell.
IIRC, the default shell on many BSDs is tcsh. I guess it was probably csh before that in some point in history. That might have something to do with it.
Only FreeBSD. OpenBSD and NetBSD aren't that fucked up.
And OSX prior to 10.3 apparently.
Inherited from FreeBSD, of course.
Everyone complained so they changed it.
Everyone complained so they changed it.
Partly, in the programming world people tend to have read and agree with the essay "Csh Programming Considered Harmful", in that they think the problems it mentions are relevant to their lives.
http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/
http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/
I was very surprised that he doesn't mention to stay away from scripting in csh/tcsh.
I've been using tcsh for 11 years now and I wish bash had been the default for the first unix job I had, because tcsh is the devil for writing any script greater than 10 lines.
I've been using tcsh for 11 years now and I wish bash had been the default for the first unix job I had, because tcsh is the devil for writing any script greater than 10 lines.
> It's a near certainty that a bash interpreter will be available on a Unix system; bash has become the JVM of the Unix world.
Don't assume this if you want your shell scripts to be portable. Follow posix standard instead.
Don't assume this if you want your shell scripts to be portable. Follow posix standard instead.
I found what seems to be a small error in your article. In the vim section it says "To switch to command mode from insertion mode, press i." I think it should say "To switch from command mode to insertion mode, press i."
For some reason I never thought of doing this before:
alias might='ssh [email protected]'
You might be better off using a .ssh/config file, as in this tutorial:
http://fabien.potencier.org/article/19/quick-ssh-tip
It saves about as many keystrokes, also works in scp, and won't clutter up your shell dotfiles.
http://fabien.potencier.org/article/19/quick-ssh-tip
It saves about as many keystrokes, also works in scp, and won't clutter up your shell dotfiles.
http://en.wikipedia.org/wiki/The_UNIX_Programming_Environmen... all you'll ever need?
This book is excellent!
I can't wait for the next articles...
This was the lecture for Matt's scripting languages class today. If you'd like a head start on the material, take a look at the materials section of the course page:
http://matt.might.net/teaching/scripting-languages/spring-20...
http://matt.might.net/teaching/scripting-languages/spring-20...
Tip: The default Bourne-shell-compatible prompts end with $ while the default C-shell-compatible prompts end with % or >. (zsh is an exception to this.) Root (super-user) prompts often end with # by default. Of course, this behavior is configurable.
Gee, who could ever find that confusing?!
As much as I love Unix now, I can't help but understand when the author says students see the above as a "baroque regression". It just seems so ridiculously arcane when you're used to clicking on things. Of course things are much better once you're on the other side of the learning curve, but it can be a doozy.
Gee, who could ever find that confusing?!
As much as I love Unix now, I can't help but understand when the author says students see the above as a "baroque regression". It just seems so ridiculously arcane when you're used to clicking on things. Of course things are much better once you're on the other side of the learning curve, but it can be a doozy.
Well, the above descriptions of shell prompts are the defaults.
If you strip out all configuration files, this is the behavior you'll see.
Of course, it's better to explicitly check to see what shell you're running ('help', 'ps up $$', grep $UID /etc/passwd | cut -d: -f7').
If you strip out all configuration files, this is the behavior you'll see.
Of course, it's better to explicitly check to see what shell you're running ('help', 'ps up $$', grep $UID /etc/passwd | cut -d: -f7').
>It's a near certainty that a bash interpreter will be available on a Unix system
Someone confused "linux" and "unix". Linux systems almost certainly have bash installed. BSDs and commercial unixes don't.
Someone confused "linux" and "unix". Linux systems almost certainly have bash installed. BSDs and commercial unixes don't.
Here's another little guide which goes over all the general topics: https://docs.google.com/viewer?a=v&q=cache:4oBqPlq1f7oJ:...