Dup2 and execl system calls

Question

I know the dup2 call moves a pointer to a file to a destination you specify but what does execl do and how do they work together? execl seems to use commands pulled out of thin air but they're obviously coming from somewhere, how many commands are there? ive only come across 'sort'.

Posted Aug 11, 2020, 9:36 PM UTC

35
dragon_wrangler•

execl executes an external command. There are as many commands as there are executables on the system. docs

dup2 creates an additional handle for a previously opened file. It doesn't affect the actual file. docs

Can you provide some of the context you're seeing?

2
FUZxxl•

Check the manual for what commands they are. User commands are found in section 1, system commands in section 8. The corresponding binaries are spread over /bin, /sbin, /usr/bin, and /usr/sbin.

2
Paul_Pedant•

You might want to be fairly selective. My counts of commands are:

   149 : /bin
   189 : /sbin
  1734 : /usr/bin
   248 : /usr/sbin

The code you see is what shell does every time you type a command: it replicates stdin, stdout and stderr, and uses dup2 to attach each of them to the new program so it can share the terminal (or it can do redirections and pipes in similar ways).

Then it forks itself (which you should also have seen) to make a new process (a copy of the shell itself). Then that copy uses execlp to load a new executable over itself.

Being as this is Unix/Linux, you can do anything a shell can do, if you gain the knowledge.

1
nerd4code•

FDs are cloned/shared from parent into child at fork and held over across exec unless marked with O_CLOEXEC via open or fcntl. dup2 is typically used to replace the stdio streams with pipe ends, allowing the parent to control the stdio goings-on.

The -p forms of exec search through the PATH environment variable if the exe name isn't absolute (i.e., initial /), which contains a list of executable search paths separated by : (UNIX) or ; (DOS/Win). It runs the first match it finds. Usually PATH starts with bin dirs within your home dir, since that's handy for per-user installation. Usually those are like $HOME/bin, $HOME/local/bin, or $HOME/.local/bin. After that come system paths, usually /opts if needed, then /usr/local/bin, then /usr/bin, then /bin. In theory, at startup all you have is the basic POSIX command set, then you mount /usr which includes things from the distro, or /usr/local which includes systemwide installs. This order is used so user, then sysadmin, then distro can override commands in later elementd of PATH. Because there isn't always an appropriate exec*p form, you'll often have to walk PATH manually, but that's relatively easy.

The PATH appriach is quite common, and can be done with (e.g.) LD_LIBRARY_PATH, MANPATH, or CPATH.

At the command-line, you can use which to tell you where an external command is sourced from. Some commands are implemented internally by the shell (e.g., cd must be), some are shell functions (can define your own in .bashrc), some might be aliases, and only if none of those pick up will PATH be searched. If help cmd works, it's shell internal. If display -pF cmd works, it's a function. Some shell commands mask external ones; e.g. there's usually a /bin/echo even though that's always internal, or /bin/time which has completely different output from interbal time. Function names can include slashes and other non-word-splitting characters, so initial / is not guaranteed to call external.

2
raevnos•

The exec functions replace the current process with a new one.

1