One thing I have noticed about this blog is that shell scripts are _very_ difficult to make look nice. I am not sure if that is a Blogger problem, or an issue with this template. Either way, I don't like mucking around with the way things look. I want to get my ideas down and not have to be constantly tweaking the text formatting.
Anyway, after monkeying around for a while with the shell script on the previous post, I decided to search for a script beautifier, along the lines of GNU indent, but for shell scripts. Eventually, I came across a ruby script, written by Paul Lutus, and aptly named Bash Script Beautifier. So far, it has worked very well for me.
As always, utilities such as this one may not work exactly the way you want. You would do well to make a backup copy of your script before you run it through the beautifier. Also, be sure to read the documentation on the download page. You can read all about it, and download the script here.
Thursday, January 14, 2010
Tuesday, January 12, 2010
Optimizing your shell scripts
A few days ago I came across a couple of posts, by Brock Noland, (blog site is dead now) about splitting strings natively with the shell. You can find them here here (Internet archive) and here here. Basically, the writer demonstrated that using shell builtins and variables is much more desirable than using outside programs, such as cut and awk for the same purpose. The reason for this is due to speed. Every time you make a call to an outside program with the shell, you fork a new process, and that takes time.
I decided to tinker with this idea a bit more, to get a better impression of how much slower using cut and awk really is. I made each of the following functions iterate 100 times. I am pretty sure some of you will be shocked by the speed difference between cut and awk, versus the shell native string splitting.
I decided to tinker with this idea a bit more, to get a better impression of how much slower using cut and awk really is. I made each of the following functions iterate 100 times. I am pretty sure some of you will be shocked by the speed difference between cut and awk, versus the shell native string splitting.
Monday, December 28, 2009
Using pushd, popd and dirs
Since I have a bit of time on my hands, I thought I might share a trick or two. Well, not really 'tricks,' but good information to know. I will cover the shell builtins, pushd, popd, and dirs for bash and zsh. Additionally, I will demonstrate how to use some shell aliases, in order to make the use of these handy builtins even more convenient, and time saving.
Monday, December 21, 2009
How to delete the 'Desktop' folder in Gnome...
...and not have the contents of your home directory displayed on your desktop.
Maybe its just me, but I really don't like the way that a fresh Gnome install sets up a user's home directory with a bunch of empty directories, like 'Video', 'Documents', and the totally evil 'Desktop' folder. If you are like me, you want to decide what is in the home folder, which does not include all the extra directories they offer. A reasonable person would expect that the quick and easy solution would be to delete the unwanted directories, but not so fast my friend. All of the directories can be safely deleted, but one. If you remove the 'Desktop' folder, you will end up with all the contents of your home directory (not including hidden files) displayed on your desktop. Of course fixing your 'mistake' of deleting the Desktop folder is not as easy as doing a
No no, the wonderful people at Gnome must have thought that would be too easy. No, first you must search around on the internet and find a post like this one. Then you have to fire up your editor and do some editing, as well as replacing the folder 'Desktop.' Then all will be well. Except for the fact that your home directory still has a folder in it that YOU DON'T WANT!!!1!
Anyway, the solution is pretty simple.
Maybe its just me, but I really don't like the way that a fresh Gnome install sets up a user's home directory with a bunch of empty directories, like 'Video', 'Documents', and the totally evil 'Desktop' folder. If you are like me, you want to decide what is in the home folder, which does not include all the extra directories they offer. A reasonable person would expect that the quick and easy solution would be to delete the unwanted directories, but not so fast my friend. All of the directories can be safely deleted, but one. If you remove the 'Desktop' folder, you will end up with all the contents of your home directory (not including hidden files) displayed on your desktop. Of course fixing your 'mistake' of deleting the Desktop folder is not as easy as doing a
mkdir ~/DesktopNo no, the wonderful people at Gnome must have thought that would be too easy. No, first you must search around on the internet and find a post like this one. Then you have to fire up your editor and do some editing, as well as replacing the folder 'Desktop.' Then all will be well. Except for the fact that your home directory still has a folder in it that YOU DON'T WANT!!!1!
Anyway, the solution is pretty simple.
Friday, December 18, 2009
ps headers and grep
GNU ps(1) has a plethora of options. One of the more useful features of ps is the header label which is printed at the top of the ps output, such as in the following snippet:
Listing 1.1
As you can see, each column has a label on the top. In this example (Listing 1.1), the columns are labelled PID, TTY, TIME and CMD. This is the most basic invocation of the ps command, and the output is minimal. If you start adding options, such as doing ps aux, (where you will get you a listing of all the processes on the system using BSD style syntax) you will get quite a bit more text to sift through. But what if you are only after a certain term, such as tty, for example in the ps aux listing?
Listing 1.1
char $ ps
PID TTY TIME CMD
15705 pts/1 00:00:00 bash
16345 pts/1 00:00:00 ps
As you can see, each column has a label on the top. In this example (Listing 1.1), the columns are labelled PID, TTY, TIME and CMD. This is the most basic invocation of the ps command, and the output is minimal. If you start adding options, such as doing ps aux, (where you will get you a listing of all the processes on the system using BSD style syntax) you will get quite a bit more text to sift through. But what if you are only after a certain term, such as tty, for example in the ps aux listing?
Tuesday, August 4, 2009
Find gotcha
Not too sure if I can call this a bonafide 'gotcha,' but it is something to keep in mind.
It is a good idea to occasionally check your Unix system for orphaned files. Normally you do so by using find with the -nouser and -nogroup filters. You could do two separate searches, one for -nouser, and then one for -nogroup, but typically the two are combined in one find command. Now here is the gotcha:
It is a good idea to occasionally check your Unix system for orphaned files. Normally you do so by using find with the -nouser and -nogroup filters. You could do two separate searches, one for -nouser, and then one for -nogroup, but typically the two are combined in one find command. Now here is the gotcha:
find / -nouser -nogroup -printIf you search find "-nouser -nogroup" on Google you likely find some examples like the one above. The problem with it is that there is an implied and when two or more filters are used as in the example. It is the same as doing the following (explicitly):
or:
The examples above will only 'find' files that belong to 'nouser' and 'nogroup.' If a file matches -nouser, but not -nogroup, find will not display it. If a file exists that matches -nogroup, but not -nouser, it will not display. Find will only return results that meet both criteria. In order to find all orphaned files, you want to do an or:
Now go have some fun tracking down those orphaned files!
find / -nouser -a -nogroup -printor:
find / -nouser -and -nogroup -printThe examples above will only 'find' files that belong to 'nouser' and 'nogroup.' If a file matches -nouser, but not -nogroup, find will not display it. If a file exists that matches -nogroup, but not -nouser, it will not display. Find will only return results that meet both criteria. In order to find all orphaned files, you want to do an or:
find / -nouser -o -nogroup -printNow go have some fun tracking down those orphaned files!
Monday, August 3, 2009
Getting rid of troublesome files with GNU find.
Ok, so this isn't that much of a problem these days for those who are running a GUI, but what about when X isn't available? Consider the following:
I got that file by doing:
Now try and issue the rm command on the file -pesky and you will find that it doesn't work so well. What can you do? Well, you can do what Bash tells you, and do:
Or if you read the man page for rm, you would know that you can also do:
But there is another interesting way to do this operation, and it will work with other kinds of problematic, persistent files as well. We will use find to nuke the file. First, you need to find the inode number of the file, by using ls with the -i flag:
In this case, the inode number is 8339920. Now we can tell find to find the file with that number. Once it finds it, we can -exec /bin/rm -f and remove it:
kermit@fastbox ~/tmp/work2 $ ls -l
total 4
-rw-r--r-- 1 kermit kermit 37 2009-08-03 21:04 -pesky
I got that file by doing:
kermit@fastbox ~/tmp/work2 $ echo "Haha, sucker"\! "Try and get rid of me"\! > -pesky
Now try and issue the rm command on the file -pesky and you will find that it doesn't work so well. What can you do? Well, you can do what Bash tells you, and do:
kermit@fastbox ~/tmp/work2 $ rm -f ./-pesky
Or if you read the man page for rm, you would know that you can also do:
kermit@fastbox ~/tmp/work2 $ rm -f -- -pesky #The '--' tells the shell there are no more options following.
But there is another interesting way to do this operation, and it will work with other kinds of problematic, persistent files as well. We will use find to nuke the file. First, you need to find the inode number of the file, by using ls with the -i flag:
kermit@fastbox ~/tmp/work2 $ ls -li
total 4
8339920 -rw-r--r-- 1 kermit kermit 37 2009-08-03 20:57 -pesky
In this case, the inode number is 8339920. Now we can tell find to find the file with that number. Once it finds it, we can -exec /bin/rm -f and remove it:
kermit@fastbox ~/tmp/work2 $ find . -inum 8339920 -exec /bin/rm -f {} \;
kermit@fastbox ~/tmp/work2 $ ls -l
total 0
Subscribe to:
Posts (Atom)