How to learn your way through Linux's shell

Question

I want to stop losing precious time when dealing with linux/unix's shell.

If I could get to understand it all so well, that would be so great. Otherwise:

• I may end up loosing a day just for setting up a crontab.
• I'll keep wondering why the shebang in this script doesn't work.
• I'll keep wondering what's the real difference between:
  • . run.sh
  • ./run.sh
  • . ./run.sh
  • sh run.sh
  • sh ./run.sh

You see, it's that kind of things that cripples my linux/unix life.

As a programmer, I want to get much better at this. I suppose it's best to stay with the widely-used bash shell, but I might be wrong. Whatever tool I use, I need to understand it down to its guts.

What is the ultimate solution?

Answer 1

The best way to learn is by reading, and then trying things out. MAN pages are often very helpful, and there are tons of Shell scripting tutorials out there. If shell scripting is what you are after, just read, and then practice the things you read by writing little scripts that do something neat or fun. If you are looking for more info on all of the different command line applications that can be run from a shell, those are more distro dependent, so look in the documentation for your favorite distro.

Answer 2

I think immersing yourself in it is the answer. It's like learning to walk, to type, to use an ergonomic keyboard, or type in dvorak. Commit to it completely. And yes, you will absolutely slow down. And you'll be forced to look at your hands or google things constantly. But eventually it will come to you.

Funny story, I killed my apartment's internet access by doing an ifconfig release. Completely didn't know that ifconfig renew was not a command. Had to call a friend when google didn't load ;) dhcpcd later and I was back to googling everything.

Answer 3

Try the Linux Documentation Project's BASH pages here [tldp.org].
PS: The difference is that . is the same as the source command. This only requires read permission. To use ./run.sh, you need execute permissions. When you use 'sh', you are explicitly specifying the command you want to run the script with (here, you only need read permission). If you are using a shell to execute it, there shouldn't be a problem there. If you want to use a different program, such as 'python', you could use python run.py. Another trick is to add a line #!<program> to the beginning of your script. In your case, #!/bin/sh would do, and for Python, #/usr/bin/env python is best.

Answer 4

use the shell a lot, type "[prog-name] --help" a lot, type "man [prog-name]" a lot, and make notes on what works and what does not -- even if those notes seem obvious at the time. By tomorrow, they might not be so obvious, again. OTOH, in a couple of weeks they definitely should be!

Have a gander at some of the many books on working with shells, like From Bash to Z Shell (which covers Bash and Z), slog through a shell-scripting tutorial, or Gnu's Bash manual.

Answer 5

Just for fun:

1. . run.sh --- "Source" the code in run.sh. Usually, this is used to get environment variables into the current shell processes. You probably don't want this for a script called run.sh.

2. ./run.sh --- Execute the run.sh script in the current directory. Generally the current directory is not in the default path (see $PATH), so you need to call out the relative location explicitly. The . character is used differently than in item #1.

3. . ./run.sh --- Source the run.sh script in the current directory. This combines the use of . from items #1 and #2.

4. sh run.sh --- Use the sh shell interpretor on run.sh. Bourne shell is usually the default for running shell scripts, so this is probably the same as item #2 except it finds the first run.sh in the $PATH rather than the one in the current directory.

5. sh ./run.sh --- And this is usually the same as #2 except wordier.

Command line interfaces, such as the various shell interpretors, tend to be very esoteric since they need to pack a lot of meaning into a small number of characters. Otherwise typing takes too long.

In terms of learning, I'd suggest using bash or ksh and don't let anyone talk you into something else until you are comfortable. Please don't learn with csh or you will need to unlearn too much when you start with a Bourne-type shell later.

Also, crontab entries are a bit trickier than other uses of shell. My guess is you lost time because your environment was set differently than on the command line. I would suggest starting somewhere else if possible.

Answer 6

Man pages are probably the "ultimate" solution. I'm always amazed at what gems they contain.

You can even use man bash to answer some of the questions you raise in this question.

Answer 7

Oreily has an older book that teaches you about bash, and bash scripting at the end. Most everything you need to know is on the web, but spread out.

Answer 8

There are some decent online guides that will help you feel more comfortable in the shell(s). For example:

• Steve Parker's Unix/Linux Shell Scripting Tutorial
• UNIX Shell Programming, by Stephen G. Kochan and Patrick H. Wood, available online at Google Books. Also available in hardback. Amazon has it.
• UNIX shell scripting with sh/ksh. Apparently used as part of a class at Dartmouth College. ksh is the Korn shell, and it's close enough to bash that the info will be useful.

Spend some time reading those kinds of tutorials and, above all, playing in the shell. Pretty soon, it'll start to feel like $HOME. (Okay, sorry for the bad pun...)

Answer 9

The way I really learned my way around in Linux was to install gentoo. It takes forever but you begin to see how everything ties together.

Go grab the latest instructions and start following them. Do it enough times and it starts to stick.

After a while you get comfortable building everything from scratch.

Answer 10

I find trying to learn a new command using the man pages sometimes a bit overwhelming.

I prefer man pages for refreshing my memory.

When I want to learn a command I look for examples then use the man pages to fine tune what I want it to do.

Answer 11

While sticking with Bash might be best, while just learning, the fish shell might be a little bit easier to use. I played around with it for a few weeks, and while it didn't seem as powerful as bash, it did seem pretty user friendly.