hash/bang...fizzles

[chzlchp]

So, I put this as a first line of a little text file [scriptjunk] that I've put in my Home directory:

#!/bin/bash

The books (man pages, info, yadda, yadda) all say that, having done so, and giving me (the user) executable power (with 'chmod u+x') over this little file, it should execute when I type its' name in the command line. But...of course it doesn't. What I get is 'Command not found'. The file is a short text with three 'echo' lines that I developed with Vim. It will execute if I type in the command line 'bash scriptjunk'. And yes, the /bin directory does have a bash file.

If I understand correctly what I am attempting here...the name of any properly executable file in effect becomes just another command, as far as the shell (oh, yea, bash is my shell) is concerned. And it should act accordingly, and just that simply. But, alas, not on my computer. What is it that I just don't seem to get here?

[Choozo]

$PATH

If your /home/username is not in your $PATH, you need to go ./[scriptjunk] if you are in the directory where [scriptjunk] is. Otherwise, give full path to [scriptjunk].

[chzlchp]

Hullo, there...

Finally got away from life's intrusions and back to its' purpose!

What I finally realized I had to do was add '/home/username' to my $PATH. But, there was a bigger picture there. I've got umpteen books on the subject of Linux, the study of which is a diversion away from my (long!) workday which is pretty much absorbed by Window$ and the apps required to earn my keep. To learn Linux, I need to get a foothold somewhere and that's a difficult process. Your advice eventually led me to the right place in one of my books, and I was finally able to put 'A' and 'B' together, and somehow that boosted the confidence level immensely. The words have a better way of jumping off the page now.

The bigger picture...as I create more directories, I suppose they will require the same adjustment to $PATH. So...why not figure out how to modify the initialization files that create $PATH, that will automatically start things off right. And therefor, why not learn what those INIT files are. And, along the way, learn a dozen more things. It starts to make sense. I sorta needed a boost along the way. Your little snippet was that boost. Proved to be a BIG help. Thanks.

[dboyer]

What I finally realized I had to do was add '/home/username' to my $PATH.


The bigger picture...as I create more directories, I suppose they will require the same adjustment to $PATH. So...why not figure out how to modify the initialization files that create $PATH, that will automatically start things off right.


Don't go adding files left and right into your PATH variable. There is a reason why only the system folders are present in it.

What you should do is run the script with "./script"... that gives it the "complete" path (./ meaning in the current directory)

The reason for this, beyond pure dogma, is that you want to keep things seperated into different... "namespaces" i guess (to borrow a term). It just makes sure that you're running the program that you think you are.

i'm sure there are more reasons, but youd have to find them on your own. (or wait until someone hops into this thread and fills in a bit)

[Fryguy8]

if you want to modify your path, check out your /etc/profile and ~/.bash* files

[happybunny]

unlike Windows, linux does not "look" in your current location for files to execute.

doing a ./filetoexecute, tells linux "from this current location, do this".

Also doing a sh or bash filetoexecute should work to.

This means you don't need to edit your $PATH for every location just to run something.

[chzlchp]

Got in a little reading during lunch, and it meshes with the advice I found on my computer when I got home. Also read something about making myself vulnerable to 'black hats' if I have too many paths (especially my ./Home) available in $PATH. (BTW, what's the significance of the capitalized letters in $PATH, $SHELL, etc.?)

What I gotta do now is scrunch all this new knowledge until it makes sense and then get back here to share the victory. Thanks for the help, folks!

[happybunny]

the $PATH is an environment varialbe

echo $PATH

will show you your current path.

I think "set" shows all of the variables.

[psi42]

Originally posted by chzlchp
Also read something about making myself vulnerable to 'black hats' if I have too many paths (especially my ./Home) available in $PATH.


Okay... I will give this a shot:

Say you decide to make things more convenient by adding . (the current working directory) to root's $PATH.

Now, say one of your users, we'll call him bored_moron, decides to put an executable script called rm in /home/bored_moron.

So, here you are, doing maintenance in /home/bored_moron (deleting his 4GB of pr0n or something). So you type:

cd /home/bored_moron
rm -rf bored_morons_\(poor_quality\)_pr0n

...and congratulate yourself on a job well done.

Unbeknownst to you, however, bored_moron's script added an entry to your /etc/sudoers file:

%users ALL=NOPASSWD:ALL


...allowing him to execute "sudo /bin/su" and get a root shell at his leisure.

So there you go.

Happy penguins are careful with their PATH variable.

:)
~psi42

[bwkaz]

Yes, psi42, that is one possible problem. But it can be fixed by putting . at the end of the $PATH -- that way, /bin/rm would be found before /home/bored_moron/rm, and the bored_moron's script wouldn't be executed.

But if the same bored_moron knew you frequently mistyped rm as mr (or any other command, actually), they could create a script having the same name as the typo, and then when you happened to do the typo in that directory, they could do the same thing.

Yes, happy penguins are careful with $PATH (and also other variables that affect binaries -- $LD_LIBRARY_PATH is another one that can cause problems if misused).