UNIX for Dummies Questions & Answers

No, I didn't know that. Do you mean, "in the then and else branches"? Although I've read that fi is simply if backwards, I've always read it as finish. You know, like, it's the end. I'm still not entirely clear on how these commands, or arguments, or whatever they're called, work.
But you're saying that I could could just put a single instance of find, or whatever command, after fi, and it'll execute no matter what happens above it? Yeah, ok, I can see that now.

I should also mention that I simply forgot to delete ls ~/$dir, which I intended to do. I like the output of find better, because prints only the path on one line, as opposed to what I was getting, or hoping to get, from ls.

No, you're right, especially if we try to make something that might actually be useful. I'm thinking it's possible in many cases that a variable could be handed some white spaces. Do you think it's a good idea to always quote variables, as a matter of course?

Right! Again, something I hadn't considered. I tried it, and as you suggest, it did not work. Adding the -p flag fixes it.

While I did not try this - at least, not yet - I wonder if cd .. would always work, since it only takes you up one level? For instance, if you had empty directory /Fun, then specified, say, a new directory four levels down: /Fun/X1/X2/X3 Wouldn't cd .. only position you, (and ls), at /X2?

Yes, absolutely. There are a very few occasions where not quoting has some desired effect and it not done. In the overwhelming majority of cases quoting has no bad effect at all and probably/perhaps a good effect. Quoting routinely is good by far more often than not.


This is called "defensive scripting" and is generally a good state of mind: once you know what you want and basically how you want it to be done you begin to wonder how the procedure you intend to use could fail for various reasons. Then you start to take care of these reasons one by one.

Here is a real-life example from my practice: i once wrote a script-function which created space for temporary files. Basically this is a simple task: create a directory. Now i asked myself: how could this fail? The following list could easily be prolonged:

What i finally wrote was about 50 lines of code, which still basically did a "mkdir" - the rest was error checking or error reporting. But first it is a good thing to actually know why a script failed, instead of it just crashing and second, some of my scripts had to run on a world-wide installation base, close to 20.000 machines. Guess what, all of the paranoid ideas i came up with about what could go wrong - did go wrong on at least one system! Still, some systems easily exceed even your worst nightmare and some reasons for the script failing didn't even occur to me and were nevertheless happening. Go figure.

Exactly this is the case. Your home directory is perhaps "/home/sudont", so position yourself there and issue "ls -l .." - and you will get a listing of all the files/directories in "/home". Do a "ls -l ../.." and you will get the same for "/". This only fails if you try to go beyond the root directory "/" - for obvious reasons. Btw., these rules are the same for every command which takes a path as an argument: for "ls", "cd", "find", ... Every time ".." means the directory one level up from where you are now and "." means the directory you are right now. "Where you are now" is either your current working directory, PWD (the place you "stand at" in the filesystem), or a place the path you just enter is leading to: write "cd /foo/bar" and you will be taken to "/foo/bar", but writing "cd /foo/bar/./." has the same effect - it is like adding zero to a number: not changing anything.

Or write "cd /foo/bar/.." - this will take you to "/foo" (and is a very complicated way of getting there), because from "/foo/bar" one level up is "/foo".

I hope this helps.

bakunin

As always, very informative. Thanks!
"Defensive scripting" - I like that.

If I may, one more question: When the shell sees fi, does it mean, "quit considering the original question, the if? In the case of my script:

Code:

[[ ! -d ~/$dir ]]

This is what I gather from what you told me about putting a single instance of ls or find outside/below fi. I had thought fi meant, "this is the end of the script, stop working". Or as the French say, "fin." The book doesn't really explain that, at least, it hasn't yet.

Not quite. "fi" is indeed "if" spelled backwards (you will later learn a construct called "case" which ends with "esac") and it ends only the fi-clause, nothing else. Cosider the following (pseudo)-code:

Code:

command1
if [ some expression ] ; then
     command2
else
     command3
fi
command4

Control flow would be: execute command1 first. Then, if the condition in "expression" is met, execute command2, if not, execute command3. Regardless of the condition being met or not execute command4 then. Consider "if" and "fi" like a braces between to put something.

I hope this helps.

bakunin