my command line isn't working

[jiggolo182]

ok so im having a major problem here.. right now i am logged in as root because when i login as my regular username none of my commands work.. i cant startx, ls, pwd or run any aliases that i have set up. does anyone have any idea what happened? also, for some reason 'echo' and 'cd' seem to work but nothing else..


brandon

[jiggolo182]

ok so i fixed.. i think.. i got my commands back.. i had put the following line in my .cshrc file and it made all the difference in the world..

set path = (. $path)
that one works

set path = (. $PATH) causes me to lose all my commands.. can anyone explain this to me?

brandon

[serz]

Ah, I googled a little bit and it looks like the environment variables for csh are lowercase.

[hlrguy]

When you set $path, you are doing nothing. $PATH is your path that the command line looks at to find commands. I don't know explicitly what the second line does, except obviously, it wipes out your $PATH.

If you want to see what your environment variables are in a shell, enter

env |more

hlrguy

[serz]

My mistake then, sorry..

[Hayl]

$path is an ampty variable, $PATH is the real $PATH variable there for by setting it to . and $path you are setting it to . + a null string.

but i am a little confused, why are you adding your cwd (current working directory) into your $PATH variable? adding your cwd to your $PATH is one of the most basic no-nos in unix security. by having . (cwd) in your path it makes it very easy to put a trojaned version of any command anywhere in your system and then when you run what you think is the real version you will run the one in your cwd. you should remove . from your $PATH right away.

the correct way to set this is:
export $PATH=/some/other/path:$PATH

Security Reference >>> "Real World Linux Security (2nd edition)", Author: Bob Toxen, page 25, page 132. It's a 5 skull security threat which is very high.

[BMK1st]

Originally posted by Hayl
the correct way to set this is:
export $PATH=/some/other/path:$PATH

I haven't used csh in long time but I believe 'export' doesn't work in csh. Use 'set' instead.

In my .cshrc on OpenBSD, it's
set path = (~/bin /bin /sbin /usr/{bin,sbin,local/bin,local/sbin,games} .)


jiggolo182 - Do a google on csh or cshrc. There are plenty of examples on PATH for csh. :)

[Hayl]

oops, didn't notice it was csh; regardless adding . (cwd) to $PATH == evil

[jiggolo182]

i added . to PATH because when i write programs and then execute them im not used to using the /. command and i always forget it. also, when i transfer the files onto the computers at school i dont need to use the /. because . is already in my PATH there too. the school computers that i telnet into are running Sun OS 5.9.

[Hayl]

Originally posted by jiggolo182
i added . to PATH because when i write programs and then execute them im not used to using the /. command and i always forget it. also, when i transfer the files onto the computers at school i dont need to use the /. because . is already in my PATH there too. the school computers that i telnet into are running Sun OS 5.9.

well... regardless it's very bad security. but if you want an insecure box then go ahead. it's not hard to get used to using ./<name of thing you want to execute>. there's really no excuse/reason for having . in your path.

[cybertron]

Originally posted by Hayl
well... regardless it's very bad security. but if you want an insecure box then go ahead. it's not hard to get used to using ./<name of thing you want to execute>. there's really no excuse/reason for having . in your path.
Agreed. When I first started out in Linux I thought not having . in the path was dumb, but then I found out how dangerous that can be. ./ becomes such a habit you don't even think about it after a little while and it's definitely worth using.

[jiggolo182]

could someone please explain to me why it's so dangerous to have . in PATH. i didnt understand Hayl's explanation. i know what a trojan is but not quite sure how it ties in with this topic :confused:

brandon

[BMK1st]

Originally posted by Hayl
by having . (cwd) in your path it makes it very easy to put a trojaned version of any command anywhere in your system and then when you run what you think is the real version you will run the one in your cwd. you should remove . from your $PATH right away.
He already has explained that one. Let's say I created a dangerous file called 'cp' and I put it in the directory, /home/joe/music. I wrote this script, cp, that will will delete everything in the directory where cp is in. Since you have . in your $path and you change to /home/joe/music and want to copy a music file to another directory. You'd type and enter 'cp' and everything in that directory is gone forever. Do you understand what I'm saying?

To avoid stuff like this, you better remove . from your $path and start a new habit by type ./ every time you execute a script. ;)

[serz]

It's indeed a bad security practice, really.. use ./program, two more characters only heh.

[shadov]

Originally posted by jiggolo182
i added . to PATH because when i write programs and then execute them im not used to using the /. command and i always forget it. also, when i transfer the files onto the computers at school i dont need to use the /. because . is already in my PATH there too. the school computers that i telnet into are running Sun OS 5.9.
If you are testing/debugging a program, you use shell history to execute it. Right? You only need to type the ./ once in the beginning of your coding session.

You don't need . in your path to be able to transfer files without using ./ . Path only affects where your shell looks for executables. It has no effect on arguments (file names) you pass to scp or what ever you use to transfer files. Or did I misunderstand your post?

[jiggolo182]

ok.. yes i know that i dont need . in path to transfer files..but one of my programs that i wrote had to run other programs by creating system calls and sending them to command line. so when i got it to compile and run here with ./program i would have to fix my source file to not add ./to the command line string then recompile and run.. in short.. it is just easier for me.. im fairly new to linux so i dont know how to write any scripts and no one else uses this computer (although i know that nothing is safe if it is on the internet haha). also, yes i use the history most of the time to rerun or compile my programs.

in regards to bmk1st's example, yes it makes clear sense.. thanks for clearing it up..

[trc]

if you really don't want to use the ./ to run a program, you could create a symlink to the file and place it within your $PATH

ln -s /path/to/file /usr/local/bin/file

[jiggolo182]

heh thats even more work than just typing ./ but thanks for the suggestion..

[psi42]

Originally posted by jiggolo182
i added . to PATH because when i write programs and then execute them im not used to using the /. command and i always forget it. also, when i transfer the files onto the computers at school i dont need to use the /. because . is already in my PATH there too. the school computers that i telnet into are running Sun OS 5.9.

Well... that's not surprising considering they are also running telnet...

If you just put the directory containing your programs into your $PATH, would that be good enough? It's still much more secure than adding the CWD...

[jiggolo182]

yes adding the path to my programs to $PATH would work except the fact that it would change everytime i write one.. for example /home/brandon/programs/assignment1/<programname>
and
/home/brandon/programs/assignment2/<programname>

i would have to keep updating my $PATH to include the latest cwd.. i suppose i can just learn to do the ./ thing if adding . is so dangerous

brandon

[trc]

Originally posted by jiggolo182
heh thats even more work than just typing ./ but thanks for the suggestion..

sorry, I should have added that once you create a symbolic link and place it in your PATH, you will be able to run the program simply by typing in the program name. going back to the example I gave before, after entering the command: ln -s /path/to/file /usr/local/bin/myprogram1
you would be able to run myprogram1 in any working directory simply by entering 'myprogram1' in the command line (without the quotes).