UNIX for Dummies Questions & Answers

Hi!
If your working directory contains a file you want to work on, or give as an argument, you don't have to give the explicit pathname, just the filename, like so:

Code:

$ vi while_loop.ksh

But if you want execute an executable file, you must supply the explicate pathname, like so:

Code:

./while_loop.ksh

Because, of course, this won't work:

Code:

$ until_loop.ksh
-bash: while_loop.ksh: command not found

Obviously, the shell is telling a lie. But why?

I think the reason is because current directory is missing in the PATH variable value. Add current directory and retry:-

Code:

export PATH="$PATH:."

That is a terrible idea. Never put relative paths inside your PATH. At best it's a security risk, at worst, it will cause things to actually fail. The shell tries to cache what programs are available when it runs, but this will not work right when things in PATH are relative. Everything inside PATH must be an absolute path!

Second, there's a reason the current directory is not included for running executables. It's not "missing", it's on purpose. It's to prevent people from dumping malign files into a folder you frequent and having you accidentally run them.

If you want to add your own scripts to the PATH, put them in /home/myusername/bin and add /home/myusername/bin to your PATH.

Corona688,
I have a question: I do not have current directory added to my PATH, but still I am able to run scripts without specifying absolute path in HP-UX & KSH

Code:

# uname
HP-UX
# echo $SHELL
/usr/bin/ksh

But this is not the case with Linux & BASH:-

Code:

# uname
Linux
# echo $SHELL
/bin/bash

Why is this behavior? Is this something to do with the UNIX shell?

Ok, I kinda get that it might be about having executables in permissions protected directories, but if all you need to do is use the absolute pathname, it doesn't seem like much security. Especially if it's just a dot-slash. Of course, it forces you to make sure executing it is what you want to do.
So you guys think that's what the deal is?

---------- Post updated at 11:42 PM ---------- Previous update was at 11:41 PM ----------

I have no need to put these practice scripts I'm doing in my PATH. It's not an issue - just something I was wondering about. If I ever write something useful, I'll stick it in /usr/local/bin

I should have mentioned - I'm running Mac OS, bash shell.

In fact it is: directories where (system) binaries are stored, like "/usr/bin", are writable only for root (and probably for a very select group of other system users). This means that only root can change the contents of the directory. As normal work never happens under root (at least this should be so) normal users and their processes can only use what is in there and not modify it.

Suppose the following: you use "/usr/bin/ls" by typing just "ls" because your PATH contains "/usr/bin". Now i write a program which erases everything in your HOME directory. I couldn't run that program, because the system would not let me. Therefore i place it somewhere and name it "ls". Because you have "." in your path once you enter the directory where this program file is and type "ls", this is executed instead of "/usr/bin/ls" and now you are requesting your HOME directory to be deleted - what the program now is allowed, because it runs under your ID. Mission accomplished.

In fact this makes for an awful lot of security if you do not use root for your daily work, just for system administration purposes) and do your normal work (like surfing the web, etc.) only under your user-ID.

This is a good idea and very very close to what the expert way is. An even better idea would be to: make /usr/local/bin writable only by root. Put in there only things you want to use with all the users on the system. Create a directory $HOME/bin, which will be writable only by you. Put all the scripts which are only for your use there. This is the most canonical way of doing this. Don't forget Unix is truly a multi-user system (unlike Windoze, which is implicitly single-user, even in modern versions. The multi-user-feature is obviously "tinkered on second thoughts".) and you should separate things needed only by you and things needed for everyone on the system - even if it is your own system and nobody else will ever use it.

I hope this helps.

bakunin

I should have been a bit more specific. What I meant here, we were speaking of an executable that would be sitting somewhere outside of my PATH, in my working directory, needing the explicit pathname to execute. I was wondering why I have to type that dot-slash to execute something in my working directory, when it's not needed to give the same file as an argument to a command.
The thing that surprises me, is that bash says "command not found," when it had no trouble finding the file only a moment before.
If I may borrow from your example, someone who gained access to my account might look around and see the little innocuous scripts I'm writing, replace one of them with your malicious script, giving it the same name as one of mine. There's nothing stopping me from executing it, except typing dot-slash.
In that sense, I don't see how having to type the explicit path for executables in my working directory, (dot-slash), gives anymore real security than not having to. Is there a reason one has to do that to execute a file?

It looks like it's already set up like that. Well, wheel can write. That's root and admin, right? I know I have to authenticate to write to it.

Code:

$ ls -l /usr/local |grep [^s]bin
drwxrwxr-x  50 root  wheel  1700 Nov 17 16:08 bin