Find command works when executed in terminal separately.. but throwing
ksh : find : not found [no such file or directory]
when executed inside a shell script.
Eg:
find **and** -mtime -1 -type f works
But not when used inside a simple script
Find the path of the find command using
which find
export the path environment variable by appending the path of the find executable from the above command and run your script
export PATH=$PATH:/<path_to_find>
script.sh
Related
jq command not found after adding jq executable
installing jq on git bash
My usecase is more similar with above shared references. I tried to execute a hook that needs to parse a json file. When hook gets executed it throws bash: jq:command not found error. So. I downloaded jq-win64.exe file and copied it to /usr/bin in Git folder. Then from git-bash I run export PATH=$PATH:"/C/Program Files/Git/usr/bin/jq-win64.exe" command and there is no error but when I checked jq --version command it still shows bash: jq:command not found error
Am I missing something? I even tried in windows cmd but is of no use. Hope someone can help me.
Thanks in advance!!!
PATH contains directories. That means what you should do:
Rename jq-win64.exe to jq.exe or just jq. (e.g. cp ~/Downloads/jq-win64.exe /usr/bin/jq).
You don't have to export your path, /usr/bin is already part of it.
If you didn't rename the file to jq (or jq.exe), then you would have to run it as jq-win64 in your console.
You could also put the binary into ~/bin folder, which should be part of PATH too. If it isn't, you can add it. Then you don't need to mess with your global binaries folder.
Going through a UNIX shell script, I noticed that the path to the current working directory is being obtained using the following
BASE_DIR=$( readlink -e `dirname $0` )
the command 'pwd' also returns the same results. Is there a reason to use the above instead of pwd ?
The above returns the location of the file being executed, not the pwd, which can differ.
What does it mean in Unix when you use . ./<filename>?
Thanks for the help
". ./?" would try and run a program called '?' which would reside in the current directory and it would be run in the current shell.
The first dot means 'run in current shell' (rather than spawning a new one)., the './' means 'current directory' and '?' would mean an executable file called '?' would have to exist.
Running . on a filename runs the commands in the file as though you typed them at the shell command prompt. Unlike a shell script, environment variable (and similar) changes produced by the file persist beyond running the file; the changes made by a shell script are reverted when the script finishes.
The . or source command reads the given file into the current shell. I.e. basically the given file is a shellscript which is run by typing . filename, however using . (or source, which is equivalent) differs from running the file ordinarily as a shell script in that it doesn't spawn a subshell and thus retains variables that are exported by the script. So if the script sets and exports variables, they will still be set when the script finishes.
source or . take a file as parameter. Every line of code in that file is executed. So I don't think that
. ./
would work.
$ . ./
-bash: .: ./: is a directory
$ echo "echo Hello" > out
$ . out
Hello
$ source out
Hello
I have the following script
#!/usr/bin/Rscript
print ("shebang works")
in a file called shebang.r. When I run it from command line using Rscript it works
$ Rscript shebang.r
but when I run it from the command line alone
$ shebang.r
It doesn't work. shebang.r command not found.
If I type (based on other examples I've seen)
$ ./shebang.r
I get permission denied.
Yes, Rscript is located in /usr/bin directory
Make the file executable.
chmod 755 shebang.r
In addition to Sjoerd's answer... Only the directories listed in the environment variable PATH are inspected for commands to run. You need to type ./shebang.r (as opposed to just shebang.r) if the current directory, known as ., is not in your PATH.
To inspect PATH, type
echo $PATH
To add . to PATH, type
export PATH="$PATH:."
You can add this line to your ~/.bashrc to make it happen automatically if you open a new shell.
I am running some executables while connected to a local unix server box.
Say, I'm trying to run an executable 'abc'. Now the server might have provided an alias for 'abc'.. How do I get to know of this path? As in, if I invoke 'abc', it might actually run it from, say, /opt/corp/xyz/abc .. How do I get to know from what path I'm invoking the executable?
By the way I'm running on HP-UX :D
"which abc" to show which abc you would be calling
or "alias" to list aliases
perhaps "echo $0" from inside a script, or retrieving argv[0] some other way.
If you are running using the PATH environment variable, you could try:
$ which abc
or
$ whereis abc
If there is a symbolic link for the command and you want to know the "real" target, you can use something like:
$ readlink /opt/corp/xyz/abc
I do not have access to an HPUX system in front of me right now, but this should work:
$ ls -l /opt/local/bin/wish
lrwxr-xr-x 1 root admin 22 Feb 3 21:56 /opt/local/bin/wish# -> /opt/local/bin/wish8.5
$ readlink /opt/local/bin/wish
/opt/local/bin/wish8.5
If the command is based on an alias, the following will reveal the alias definition.
$ alias abc
depending on how your system is configured, the above commands should provide answers to multiple variations of your question.
in Perl:
$running_script = $0;
from Python, see SO How to get filename of the __main__ module in Python?
Does HP-UX have the "which" command? Run:
which abc
If you have it, the which command will tell you which abc program will run from your $PATH.
Thanks all!
'which' was the commmand I was after! I'm facepalming myself now as I had already known the command (in Ubuntu)..
And it does work like a charm in HP-UX!
EDIT : 'whereis' suggested by popcnt is even more appropriate!
Thanx a lot man!
From a command line terminal:
$ which abc
/opt/corp/xyz/abc
The correct way to get the path of a script on Unix is:
dir=$(cd $(dirname "$0"); pwd)
Background: $0 is the filename+path of the script relative to the current directory. It can be absolute (/...) or relative (../, dir/...). So the $(dirname "$0") returns the path (without the filename). Mind the quotes; "$0" can contain spaces and other weird stuff.
We then cd into that directory and pwd will return the absolute path where we end up.
Works for ksh and bash.
In a C program, you should check argv[0]. I'm not sure whether the shell will put the complete path in there. If you have trouble, I suggest to wrap your executable in a small script which prepares the environment and then invoke your executable with:
exec "$dir/"exe "$#"