I was reading in the book Beginning Linux Programming about the directories that are listed with PATH that :. means bash will look in the current directory. When I echo PATH on my system :. is not part of any paths in it, however I have no problem running my various little "hello world" programs in the current directories that I work in. I am wondering if this is perhaps because the book I'm reading may be a little out of date and the current versions of bash simply automatically look in current directories. If that is so, is it possible to to put something in the PATH variable that omits looking in the current directory(not that I want to but it would be interesting to know). Thanks for anyone willing to comment on this.

As far as I know, the current directory must be in your PATH if you want to run commands without specifying the relative or absolute path of the command itself. If I want to run a command in my current directory I have to type
Anyway, there is a chance you have a colon : at the beginning or at the end of your PATH. In that case it includes the current working directory in your PATH. Check it and eventually find out where the erroneous colon has been added.

Bash doesn't include . in the path by default, at least vanilla bash doesn't (of course I can't speak for any odd patches that your distro might include).

colucix said the rest. If you use a standard -unpatched- bash, then you either need to have . in your path or use ./ prefixed to the name of the program that lives in the current directory.

Thanks guys for answering, it cleared up a misconception I was having. For some reason I picked up along the way that the dot " . " was a bash command telling it to execute the file name that follows. So all along I was using ./ to execute my programs in the current directory but misinterpreting what it means.

To test that idea I tried running my program without the ./ prefix and nothing happened, then I added :. to my PATH and when I typed my program name without the ./ prefix name it did run.

So I guess bash will try to run anything you type as long as its been told where to look.

Which brings the question to mind of scripts vs. compiled programs. I haven't done any script writing so this may not be a fair question since I have no concrete examples but from what I understand you can run compiled programs or scripted programs; and if all I need to do is just provide the name of the program and where to look for it, how does bash know to differentiate between a script and a compiled program?

Like with ms windows you would have .exe and whatever for something else. Perhaps I should just research scripting in Linux and come back later to ask if I don't find out.

But thanks again for answering my first question.

This is another story. The dot by itself is a bash built-in equivalent to source. You can do
to source the script, whereas
executes the script. The difference is that when you source a script, all the instructions inside it are executed in the current shell and if some environment variable is set, it is preserved as far as you exit from the shell session. In other word, to source a script is equivalent to execute its statements directly from the command line.

On the contrary, when you execute a script you start a child process and all the variables are local to that process and are not inherited by the current parent shell. Eventually they can be inherited from the children of the child (using export) but can't be passed backward to the parents.

Usually the type of a file is retrieved by the content of the first bytes (the header of the file). You can find more information regarding this topic if you look at the manual page of the file command:

Thank you very much Colucix for that answer. Definitely very useful and informative; will have to play around with some stuff using those thoughts so it sticks to memory.

Exactly. "./" is what we call a relative path. It means "from the current directory". You could also specify the whole path, or do "$PWD/my_script.sh". since $PWD will always contain the full path to the current directory.

The magic bytes at the beginning of every file tells the shell what to do. Technically the shell is the first to reach at file you want to run. It can identify the type of file based on the contents. If the file is a text file then it tries to run it as a script. If the file starts with the sequence "#!" then the next string is used as the interpreter that must be used to open the file,

Or whatever... This code doesn't interfere with the script because -out of casuality -, the lines starts with #, which is considered a commentary marker

Win relies on file extensions for this, linux doesn't need to. You can start researching with the "file" command for example. If will use the magic info inside the file to recognize the file type, and it should ignore the extension as long as the file is of a known type and is not corrupt.

Thank you too i92guboj ,
yes I'll have to read the man on file