Quote:
Originally Posted by
sudon't
Do you think it's a good idea to always quote variables, as a matter of course?
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.
Quote:
Right! Again, something I hadn't considered. I tried it, and as you suggest, it did not work. Adding the -p flag fixes it.
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:
- the desired directory already exists. Solution: make sure you create a directory with a name guaranteed to be unique.
- The script has no write-access to the place where the directory is to be created - issue an error message.
- The directory cannot be created because of no inode being available - issue a different error message.
- The directory can be created but the available space in the filesystem is not big enough to hold the temporary files - issue yet another error message.
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.
Quote:
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?
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