Script directory in path
 

I add my script directory to my path, but still get this when I run a script from any other directory.

Andy:

Did you source the file you used to alter the path?
Your shell won't know about the edit until you do.
https://www.linuxquestions.org/quest...#faq_lqwelcome

Try also

I do not understand "source the file." ?

In my .bashrc

export PATH=$PATH:/root/Scripts/

The purpose of adding a dir to the path is to be able to runs scripts from any directory WITHOUT using the full path to it.

I guess Linux does it differently than Windows.

After the edit, you have to either close the shell and re-open it or use
to "re-read" it into the current shell session.

I know what the purpose of the path is on every OS. ;)
but since "No such file or directory" doesn't say jack-all about what generated the message...I asked you to test the full path to the script.
Is bash spewing "No such file or directory" or is the script?

Seems export PATH=$PATH:/root/Scripts/ should be enough.

Full path to script

does /root/Scripts/./Findit.sh take parameters?

Yes.
Can I make an alias that puts /root/Scripts/ in "front of" the script I want to run ?

export PATH=/root/Scripts/:$PATH

I have that in .bashrc but still get

don't use the .

Couple of possible issues here, and I think this probably should be in the Linux Software, Linux General, or Programming forums instead of Non-Nix General.

You've place a script in /root/Scripts.

Who owns that directory and what permissions does it allow?

Findit.sh should be executable permissions, but also should be executable permissions for the user which is attempting to run the script.

The two or three things which need to be satisfied are: (EDIT: OK 5 or 6! :))

1. The user attempting to execute any script or binary, must be able to "see" via permissions, the directory where the script or binary resides
2. The permissions for the script or binary must be executable for the user type which is attempting to run it
3. The user which is attempting to run it should have the directory where the binary or script resides, as part of their path, and they must log out and log back in as the best way to ensure that the update to the PATH is taken care of, or use one of the various source calls or re-run .bashrc. I say best to just create a new terminal window and verify that PATH now contains what you intend it to contain.
4. As pointed out, if there are arguments for a script or binary, and it doesn't tell you this, but instead encounters and error as shown, pretty bad script writing, but for a script, one can also turn on debugging and see if the problem lies within the first lines of the script versus if the problem lies in running the script.
5. You can stage this differently by copying the script locally and verify that when you are the owner and it's in your home directory, or "." (your local directory) that you can run the script successfully, all before you place it in a common system location, of which /root really isn't common for all users
6. I personally have "." in my path variable, that's just me, I'm sure there may be reasons why someone wouldn't do that, but I've like done it since the Unix days ...

Habitual has it right -the OP is using the relative dir './' to call the program. Leave off the './' before the program name so that the shell searches for the object in the PATH.

You and gnashley get the gold star.

Do not need ./ and less typing too.

Rtmistler,

All flavors of Puppy run as root.

This makes some Linux users cringe, but it's ok if you are safe and cautious.

woot.