ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
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.
Distribution: RPM Distros,Mostly Mandrake Forks;Drake Tools/Utilities all the way!GO MAGEIA!!!
Posts: 986
Rep:
Is the "./" statement just a throwback?
If I'm in a directory and I want to move into the next directory I just type it in raw without the relative ./ All I use is cd "next directory" enter. So my point is that I can not find a purpose for the "./" statement other than to state it on paper ;or the like as , ./directory/directory (from whatever current directory) I was in. Is the "./" statement for an older version of BASH?
Is this correct? Thanks in advance!
Click here to see the post LQ members have rated as the most helpful post in this thread.
You will need to use "./" to precede a program you want to run in the current directory. "./" isn't a statement. You are simply giving the current directory "." at the start. Both ways end up having the same meaning, that's all.
To expand just a little bit on jschiwal's point, consider the following.
One Unix tradition is to add "." to $PATH so that shell scripts may be run from the current working directory. On all the Ubuntu systems I have used "." is not in $PATH by default. So when I want to run a shell script from the current working directory I cannot just write
Distribution: RPM Distros,Mostly Mandrake Forks;Drake Tools/Utilities all the way!GO MAGEIA!!!
Posts: 986
Original Poster
Rep:
Thanks for the replies!
I refered to it "./" as a statement because I did'nt know what else to call it."Piece of garbage with no explanation". I Still can't find a use for it. Apparently I understand the description as well as anyone else but If BASH is in a directory It is redundant to use it because it will change from that directory to the next without using it.
cd /home/kbs -while in home is the same as
cd kbs
"kbs@localhost ~]$ cd /home/kbs
[kbs@localhost ~]$ pwd
/home/kbs
[kbs@localhost ~]$ cd Documents
[kbs@localhost Documents]$ pwd
/home/kbs/Documents
[kbs@localhost Documents]$"
If not in home (or the known beginning of the directory) than you can't use a relative path so what is the point? Bash knows where it is without the "./" it would seem.
Last edited by theKbStockpiler; 03-05-2011 at 11:44 PM.
I think what you're talking about is applicable to just about any Linux/UNIX-like system, not just Ubuntu...I can't think of any instance where I've been able to run an executable in the current working directory (be it a shell script/binary/whatever) just by providing its filename alone; I've always had to precede it with the "./" shortcut for "current directory".
EDIT:
Quote:
cd /home/kbs -while in home is the same as
cd /kbs
Actually, no, these aren't equivalent, even if you're already in /home. There is a shortcut for /home/$(whoami), though: you might already know it as "~".
"cd /kbs" will make bash attempt to switch to a directory called "kbs" from the root of the filesystem.
AFAIK the way running executables without providing their full path or "./" works is that bash checks for the existence of the file in the director(y|ies) pointed to by $PATH, and if it's not there, it gives a "command not found" (or in some cases, "<executable>: No such file or directory") error.
To anyone who knows better: feel free to correct me.
Any command which takes a path will probably accept a relative path, which effectively means there is an implicit "./" prepended to the path by default. Using "./" just makes it explicit. Note that this is a feature of open(2) system call, so it is not a bash thing, but a Linux thing.
@Telengard
I think what you're talking about is applicable to just about any Linux/UNIX-like system, not just Ubuntu...
I'm informed by a couple of sources. My primary source is my own experiences on Debian, Ubuntu, Slackware, Red Hat, and Fedora. Not all of those systems were mine to administer, so I don't know whether the admin changed the default settings or not. The Red Hat system in particular used some variant of traditional sh, and not Bash.
My other source of information is The UNIX Programming Environment by Kernighan and Pike. They mention adding "." to $PATH for convenience early in the book. It is a fine read by the way. Even though some of the examples are steeped in archaic Unix-isms, Linux CLI newbies can learn a great deal from it.
I'm informed by a couple of sources. My primary source is my own experiences on Debian, Ubuntu, Slackware, Red Hat, and Fedora. Not all of those systems were mine to administer, so I don't know whether the admin changed the default settings or not. The Red Hat system in particular used some variant of traditional sh, and not Bash.
I was just talking about WRT the whole "./" syntax, not necessarily adding "." to $PATH, but thanks for the info anyway.
EDIT: One interesting idiosyncrasy(?) that I've noticed is that one can directly execute a binary/shell script that exists within a subdirectory of the CWD by referring to it relative to the current working directory (i.e. without having to use "./"). For example, if one has a script in /home/joe/Scripts/something.sh, and the're currently in /home/joe, they can simply execute the script like this:
They really don't include enough info to grasp it. I remember ./configure and know it won't work without it but I think it is NOT completely part of the same thing. It is still part of the purpose of this thread. If you don't want to permanently modify the search path you have to include the "./" . If you modify it you don't have to include the "./" . It's just like opening up gedit in bash without typing "./" before it I think. A lot of these guides and tutorials heavily borrow from other guides and tutorials and I think some stuff gets outdated and no one gives it any mind. Java is not working. Imagine an emotioncon of your choice "here".
Any command which takes a path will probably accept a relative path, which effectively means there is an implicit "./" prepended to the path by default. Using "./" just makes it explicit. Note that this is a feature of open(2) system call, so it is not a bash thing, but a Linux thing.
EDIT: One interesting idiosyncrasy(?) that I've noticed is that one can directly execute a binary/shell script that exists within a subdirectory of the CWD by referring to it relative to the current working directory (i.e. without having to use "./"). For example, if one has a script in /home/joe/Scripts/something.sh, and the're currently in /home/joe, they can simply execute the script like this:
Code:
$ Scripts/something.sh
Yes, there is nothing special about "./", it's just a way to specify a file current in the current directory using a slash:
Quote:
If the name is neither a shell function nor a builtin, and contains no slashes, Bash searches each element of $PATH for a directory containing an executable file by that name.
That explains things pretty well, except that it has one incorrect statement:
Quote:
When you input the path yourself (either a command or a file) The shell interprets each component of a pathname before passing it to the appropriate command.
There is no expansion of pathname components by the shell, as I said before this is a feature of the open() system call (and other calls that take paths), not bash. See path_resolution(2)
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.