I just found this page on the OReilly website – a Linux Command Directory

Click on any of the 687 commands below to get a description and list of available options. All links in the command summaries point to the online version of the book on Safari Bookshelf.

It doesn’t cover everything (what could?) but it could be a useful page to bookmark.

I have previously plugged the great list of sed 1-liners at http://sed.sourceforge.net/sed1line.txt.

Here is a similar (if shorter) list of handy awk 1-liners:

http://www.sap-basis-abap.com/unix/awk-one-liner-tips.htm:

Print column1, column5 and column7 of a data file or output of any columns list

awk '{print $1, $5, $7}' data_file

ls –al |awk '{print $1, $5, $7}' -- Prints file_permissions,size and date

List all files names whose file size greater than zero.

ls –al |awk '$5 > 0 {print $9}'

List all files whose file size equal to 512bytes.

ls –al |awk '$5 == 0 {print $9}'

print all lines

awk '{print }' file_name

awk '{print 0}' file_name

Number of lines in a file

awk ' END {print NR}' file_name

Number of columns in each row of a file

awk '{print NF}' file_name

Sort the output of file and eliminate duplicate rows

awk '{print $1, $5, $7}' |sort –u

List all file names whose file size is greater than 512bytes and owner is “oracle”

ls –al |awk '$3 == "oracle" && $5 > 512 {print $9}'

List all file names whose owner could be either “oracle” or “root”

ls –al |awk '$3 == "oracle" || $3 == "root" {print $9}'

list all the files whose owner is not “oracle

ls –al |awk '$3 != "oracle" {print $9}'

List all lines which has at least one or more characters

awk 'NF > 0 {print }' file_name

List all lines longer that 50 characters

awk 'length($0) > 50 {print }' file_name

List first two columns

awk '{print $1, $2}' file_name

Swap first two columns of a file and print

awk '{temp = $1; $1 = $2; $2 = temp; print }' file_name

Replace first column as “ORACLE” in a data file

awk '{$1 = "ORACLE"; print }' data_file

Remove first column values in a data file

awk '{$1 =""; print }' data_file

Calculate total size of a directory in Mb

ls –al |awk '{total +=$5};END {print "Total size: " total/1024/1024 " Mb"}'

Calculate total size of a directory including sub directories in Mb

ls –lR |awk '{total +=$5};END {print "Total size: " total/1024/1024 " Mb"}'

Find largest file in a directory including sub directories

ls –lR |awk '{print $5 "\t" $9}' |sort –n |tail -1

http://www.seanius.net/blog/2009/03/saving-and-restoring-positional-params/ has a really good post about how “shift” loses the original command-line arguments, discusses various seemingly-obvious ways of restoring them, explores why they fail for certain types of input, and provides what seems to be a working solution:

one way you could try to store/save them would be to save the original copy of $@ and use eval set — later on to change it back to the saved variable

… but as it turns out, that doesn’t work with spaces, or quotes. Excellent, really concise description of the problem(s) and solution(s).

Shell Script: GetCluster – a shell script I happen to have written today; uses a few features of GNU Grep, whilst being tolerant of non-GNU greps (at the cost of some functionality).

This simple shell script is an example of the kind of thing that can easily be done with a few simple commands. As it is intended for the Solaris platform, which does not necessarily include GNU’s grep, some additional complexity is required to see what the platform’s grep utility is capable of.

This is achieved by:
1) Set the PATH to pick up the GNU tools first: PATH=/usr/sfw/bin:$PATH
2) Find grep (ggrep if possible; the existence of ggrep suggests that grep itself is not GNU’s grep):
type ggrep >/dev/null 2>&1
if [ "$?" -eq "0" ]; then
GREP=`which ggrep`
else
GREP=`which grep`
fi


It then finds a file, which could be in one of many places:
CLUSTERTOC=`ls clustertoc .clustertoc /cdrom/cdrom0/Solaris*/Product/.clustertoc /cdrom/Solaris*/Product/.clustertoc /mnt/Solaris*/Product/.clustertoc 2>/dev/null|head -1`
What this does, is identify the first succesful match (the rest go to /dev/null). If none is found, the CLUSTERTOC will not be a valid file (note: this gets us the added bonus that it will complain if clustertoc is a device driver, pipe, etc).

