Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
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.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
I do not know about the problem with the permissions, but if you want to run programs in the current directory you have to modify your PATH variable and add ":." at the end. If you use bash as shell, then modify your .bashrc. Notice however that you do not want to do this for the root user, as it could be a security threat.
Ok, I know it's annoying but it's a basic security measure. By having you type "./" in front of any program in the current dir, you can be sure no one can trick you into running a fake system command (eg, a modified 'ls' executable in your $HOME). That's why "." is not in the PATH by default.
Doesn't the order in which the path is searched prevent the malicious "ls" from being executed, since the real "ls" command is found first? Just wondering.
Also, I have tested on my system with two instances of the same c program, called "ls" and "ls.bin" respectively (both only printing "hi" and then quiting). Typing "ls.bin" ran the program fine, but with "ls" it only worked by typing "./ls"
So it appears that on my system I can only run programs in this way that have an extension (like .exe, or .bin, or .abighairylamawithpurpledots), maybe it is the same with other systems.
That is what I thought too, which is why I literally tried the silly extension and it worked!
If I rename both files to "test.bladiebla" and "test", then "test.bladiebla" executes without "./"
However, "test" still requires the "./" even though the permissions on both programs are the same. And yet I do not get a "no such file or directory" error, simply a newline as if I just pressed enter on a blank line.
As root user it is indeed not possible for me to run "test.bin" without "./", which is what I expected. And it does give the bash error message.
Does anyone know why this is?
Well... I have to thank a freebsd-using friend to point me in the right direction.
The thing is, bash keeps a table with all the results it gets from PATH searches. So, when it has found a program somewhere in the PATH, it never searches for it again because its location is unlikely to change.
That is why yesterday, when I made my own 'ls', I kept running /bin/ls instead of /home/png/bin/ls.
There is a bash builtin command, hash , that shows the current contents of the search table. If you do the same test as I did, and then run 'hash', you can see exactly which version of 'ls' will be executed. Furthermore, if you erase that executable, bash will no longer be able to find it and will complain about it, even when there is another executable with the same name in the path!!!
How to fix that?
When an executable changes its location, you need to tell bash "forget what you assumed about this program" so that it will search again next time. In bash, this is done with the following command:
This erases the full hash table.
You can see more about this in bash(1), in the "BASH BUILTIN COMMANDS" section.
BTW, in freebsd there is also the 'rehash' command that makes the shell rebuild the table.