Re: feature request: file_not_found_handle()

[Aharon Robbins]

Hi.

> Date: Tue, 20 Aug 2013 11:02:24 -0400
> From: Greg Wooledge <wooledg@eeg.ccf.org>
> To: Aharon Robbins <arnold@skeeve.com>
> Cc: bug-bash@gnu.org
> Subject: Re: feature request: file_not_found_handle()
>
> On Tue, Aug 20, 2013 at 05:48:12PM +0300, Aharon Robbins wrote:
> > In article <mailman.403.1376999138.10748.bug-bash@gnu.org> you write:
> > >1) PATH is used by the kernel (exec family) to determine how commands are
> > >   executed.  The way PATH is used by the kernel is not likely to change.
> > >   Having the shell treat it differently would lead to confusion.
> > 
> > Actually, PATH searching is implemented in the C library and always
> > has been; there is only one real system call.  The confusion likely arises
> > from the traditional practice of documenting all the exec calls on the
> > same manpage.
>
> Oh, really?  That's very misleading and confusing.
>
> HP-UX 10.20 exec(2) says:
>
>   The exec*() system calls, in all their forms, ...
>
> So that's a complete lie, I guess.

A small fiction. The man pages were that way since at least V7, and
probably further back. IIRC the BSD folks at 4.2 left execve in section 2
and moved the rest to section 3.  It is certianly that way now on
GNU/Linux systems.

> (And they do appear to be defined in
> /lib/libc.a if I'm reading the output of nm correctly.)

All the system calls are in /lib/libc.a.  They are implemented as regular
C wrappers around a special function (usually) written in assembly that
traps into the kernel passing the system call number and the parameters
and returning the result code.

On a Linux system see syscalls(2), syscall(2) and possibly _syscall(2)
(the latter is marked obsolete).

As Chet said, most people don't really need to know about this fiction.

Thanks,

Arnold