Hi. > Date: Tue, 20 Aug 2013 11:02:24 -0400 > From: Greg Wooledge <wool...@eeg.ccf.org> > To: Aharon Robbins <arn...@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-b...@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
