UNIX for Dummies Questions & Answers

About " . ":
If you are a ordinary user or you can afford adding . in your $PATH (and understand its possible consequences...) at the condition its at the end of your PATH variable ( for security reason already mentionned ), if you were a developper you would I imagine create a bin directory in your $HOME and add that to your PATH variable instead, avoiding like that the risk of being spoofed...
About /usr/local/bin: Trust what the mods above already mentionned, since /usr/local/bin is set in PATH by default on most systems, it is not a good idea at all to let people other than root add new programs..., I for instance dont even trust the content.. and so remove /usr/local/bin from my PATH, and if I need a program that is there I check before its content.. You can always use aliases to your executable with fancy long absolute paths...

I saw a hole production fail for 5 weeks because someone not listening to what I said add . at the beginning of PATH in /etc/profile...
The side effects can be disastrous...

You're missing the point. If you just type 'mycommand' and hit enter, you won't run something that's been maliciously dumped in a local directory by accident.

You can still do so with ./ but it will be hard to claim you did so by accident.

I think people are misunderstanding my question, or I haven't been clear enough. (Or possibly I've misunderstood your answers?) Please forgive my ignorance, I was only wondering why, when you are in the same directory as a file, (not only executables), to access it, you only need its name.

Code:

$ anycommand any_execfile
$ anycommand any_file

But to execute a file, you must add dot-slash.

Code:

$ ./any_execfile

In other words, why doesn't simply typing the name and hitting <ENTER> work?

Code:

$ any_execfile
-bash command not found

Is it perhaps that using the pathname just indicates to the system that execution is your intention? Or that it forces you to do something extra, so you know you are executing something? Yes, that makes sense.


As a side note, I do understand what all of you have been telling me - that executables belong in protected directories, and all the very good reasons for that. I also understand why you encourage me to follow canonical unix protocols - someday I may working on something other than my own Macbook - maybe even a shell account accessed from my own Macbook at home. One should develop good habits.

---------- Post updated at 11:04 AM ---------- Previous update was at 10:54 AM ----------

Yes, this is what I was wondering about - the reason it's done this way, is simply that it forces you to realize what you are doing?

Adding a relative directory into your PATH can have problems beyond the obvious.

Many shells cache a list of available commands they find in PATH. Put a relative directory in there, and they may not always find all available commands because they don't know the cache needs to be regenerated every time you cd. Some may even crash if you put a relative directory in PATH.

That's a reason, but not the reason. The entire system uses PATH, not just you. This restriction gets rid of many unpredictable, unintended consequences.

The number of problems this could cause are potentially unlimited. It's not one specific problem, but a whole class of them. Imagine running commandname from your crontab, carelessly creating another file named commandname in your home directory to document what you've done, and seeing your cron log fill up with 'permission denied' for no reason you can explain -- because cron's trying to run your text document instead of /bin/commandname.

Having defined places where commands belong solves quite a lot.

P.S. It's not really the same issue as creating a new file. When you think about it, creating files is actually a lot more strict. It creates files in the current directory and only the current directory unless you force anything else. You wouldn't want 'nano bash' to open /bin/bash, after all. So running files, and creating files, are entirely separate things.

So running files, and creating files, are entirely separate things. UNIX likes to keep things separate like that. It can keep data and executables as far apart as different partitions for safety so you, out-of-control programs, malicious network worms, random disk corruption, and other nasties do as little damage as possible when they happen.

My situation is a little different. I'm just learning about unix and shell scripting at home on my Mac. Since the scripts I'm writing are useless except to learn how they work, I will never add them to my PATH. It's also rare that anyone else uses my computer. So it's convenient to write them in a sub-directory of my home directory, where I can execute them immediately after writing them, just to see that they work, and immediately go back to edit them. It's no problem to prepend dot-slash, and no need to alter my current PATH. I didn't see this as a problem, but because I'm a newb, things are not always obvious to me, and I wonder why some things are the way they are.