dot slash ( ./ ) problem

[jfshadow]

Hello All:

There were several of you who tried to help me figure out why I could not run certain executables on my system w/o putting a ./ before it. Unfortunately, I could not keep that string alive there was a problem posting a reply after USER: Logon Name Gone posted the last comment.

I tried taking X_console's advice to export PATH=$PATH:., syn's to move it to /usr/bin and Logon Name Gone's to add "./" to $PATH. Also, in answer to DMR:
Depending on how you access an account, either ~/.bash_profile or /etc/profile will be sourced. The same is true of ~/.bashrc vs. /etc/bashrc. I forget the details at the moment.
Actually, I haven't worried about which one is sourced when I open a console, at this point I've just been manually invoking the profile that I want to use, although I would like to know how to get X window's 'konsole' to use /etc/profile.local the same as the non-graphical login does, since it apparently uses a different environment file.

Originally posted by EyesWideOpen
Does this happen with all executables or just certain programs?

Normal system programs do work without a hitch, such as those in /usr/bin. It is my executable shell scripts that won't work without the ./ prefix.

Not sure what to do from here. Is SuSE usually this strange on operability? Or is it the same with other distro's too? I'm relatively new to linux, so I don't know yet.

[Dark Ninja]

No, I had a similar problem in Mandrake and Slackware. Even typing ./programname still would not run it (even if it was in my home directory). The way I eventually fixed this was I edited my path in my .bash_profile in my home directory. For root, I would edit /root/.bashrc.

After that, everything worked fine for me. (PLEASE NOTE: I noticed on another "Newbie" Linux type board that a person suggested adding "." to the root's $PATH. DO NOT do this, as you will create a security issue. Just thought I'd warn you about that.)


Dark Ninja

[bdl]

Create a dir named 'bin' under your home directory. Make sure all the scripts you want to use are executable. Add the 'bin' dir to your path.

prompt@linuxbox:/home/name $ mkdir bin

prompt@linuxbox:/home/name $ chmod +x bin/*

prompt@linuxbox:/home/name $ PATH=$PATH:/home/name/bin

Thats about the gist of it. You just add the PATH variable to your ~/.profile or ~/.bash_profile and you're set. You can do the same for any other directories you feel have to be in the path, but like Dark Ninja, I highly recommend against adding '.' (the current working directory) to the path.

[jfshadow]

Well, Dark Ninja and bdl, I tried both of the ways that you mentioned and neither work.

I have been able to get them to run using ./ though, all along.

Actually, I developed these applications on a *NIX machine but made them portable so that they could run on Linux. They were written in ksh, which I do have installed on SuSE, and should be able to run under both bash and zsh. As mentioned before, they do run, just not without the ./ prefix.

Oh, if only things were simpler...

Thanks for your help everyone.

[Gaccm]

so, do they run without the ./ if you move them to /usr/bin? if they don't..... thats not good at all. If they do work, then try running the command "set" and look for the line about your path (or do "set|grep PATH") and check if '.' is in it. if it is, you should be able to just do the command name and the program will open. Also Dark Ninja, the only way i can think that this would be a security threat (i'm sleepy so there might be more) is if someone creates a program called "su" which emails root's password to someone. But, that still shouldn't be a problem because the '.' is the last place in the path, so /usr/bin/su would be found first.

[jfshadow]

Gaccm wrote:
so, do they run without the ./ if you move them to /usr/bin? if they don't..... thats not good at all.

No. That was one of the first things I tried.

I was wondering if it could be because I am using aliasing, though. For example:

alias rm="$HOME/.trash/trash.sh -rm "

is a line that I added to my profile to over-ride the rm command.

That shouldn't be the cause of the problem though, because when I type: rm[b/]
an error message says: [b]$HOME/.trash/trash.sh cannot be found although it is absolutely there with file permissions set to -rwxr-xr-x.

And when I copied the executable to /usr/bin, I changed the alias to read:
alias rm="/usr/bin/trash.sh -rm ", and involked the profile, but as mentionde, that didn't work either.

This is messed up.

[slapNUT]

What do you see if you type:
echo $PATH

Also make sure you have an entry in /etc/passwd that looks something like this:
ifshadow:x:501:501:The ifshadow dude:/home/ifshadow:/bin/bash

Have you tried creating a new user and see if that account works?

[jfshadow]

Maybe this will help:

"root" /root--$ echo $PATH
/opt/kde/bin:/opt/kde2/bin:/sbin:/usr/sbin:/usr/local/sbin:/root/bin:/usr/local/bin:/usr/bin:/usr/X11R6/bin:/bin:/usr/lib/java/bin:/var/lib/dosemu:/usr/games/bin:/usr/games: /opt/gnome/bin:/opt/kde/bin:./:.:./:.

"root" /root--$ ls
AOpen FM56-SM Soft PCI Modem.log.txt PPP-logfile lost+found trash_install.sh
Desktop bin test.txt trash_install.tar.gz

"root" /root--$ rm test.txt
bash: /usr/bin/trash.sh: No such file or directory

"root" /root--$ ls -l /usr/bin/trash.sh
-rwxr-xr-x 1 root root 8090 Dec 4 08:06 /usr/bin/trash.sh

"root" /root--$ tail -8 /etc/profile.local
#- Trash Bin
#--------------------------
alias empty="/usr/bin/rm -fr ${HD}/.trash/can/* && > ${HD}/.trash/trash.list"
alias list="/usr/bin/trash.sh -list "
alias restore="/usr/bin/trash.sh -rest "
alias rm="/usr/bin/trash.sh -rm " #-- Same as 'throw'
alias throw="/usr/bin/trash.sh -rm " #-- Same as 'rm'
alias trash="echo ''; echo 'disk usage:'; du -h ${HD}/.trash/can; echo ''; echo "Contents:"; cat ${HD}/.trash/trash.list | more; echo ''"

"root" /root--$

[Dark Ninja]

Also Dark Ninja, the only way i can think that this would be a security threat (i'm sleepy so there might be more) is if someone creates a program called "su" which emails root's password to someone. But, that still shouldn't be a problem because the '.' is the last place in the path, so /usr/bin/su would be found first.

Hey Gaccm. Sorry - let me explain the hole.

Normally, "." is listed in the $PATH for convenience. For example, a user does not need to type "./program_name" to run a program - they can just type "program_name"

HOWEVER, this is an enormous security hole in root to have "." in the $PATH. The reason for this is because - say an account on your system is compromised (but root hasn't been). What an attacker may try doing is putting a trojan horse into the user's home directory (possibly) or the /tmp directory. The trick is - the name of the trojan horse will be close to a common mispelling or mistyping of a normal command. Thus, the first time that mispelling is typed, the attacker has then installed a trojan on your system. It's that easy.

Also...there is always the problem of having "." listed first in the $PATH. Although - this should NEVER be done.

(For anybody who does not know, check /root/.bashrc and /root/.bash_profile to see your $PATH variable. It is advisable that you remove "." from your $PATH and then reboot.)


Dark Ninja