It then looks for “SUNW_CSRMEMBER” in the clustertoc, using “grep -n” to get the line number, then passing that linenumber on to head so as to limit the output to only contain those lines. Any lines below that point would refer to other clusters, and be irrelevant. We want to get the last of the relevant part of the file, so that the tail command below will give us what we need.

GNU Grep has a “-A n” and “-B n” facility to say “include n lines After the matching line” or “include n lines Before the matching line”. We use “-A” here to get the following lines which describe the pacakge in more detail:
head -${linenum} $CLUSTERTOC |$GREP -A4 "^CLUSTER="|cut -d"=" -f2-|tail -4

See the readme file for specific output – the Solaris (non-GNU) version has notably less detail than the GNU version.

Hopefully the script (http://steve-parker.org/code/sh/getcluster/getcluster.sh) is in other ways sufficiently self-explanatory.

The input file (http://steve-parker.org/code/sh/getcluster/clustertoc is relatively simple, and should explain any other queries.

Still – this simple script may provoke a few questions; please do play with it and ask away, if anything is unclear.

I have missed the second birthday of this blog; starting with Hello World on 17th January 2007, this blog has seen a small growth, but the comments posted show that people have found it to be useful, which is good.

Traffic

Statistics

I hope that you continue to find it useful; I really will try to post a bit more often in 2009!

Steve

echo unccl puevfgznf | tr A-Za-z N-ZA-Mn-za-m

This is a very simplistic thing called “rot13″, whereby “a” becomes “n”, “b” becomes “o”, “c” becomes “p”, and so on. The tr utility is ideal for simple string manipulation like this.

Happy Christmas to all!

You can forward ports with ssh like this:

$ ssh -L 8080:localhost:80 user@remotehost

This will log you in to remotehost as user, and port 8080 on your local machine will be tunnelled to port 80 on remotehost. If remotehost can see a machine that you can’t (for example, if it’s on an internal network), you can even do this:

$ ssh -L 8080:internalhost:80 user@borderhost

This will log you in to borderhost, and localhost:8080 will be directed to internalhost:80, even though you may not be able to see internalhost directly yourself.

What I didn’t know until I read Nico Golde’s blog today, is that you can do this interactively, with an existing session. Tilde (~) is the default escape character, and ~C (note that’s an uppercase C) gets you a shell session within ssh itself:

$ ssh user@remotehost
user@remotehost$ ~C
ssh> -L 8080:localhost:80
Forwarding port.
user@remotehost$

Mike Hommey has a nice article on clearing down deleted (but still-open) files:
http://glandium.org/blog/?p=211. He explains the problem clearly, and goes on to provide the solution, too. Well worth bookmarking, for that 2am emergency!

someone had to free some space on a 1GB filesystem, and thought a good idea would be to delete that 860MB log file that nobody cares about. Except that it didn’t really remove it, but he didn’t really check.

Later, the “filesystem full” problem came back at someone else, who came to ask me what files from a small list he could remove. But the files were pretty small, and that wouldn’t have freed enough space. That gave me the feeling that we probably were in this typical case I introduced this post with, which du -sk confirmed: 970MB used on the filesystem according to df, but only 110MB worth of data…

Mike has solutions to this for Solaris and Linux; lsof is also useful for this kind of thing, on systems which have it.

When using the more tool (this works with less, also, and less is generally more useful; you can scroll backwards and forwards with less), you can press “v” to start editing the file, in vi, at the line you are currently viewing.

This works on Linux and Solaris; please confirm on other OSes as appropriate, though I would assume that what works on more on Solaris, will work on more or less on just about any OS.

This makes using more or less far more powerful than before, and a new way into vi.

Ben Hutchings has noted a quirk in the chmod syntax: If you use the “chmod o-x” syntax, but omit the “o” (Others) (or the “u” (User) or “g” (Group)), it will default to “a” (All).

So “chmod -x foo” becomes “chmod a-x foo“; similarly, “chmod +x foo” becomes “chmod a+x foo“

Interesting list of 15 examples of bash history syntax.

Most people probably know #5:
# !ps
ps aux | grep yp

I didn’t know #13, that looks really useful for arcane purposes:
# cp ~/longname.txt /really/a/very/long/path/long-filename.txt
# ls -l !cp:2
ls -l /really/a/very/long/path/long-filename.txt

Entitled “Lazy Linux: 10 essential tricks for admins“, this is a pretty good set of essential commands for *nix administrators.

If I have to suggest anything for in-depth study, it’s “Trick 6″: “Remote VNC session through an SSH tunnel”, because you can actually do just about anything through an SSH tunnel. If you’re faced with you -> firewall -> internet -> remotemachine -> internet -> restoftheworld, you can do whatever you like with “restof theworld” if you can ssh to “remotemachine”, whatever the local firewall thinks. And you can probably ssh over port 443 through the firewall. Hmm; maybe I should write this up properly at some point. I’m sure it’s well documented on the web if you look for it….

Network Theory have a Bash Quiz!

Out of the ten questions, one I’m not immediately sure of without checking; another I only happened to come across earlier today, and one (echo "\'")I got wrong

So, 7/10 really; 8/10 by good fortune of coming across the definition earlier today

A serious publisher has contacted me about writing a serious book about Linux shell programming.

It is all really very serious. I’m not used to being serious, as you can probably tell from the fact that I have now used the word “serious” four times in this three-sentence post.

I am rather keen to write a book on the subject, not because I’m vain, or desperate for money, but because the stuff I have seen out there in dead-tree format has been of rather low quality. Also because of all the emails I’ve received over the years, they have all been positive, and none has said anything along the lines of “I didn’t need any of that because I bought Book[X]“, or indeed any book. People have emailed me, asking for advice as to what book to buy, and I have been unable to recommend any book that I have seen.

So:

What would you like to see in your ideal book about UNIX / Linux shell scripting, be it Bourne, Bash, ksh, tcsh, zsh, whatever?

Please don’t be timid; if you want to know how to work out how many nose-flutes can be fitted into the area of a Boeing 757, you won’t be anything like as strange as some of the correspondants I’ve had over the years, so please, tell me what is bugging you, what has bugged you, or even what you think might be likely to bug you in days / months / years to come.

I’m likely to answer any specific questions here and now, whether or not they end up in the book, but anything you’d like to see in a book, too… post that here, and I’ll have a stab at it.

Also, I would of course be interested to know if you have found any useful books on or around the subject, and what they did particularly well.

Steve

This blog has now been running for a year; the first post was Hello World on 17th Jan 2007.

I hadn’t realised it had been going for so long; in that time, I’ve made 41 posts, so I haven’t quite managed to make one post per week I have been a bit slack lately, for which I do apologise. New Years Resolution: I must make more posts here!

In the meantime, my main site, steve-parker.org, has celebrated its seventh birthday, having been born in June 2000 – looking forward to making the 8th birthday celebrations this June!

There are lots of small little quirks to the *nix shells; this is just one of them.

If you want to list the files in a directory, then ls will list them all for you, in alphabetical order.

If you want to list them by size, you can use ls -S; by timestamp: ls -t, and so on.

But ls is a particular utility. What happens when we do this:


for myfile in *
do
  echo "My file is called $myfile"
done

We get an alphabetically sorted list (see man ascii for the actual detail; they’re sorted by ASCII value, so numbers first, then uppercase letters, then lowercase letters).

This can be a pain, but it can also be quite useful. If you’ve got a bunch of files:

1.install.txt
2.setup.txt
3.use.txt
4.uninstall.txt

Then you can play with them in order, just by using the asterisk:

for i in *
do
  echo "File $i" >> all.txt
  cat $i >> all.txt
done

And it will sort them into order for you (”1″ comes before “2″ in ASCII, and so on…)

Or you could just do this:

more * > all.txt

Because more will prefix each file with its name in a header, if there is more than one file to process.

http://snap.nlc.dcccd.edu/reference/bash1/features_29.html has a bash-specific technique for processing calculations:

$[ expression ]
$(( expression ))

See the link for further details.

It seems like an esoteric concept, but it’s actually very useful.

If your input file is “1 apple steve@example.com”, then your script could say:

while read qty product customer
do
  echo "${customer} wants ${qty} ${product}(s)"
done

The read command will read in the three variables, because they’re spaced out from each other.

However, critical data is often presented in spreadsheet format. If you save these as CSV files, it will come out like this:

1,apple,steve@example.com

This contains no spaces, and the above code will not be able to understand it. It will take the whole thing as one item – the first thing, quanity, $qty, and set the other two fields as blank.

The way around this, is to tell the entire shell, that “,” (the comma itself) separates fields; it’s the “internal field separator”, or IFS.

The IFS variable is set to space/tab/newline, which isn’t easy to set in the shell, so it’s best to save the original IFS to another variable, so you can put it back again after you’ve messed around with it. I tend to use “oIFS=$IFS” to save the current value into “oIFS”.

Also, when the IFS variable is set to something other than the default, it can really mess with other code.

Here’s a script I wrote today to parse a CSV file:

#!/bin/sh
oIFS=$IFS     # Always keep the original IFS!
IFS=","          # Now set it to what we want the "read" loop to use
while read qty product customer
do
  IFS=$oIFS
  # process the information
  IFS=","       # Put it back to the comma, for the loop to go around again
done < myfile.txt

It really is that easy, and it’s very versatile. You do have to be careful to keep a copy of the original (I always use the name oIFS, but whatever suits you), and to put it back as soon as possible, because so many things invisibly use the IFS – grep, cut, you name it. It’s surprising how many things within the “while read” loop actually did depend on the IFS being the default value.

Whilst not directly related to shell programming, understanding of basic logic operations – AND, OR, NOR, XOR, NAND, etc, are as important to shell programmers as to C, Java, .Net and other coders.

My recent interactive logic gate page seems to have become quite popular; it’s just a simple implementation of each of the major logic circuits in use. If you want to see more, say so – I’ll add anything you ask for

The (often a bit geeky for this blog) FreeBSD-World website has a good “Top-25″ list of 25 useful commands in Linux/UNIX for Beginners (note: new URL updated 31 Aug 2008)

I’m not sure that #24 (dig) and #25 (host) are absolutely necessary, #18 (startx) is possibly outdated these days, and the compression tools (6-9) are much of a muchness, but apart from that, #1 – #23 should be familiar to anyone who claims to be experienced with UNIX/Linux. If somebody was missing one, it would have to be #18 (startx), as (a) it’s not needed on servers, and (b) modern *nix distros will boot into a GUI automatically when possible.

So what’s the list?
25. host
24. dig
23. mkdir
22. rm
21. cp
20. grep
19. ls
18. startx
17. nano / vi
16. pwd
15. cat
14. man
13. kill
12. locate
11. ifconfig
10. ssh
9. gzip
8. bzip2
7. zip
6. tar (I would put 6-9 in one category, personally. rar should probably be in there too)
5. mount
4. passwd
3. ping
2. tail
1. top

I use vi every day; to me, there is no better text editor. It is apparently a little intimidating for the newcomer, though…. here’s a beginner’s guide to the VI editor.

I would write one of these, but – much as I love vi, and I really do, everyone who uses vi, seems to have their own experience of it, and their own shortcuts. We’ve all got our own quirks. One thing’s for sure; vi is not notepad!

Greg Wooledge has an excellent list of Bash Pitfalls, with good explanations as to why they are wrong, and what the correct syntax should be.

UNIX and Linux systems use “init scripts” – scripts typically placed in /etc/init.d/ which are run when the system starts up and shuts down (or changes runlevels, but we won’t go into that level of detail here, being more of a sysadmin topic than a shell scripting topic). In a typical setup, /etc/init.d/myservice is linked to /etc/rc2.d/S70myservice. That is to say, /etc/init.d/myservice is the real file, but the rc2.d file is a symbolic link to it, called "S70myservice". The “S” means “Start”, and “70″ says when it should be run – lower-numbered scripts are run first. The range is usually 1-99, but there are no rules. /etc/rc0.d/K30myservice (for shutdown), or /etc/rc6.d/K30myservice (for reboot; possibly a different scenario for some services), will be the corresponding “Kill” scripts. Again, you can control the order in which your services are shut down; K01* first, to K99* last.

All of these rc scripts are just symbolic links to /etc/init.d/myservice, so there is just one actual shell script, which takes care of starting or stopping the service. The Samba init script from Solaris is a nice and simple script to use as an example:

case "$1" in
start)
	[ -f /etc/sfw/smb.conf ] || exit 0

	/usr/sfw/sbin/smbd -D
	/usr/sfw/sbin/nmbd -D
	;;
stop)
	pkill smbd
	pkill nmdb
	;;
