Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
So I am new to Linux and a co-worker and I were discussing using ./ so that Linux knows to look in the current directory. My co-worker explained that you must use ./ to take away ambiguity and that is a better method than Windows. I feel this is pretty stupid because Linux should assume if I have navigated to a directory that it should know that I want to execute the file that is in that directory. Is there another reason for this? If not can you give me a good reason why I should have to use ./ ? What are your thoughts on this?
without wishing to sound too ridiculous, about the best reason is that's the way it is. new users seem to have this salmon like urge to fight against anything that doesn't immediately strike them as obvious. this makes life very hard for them, whereas if they initially accepted these sorts of things, and questioned them later, that later stage either never needs to arise or is a lot more valid when it does.
as for more pratical reasons, executable programs live in /usr/bin, /bin etc... and a command should be generally predictable wherever you run it from. if you stick your current directory into the path variable, then running a command may be different if you were to have your own "versions" of a command. e.g. you have /home/user/rm which is a test script you're messing about with. you run "rm file.txt" whilst in /tmp and the file /tmp/file.txt is deleted. you run that in your home directory and file.txt is sent as an email attachment to your ex girlfriend and your boss... stupid example of course, but it's much better to have this consistency, even if it is more long winded.
as above... don't fight it. if nothing else, it's very cliched!
My co-worker explained that you must use ./ to take away ambiguity
You may want to have another listen to your co-worker. He/she is correct is that it helps with ambiguity.
example. You have "executable" located at (/usr/bin/executable).
In /tmp/testEXE dir you have a test "executable" file. You want to compare how they both react when used.
First you test the original:
:/tmp/testEXE>executable <input>
BLAH BLAH ... something happens
Next test your new file:
:/tmp/testEXE>./executable <input>
blah blah.. something else happens
Now isn't that easier then comparing it this way:
:/tmp/testEXE>/usr/bin/executable <input> {file in $PATH but local file would mask it if in current dir}
:/tmp/testEXE>executable <input> {local file}
It's true that you should type ./cmd to access an executable in the current directory (as acid_kewpie said, the primary rationale is a slight security issue), but you don't *have* to. If you wish, you can append the current directory to your PATH (you can prepend it but this is even less wise). But what kind of a filesystem mess are you living in where you need that? Just create a personal bin directory and put *that* on your path and keep your shell scripts and whatnot there. Saves on './' and 'cd' typing.
I feel this is pretty stupid because Linux should assume if I have navigated to a directory that it should know that I want to execute the file that is in that directory.
So,
1. you think you know better than experts with 30 years of unix experience?
2. you expect a piece of software to be able to read your, ahem, "mind"?
I feel this is pretty stupid because Linux should assume if I have navigated to a directory that it should know that I want to execute the file that is in that directory. Is there another reason for this? If not can you give me a good reason why I should have to use ./ ? What are your thoughts on this?
It is really the opposite of your intuition....Linux looks in the PATH variable to see where executable files are located. You really do not want all executables located in your home directory. Look in /bin or /sbin or /usr/bin to see why.
When you DO have an executable in a directory not in PATH, then you have to disambiguate.
1. you think you know better than experts with 30 years of unix experience?
2. you expect a piece of software to be able to read your, ahem, "mind"?
Okaaaaaaaaaay.
I never said I knew better. Why are you taking such a smart @ss attitude?
To answer your question yes, I belive a computer should read my mind. Isn't it pretty obvious that if I navigate to a certain directory I want to run the file in that directory?? Also if people don't ask question and "accept" something just because it always been done that way then humans will never advance.
I do understand the security issue and that does make sense. Thanks for shedding some light on this.
Last edited by benchmarkman; 06-17-2007 at 05:17 PM.
To answer your question yes, I belive a computer should read my mind. Isn't it pretty obvious that if I navigate to a certain directory I want to run the file in that directory??
Why should that be obvious? Wanting to execute an executable located in a directory is not the most common reason for most users to cd into a directory, which is to operate on things in that directory using standard commands. Executing files in random directories is something developers do, and we know how to do it, either by prepending "./" to the command or by appending . to the path once and for all.
Why should that be obvious? Wanting to execute an executable located in a directory is not the most common reason for most users to cd into a directory, which is to operate on things in that directory using standard commands. Executing files in random directories is something developers do, and we know how to do it, either by prepending "./" to the command or by appending . to the path once and for all.
Amen....as a normal practice, you do NOT want all you executables to be in regularly used directories. That is why there is a PATH variable. Once that design decision is made, then there must be a means of executing a file in a directory that is not in PATH. I'm no a programmer, but I'd be willing to bet that tracking your movements thru the filesystem and somehow anticipating where you would want to run something----would be a bit of a chore....
Learning to type ./filename will surely be the easiest course of action.......
Amen....as a normal practice, you do NOT want all you executables to be in regularly used directories. That is why there is a PATH variable. Once that design decision is made, then there must be a means of executing a file in a directory that is not in PATH. I'm no a programmer, but I'd be willing to bet that tracking your movements thru the filesystem and somehow anticipating where you would want to run something----would be a bit of a chore....
Learning to type ./filename will surely be the easiest course of action.......
I guess I'm kind of lost, let me give an example. I install program x and install it in directory y. If I go to the directory y and type x, why should it not assume I want to run the file x in the current directory? What would be the point of me navigating to directory y if I didn't want to use that file?
I guess I'm kind of lost, let me give an example. I install program x and install it in directory y. If I go to the directory y and type x, why should it not assume I want to run the file x in the current directory? What would be the point of me navigating to directory y if I didn't want to use that file?
What you describe is not standard practice. When you install a program, it should normally go in one of the standard program directories, maybe like /usr/local/bin. The standard directories are probably part of your path by default, so you can then run the program simply by invoking its name. The point of working in a directory is usually to examine or modify files in that directory, not to execute programs contained therein.
An example of standard usage: I have a directory, ~/documents/pictures, with a bunch of pictures, say 1.jpg, 2.jpg, .... To display those pictures, I can switch to that directory (cd ~/documents/pictures) and display them with, for example, eog 1.jpg, eog 2.jpg, .... If I weren't in that directory, I would have to qualify the filenames, like eog ~/documents/pictures/1.jpg, so it's more convenient to be in the directory.
What you describe is not standard practice. When you install a program, it should normally go in one of the standard program directories, maybe like /usr/local/bin. The standard directories are probably part of your path by default, so you can then run the program simply by invoking its name. The point of working in a directory is usually to examine or modify files in that directory, not to execute programs contained therein.
An example of standard usage: I have a directory, ~/documents/pictures, with a bunch of pictures, say 1.jpg, 2.jpg, .... To display those pictures, I can switch to that directory (cd ~/documents/pictures) and display them with, for example, eog 1.jpg, eog 2.jpg, .... If I weren't in that directory, I would have to qualify the filenames, like eog ~/documents/pictures/1.jpg, so it's more convenient to be in the directory.
So if I understand you correctly, unlike Windows, all your installed executable files go into a single directory?
not a single directory, but generally few, based on what their role is... /bin, /sbin, /usr/bin etc... the closest you'll get to "program files" is /opt/ where specific large programs will be more privately placed away from the generic infrastructure. most things are in the usual places though
So if I understand you correctly, unlike Windows, all your installed executable files go into a single directory?
Also what is eog?
Eye of Gnome--a picture viewer.
To the main topic:
No, as with Windows, you can put executable files where-ever you want. There are a few conventions, but they are not requirements.
The whole point of this discussion is that Linux has a convention in which most executables are in just a few directories. It has a standard mechanism for finding the executables---ie the PATH variable. This is why you don't type /usr/bin/myprogram every time you want to run something. (Or, more absurdly, /bin/ls every time you want to list the current directory.)
The beauty of Linux is you can set it up any way you want....e.g.:
1.Put ALL the executables in your home directory (get rid of PATH). Now just remember anytime you are NOT at home, type ~/program to run something.
2.Get rid of PATH and just remember where all executables are so you can type the right path.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.