Is there an API similar to the "whereis" command in UNIX that can be called from a C program to find out all instances of a given command?
Use getenv("PATH") to get a list of ':'-separated directory names. Look for the command name in each directory (e.g. using stat() or access()) and check if it's a regular file and can be executed. (If the directory name is empty, assume "." instead.) That's exactly what the which and whereis commands do.
The execvp() and execlp() functions automatically do PATH lookups when executing the given command, although it seems they do not manually check each path but just call execv(); if an error code is returned, they just try the next path.
There are many different functions in C you can use to launch shell command from your program. I think you should particularly look in the exec(3) family.
Every example you may need are in the manual: man 3 exec in a terminal or here: http://linux.die.net/man/3/exec.
Hope this helps!
Related
I ame using Linux Mint and I have to set some new environment variables.
I edited the file bash.bashrc in etc/ appending this line:
export NDK=/home/myname/Scrivania/android-ndk
but if i write on the shell the command $NDK i get this:
bash: home/myname/Scrivania/android-ndk: File o directory non esistente
why?
you get this error message exactly because you asked for it =)
sh#$NDK <enter>
keeping things simple such command tries to execute programs which stored inside NDK variable,
if it's what you tried to achieve then you should check that it's really exists.
if you want just to output value use:
sh#echo $NDK
$NDK is not a command. When you say $NDK at the shell prompt, then the OS tries to execute /home/myname/Scrivania/android-ndk which is probably not what you want.
Even if the directory /home/myname/Scrivania/android-ndk were to exist you would get the error you mentioned upon saying $NDK. You probably wanted to say cd $NDK or such.
type source .bashrc
in your terminal.
I am developing an application on Beaglebone board with Angstrom distrubition fo Linux.I faced an interesting problem.
When I execute :
sh /home/root/Desktop/BBTCP/out/vehicleDetect 192.168.10.29
in terminal it says
/home/root/Desktop/BBTCP/out/vehicleDetect: /home/root/Desktop/BBTCP/out/vehicleDetect: cannot execute binary file
But when i execute
cd /home/root/Desktop/BBTCP/
and
sh out/vehicleDetect 192.168.10.29
it starts working??
What is the reason and why I can't run tha application with first configuration?
I think it is about the difference between ./ and sh. What are the differences?
My first guess would be that one of the folders in the path /home/root/Desktop/BBTCP is a link. If vehicleDetect is a script and it invokes itself recursively, then this link might be confusing it.
If that's not the case, try sh -x /home/root/Desktop/BBTCP/out/vehicleDetect and see what that prints.
Lastly, check what's in the folder /home/root/Desktop/BBTCP. There might be an executable sh in there. If your path contains ., a different shell might be executed.
Seems like /home/root/Desktop/BBTCP/out/vehicleDetect is invoking a binary file (an executable) that was built on a different architecture.
The main difference between sh and ./ is that ./ will attempt to execute the file itself as an executable, whereas sh will do that for you. It could be that there is a weird magic number at the start of the file, but you would expect sh to complain about that.
Best guess though it is a #! line at the start of the file which either contains invalid characters or refers to a strange file. Did you, for example, bring this script file from another operating system (like Windows) that has different line endings? I have seen similar effects when text file scripts have not been converted but just copied. Maybe you downloaded it in a strange format?
Check with od -xc /home/root/Desktop/BBTCP/out/vehicleDetect and look at the first line.
I am new to shell scripting. I am trying to work through this.
> script to execute in cron (util.sh)
#!/bin/sh
HOST='ahostname'
PORT='3306'
USER='auser'
PASS='apassword'
DB='adatabase'
. /mnt/stor/backups/backup.sh
(I also tried source /mnt/stor/backups/backup.sh)
> script to execute (backup.sh)
When backup.sh is called (it does get called) it appears to simply be parsed and not executed. So no matter what I put in it I get messages like:
/mnt/stor/backups/backup.sh: line 8: date: command not found
/mnt/stor/backups/backup.sh: line 8: mysqldump: command not found
/mnt/stor/backups/backup.sh: line 8: tar: command not found
/mnt/stor/backups/backup.sh: line 8: rm: command not found
The idea is to have a domain localized file, execute it with variables, and call a master script that uses the variable to do the dirty work. Because of limitations with one of my hosts and multiple domains this is the best method.
The script with the Problem seems to be /mnt/stor/backups/backup.sh. Try setting the PATH to include all the usual directories with binaries, so the script can find its tools. Or, even better, change /mnt/stor/backups/backup.sh and use absolute paths in the commands like /bin/rm instead of just 'rm'.
When running from cron, you can't rely on any variables that are normally in your login shell's profile (e.g.: PATH, CLASSPATH, etc). You have to set explicitly what you need. In your case, i'm guessing that it's the lack of a PATH variable that's causing your troubles.
It's also good practice to put full paths to the programs you're executing from an unattended script, just to make sure you really are going to run that specific command, i.e., don't rely on the path.
So instead of
date
for example, use
/bin/date
etc.
I read that the executables for the commands issued using exec() calls are supposed to be stored in directories that are part of the PATH variable.
Accordingly, I found the executables for ls, chmod, grep, cat in /bin.
However, I could not find the executable for cd.
Where is it located?
A process can only affect its own working directory. When an executable is executed by the shell it executes as a child process, so a cd executable (if one existed) would change that child process's working directory without affecting the parent process (the shell), hence the cd command must be implemented as a shell built-in that actually executes in the shell's own process.
cd is a shell built-in, unfortunately.
$ type cd
cd is a shell builtin
...from http://www.linuxquestions.org/questions/linux-newbie-8/whereis-cd-sudo-doesnt-find-cd-464767/
But you should be able to get it working with:
sh -c "cd /somedir; do something"
Not all utilities that you can execute at a shell prompt need actually exist as actual executables in the filesystem. They can also be so-called shell built-ins, which means – you guessed it – that they are built into the shell.
The Single Unix Specification does, in general, not specify whether a utility has to be provided as an executable or as a built-in, that is left as a private internal implementation detail to the OS vendor.
The only exceptions are the so-called special built-ins, which must be provided as built-ins, because they affect the behavior of the shell itself in a manner that regular executables (or even regular built-ins) can't (for example set, which sets variables that persist even after set exits). Those special built-ins are:
break
:
continue
.
eval
exec
exit
export
readonly
return
set
shift
times
trap
unset
Note that cd is not on that list, which means that cd is not a special built-in. In fact, according to the specification, it would be perfectly legal to implement cd as a regular executable. It's just not possible, for the reasons given by the other answers.
And if you scroll down to the non-normative section of the specification, i.e. to the part that is not officially part of the specification but only purely informational, you will find that fact explicitly mentioned:
Since cd affects the current shell execution environment, it is always provided as a shell regular built-in.
So, the specification doesn't require cd to be a built-in, but it's simply impossible to do otherwise.
Note that sometimes utilities are provided both as a built-in and as an executable. A good example is the time utility, which on a typical GNU system is provided both as an executable by the Coreutils package and as a shell regular built-in by Bash. This can lead to confusion, because when you do man time, you get the manpage of the time executable (the time builtin is documented in man builtins), but when you execute time you get the time built-in, which does not support the same features as the time executable whose manpage you just read. You have to explicitly run /usr/bin/time (or whatever path you installed Coreutils into) to get the executable.
According to this, cd is always a built-in command and never an executable:
Since cd affects the current shell execution environment, it is always provided as a shell regular built-in.
cd is part of the shell; an internal command. There is no binary for it.
The command cd is built-in in your command line shell. It could not affect the working directory of your shell otherwise.
I also searched the executable of "cd" and there is no such.
You can work with chdir (pathname) in C, it has the same effect.
I would like to know exactly how the "Is" command works in Linux and Unix.
As far as I know, ls forks & exec to the Linux/Unix shell and then gets the output (of the current file tree. eg./home/ankit/). I need a more detailed explanation, as I am not sure about what happens after calling fork.
Could anyone please explain the functionality of the 'ls' command in detail?
ls doesn't fork. The shell forks and execs in order to run any command that isn't built in, and one of the commands it can run is ls.
ls uses opendir() and readdir() to step through all the files in the directory. If it needs more information about one of them it calls stat().
To add to the answer, in The C Programming Language book (K&RC) they have given a small example on how to go about implementing ls. They have explained the datastructures and functions used very well.
To understand what ls does, you could take a gander at the OpenSolaris source: https://hg.java.net/hg/solaris~on-src/file/tip/usr/src/cmd/ls/ls.c.
If that´s overwhelming, on Solaris you start by using truss to look at the system calls that ls makes to understand what it does. Using truss, try:
truss -afl -o ls.out /bin/ls
then look at the output in ls.out
I believe that trace is the equivalent to truss in Linux.
If you really want to understand the detailed innards of ls, look at the source code. You can follow tpgould's link to the Solaris source, or it's easy to find the source online from any Linux or BSD distribution.
I'll particularly recommend the 4.4BSD source.
As I recall, ls starts by parsing its many options, then starts with the files or directories listed on the command line (default is "."). Subdirectories are handled by recursion into the directory list routine. There's no fork() or exec() that I recall.
This is a old thread , but still I am commenting because I believe the answer which was upvoted and accepted is partially incorrect. #Mark says that ls is built into shell so shell doesn't exec and fork. When I studied the tldp document on bash(I have attached the link)
"ls" is not listed as a build in command.
http://tldp.org/LDP/Bash-Beginners-Guide/html/sect_01_03.html
Bash built-in commands:
alias, bind, builtin, command, declare, echo, enable, help, let, local, logout, printf, read, shopt, type, typeset, ulimit and unalias.