*)
	echo "Usage: $0 { start | stop }"
	exit 1
	;;
esac
exit 0

The init daemon, which controls init scripts, calls a startup script as "/etc/rc2.d/S70myservice start", and a shutdown script as "/etc/rc0.d/K30myservice stop". So we have to check the variable $1 to see what action we need to take. (See http://steve-parker.org/sh/variables2.shtml to read about what $1 means – in this case, it’s either “start” or “stop”).

So we use case (follow link for more detail) to see what we are required to do.

In this example, if it’s “start”, then it will run the three commands:

	[ -f /etc/sfw/smb.conf ] || exit 0
	/usr/sfw/sbin/smbd -D
	/usr/sfw/sbin/nmbd -D

Where line 1 checks that smb.conf exists; there is no point continuing if it doesn’t exist, just “exit 0″ (success) so the system continues booting as normal. Lines 2 and 3 start the two daemons required for Samba.

If it’s “stop”, then it will run these two commands:

	pkill smbd
	pkill nmdb

pkill means “Process Kill”, and it simply kills off the two processes started by the “start” option.

The "*)" construct catches any other uses, and simply replies that the correct syntax is to call it with either “start” or “stop” – nothing else will do. Some services allow for status reports, restarting, and so on. The one thing we do need to provide is “start”. Most services also have a “stop” function. All others are optional.

The simplest possible init script would be this, to control an Apache webserver:

#!/bin/sh
/usr/sbin/apachectl $1

Apache comes with a program called “apachectl” (or “apache2ctl”), which will take “stop” and “start” as arguments, and act accordingly. It will also take “restart”, “status”, “configtest”, and a few more options, but that one-line script would be enough to act as /etc/init.d/apache, with /etc/rc2.d/S90apache and /etc/rc0.d/K10apache linking to it. To be frank, even that is not necessary; you could just link /usr/sbin/apachectl into /etc/init.d/apache. In reality, it’s normally good to provide a few sanity-checks in addition to the basic stop/start functionality.

The vast majority of init scripts use the case command; around that, you can wrap all sorts of other things – most GNU/Linux distributions include a generic reporting script (typically /lib/lsb/init-functions – to report “OK” or “FAILED”), read in a config file (like the Samba example above), define functions for the more involved aspects of starting, stopping, or reporting on the status of the service, and so on.

Some (eg, SuSE) have an “INIT INFO” block, which may allow the init daemon a bit more control over the order in which services are started. Ubuntu’s Upstart is another; Solaris 10 uses pmf (Process Monitor Facility), which starts and stops processes, but also monitors them to check that they are running as expected.

After a good decade of stability, in 2007 the world of init scripts appears to be changing, potentially quite significantly. However, I’m not here to speculate on future developments, this post is just to document the stable interface which is init scripts. Even if other things change, the basic “start|stop” syntax is going to be with us for a long time to come. It is easy, but often important, to understand what is going on.

In closing, I will list the run-levels, and what each run-level provides:

0: Shut down the OS (without powering off the machine)
1, s, S: Single-User mode. Networking is not enabled.
2: Networking enabled (not NFS, Printers)
3: Normal operating mode (including NFS, Printers)
4: Not normally used
5: Shut down the OS and power off the machine
6: Reboot the OS.

Some GNU/Linux distributions change these definitions – in particular, Debian provides all network services at runlevel 2, not 3. Run-level 5 is also sometimes used to start the graphical (X) interface.

Pipes, piping, pipelines… whatever you call them, are very powerful – in fact, they are one of the core tenets of the philosophy behind UNIX (and therefore Linux). They are also, really, very simple, once you understand them. The way to understand them, is by playing with them, but if you don’t know what they do, you don’t know where to start… Catch-22!

So, here are some simple examples of how the pipe works.

Let’s see the code

$ grep steve /etc/passwd | cut -d: -f 6
/home/steve
$
What did this do? There are two UNIX commands there: grep and cut. The command “grep steve /etc/passwd” finds all lines in the file /etc/passwd which contain the text “steve” anywhere in the line. In my case, this has one result:
steve:x:1000:1000:Steve Parker,,,:/home/steve:/bin/bash
The second command, “cut -d: -f6” cuts the line by the delimiter (-d) of a colon (”:“), and gets field (-f) number 6. This is, in the /etc/passwd file, the home directory of the user.

So what? Show me some more

This is the main point of this article; once you’ve seen a few examples, it normally all becomes clear.

EG2

$ find . -type f -ls | cut -c14- | sort -n -k 5
rw-r--r--   1 steve    steve       28 Jul 22 01:41 ./hello.txt
rwxr-xr-x   1 steve    steve     6500 Jul 22 01:41 ./a/filefrag
rwxr-xr-x   1 steve    steve     8828 Jul 22 01:42 ./c/hostname
rwxr-xr-x   1 steve    steve    30848 Jul 22 01:42 ./c/ping
rwxr-xr-x   1 steve    steve    77652 Jul 22 01:42 ./b/find
rwxr-xr-x   1 steve    steve    77844 Jul 22 01:41 ./large
rwxr-xr-x   1 steve    steve    93944 Jul 22 01:41 ./a/cpio
rwxr-xr-x   1 steve    steve    96228 Jul 22 01:42 ./b/grep
$

What I did here, was three commands: “find . -type f -ls” finds regular files, and lists them in an “ls”-style format: permissions, owner, size, etc.
“cut -c14-” cuts out the first 14 characters, which mess up the formatting on this website (!), and aren’t very interesting.
“sort -n -k 5” does a numeric (-n) sort, on field 5 (-k5), which is the size of the file.
So this gives me a list of the files in this directory (and subdirectories), ordered by file size. That’s much more useful than “ls -lS“, which restricts itself to the current directory, but not subdirectories.

(As an aside, I have to admit that I only concocted this by trying to think of an example; it actually seems really useful, and worth making into an alias… I must do a post about “alias” some time!)

So how does it work?

This seems pretty straightforward: get lines containing “steve” from the input file (”grep steve /etc/passwd“), and get the sixth field (where fields are marked by colons) (”cut -d: -f6“). You can read the full command from left to right, and see what happens, in that order.

How does it really work?

EG1 Explained

There are some gotchas when you start to look at the plumbing. Because we’re using the analogy of a pipe (think of water flowing through a pipe), the OS actually sets up the commands in the reverse order. It calls cutfirst, then it calls grep. If you have (for example) a syntax error in your cut command, then grep will never be called.
What actually happens is this:

1. A “pipe” is set up – a special entity which can take input, which it passes, line by line, to its output.
2. cut is called, and its input is set to be the “pipe”.
3. grep is called, and its output is set to be the “pipe”.
4. As grep generates output, it is passed through the pipe, to the waiting cut command, which does its own simple task, of splitting the fields by colons, and selecting the 6th field as output.

EG2 Explained

For EG2, “sort” is called first, which ties to the second (rightmost) pipe for its input. Then “cut” is called, which ties to the second pipe for its output, and the first (leftmost) pipe for its input. Then, “find” is called, which ties to the first pipe for its output.
So, the output of “find” is piped into “cut“, which strips off the first 14 characters of the “find” output. This is then passed to “sort“, which sorts on field 5 (of what it receives as input), so the output of the entire pipeline, is a numerically sorted list of files, ordered by size.

There doesn’t seem to be any decent shell CheatSheet out there, so I have undertaken to write one.

This is my first attempt; once I actually printed it out, I realised that the the font was actually rather large, so I had room to include much more than I had originally sketched out.

Cheatsheet You may notice that there are a lot of blanks; Shell Cheatsheet has the same content, with some ideas for new content. Please tell me what you want to see in there – There is still lots of room, it’s only about 60% full.

What would you fill the other 40% with?

Does this seem to be a useful cribsheet? What would you like to see in it?

Also, what format would you prefer? PDF? PNG? GIF? DOC?!