Location: Asia Pacific, Cyberspace, in the Dark Dystopia
Thanks Given: 2,351
Thanked 3,358 Times in 1,877 Posts
OK..... if it is 'exec()able' then it:
The exec family of functions replaces the current process
image with a new process image. The functions described
in this manual page are front-ends for the function
execve(2). (See the manual page for execve for detailed
information about the replacement of the current process.)
The initial argument for these functions is the pathname
of a file which is to be executed.
The const char *arg and subsequent ellipses in the execl,
execlp, and execle functions can be thought of as arg0,
arg1, ..., argn. Together they describe a list of one or
more pointers to null-terminated strings that represent
the argument list available to the executed program. The
first argument, by convention, should point to the file
name associated with the file being executed. The list of
arguments must be terminated by a NULL pointer.
The execv and execvp functions provide an array of point-
ers to null-terminated strings that represent the argument
list available to the new program. The first argument, by
convention, should point to the file name associated with
the file being executed. The array of pointers must be
terminated by a NULL pointer.
The execle function also specifies the environment of the
executed process by following the NULL pointer that termi-
nates the list of arguments in the parameter list or the
pointer to the argv array with an additional parameter.
This additional parameter is an array of pointers to null-
terminated strings and must be terminated by a NULL
pointer. The other functions take the environment for the
new process image from the external variable environ in
the current process.
Some of these functions have special semantics.
The functions execlp and execvp will duplicate the actions
of the shell in searching for an executable file if the
specified file name does not contain a slash (/) charac-
ter. The search path is the path specified in the envi-
ronment by the PATH variable. If this variable isn't
specified, the default path ``:/bin:/usr/bin'' is used.
In addition, certain errors are treated specially.
If permission is denied for a file (the attempted execve
returned EACCES), these functions will continue searching
the rest of the search path. If no other file is found,
however, they will return with the global variable errno
set to EACCES.
Does this answer all questions, or just create more ?
Originally posted by rwb1959 The AIX version seems to explain it best. It states that this
is to provide exec()-able versions of shell built-ins...
Why would you possibly need an exec-able version of cd? Execing it would just change your current directory and then immediately kill your shell. Doesn't seem very useful to me. If you can't run any command after the "cd" why would you even need to call it?
I also was thinking of something else.. This *may* have something to do with the UNIX-95 specification (seeing as how they seem to came out in 95).. Perhaps there is something which says something about built-in command having equivalent /usr/bin commands.... Or maybe something with POSIX, I dunno... I'm just rambling....
To the cd question though, it is ludicrous to have /usr/bin/cd.. Plain-and-simple.. There is no good use for it...... I have tried-and-tried to come up with a reason for it and it just isn't there.... So if it bugs you - delete it... I'm quite sure your system won't mind...
Originally posted by devnul Or maybe something with POSIX, I dunno... I'm just rambling....
I got curious so I did some digging on Usenet, and came up with a similar thread on comp.unix.questions. The ultimate answer to that thread was that it is part of the POSIX.2 standard. All builtins must also exist as scripts or binaries in the filesystem. They do not have to do anything, but they must exist. The logic behind this requirement is still a mystery, but hopefully we can close this thread now...