Friday, June 26, 2009

Man page: Vim

NAME
vim - Vi IMproved, a programmers text editor

SYNOPSIS
vim [options] [file ..]
vim [options] -
vim [options] -t tag
vim [options] -q [errorfile]

ex
view
gvim gview evim eview
rvim rview rgvim rgview

DESCRIPTION
Vim is a text editor that is upwards compatible to Vi. It can
be used to edit all kinds of plain text. It is especially
useful for editing programs.
There are a lot of enhancements above Vi: multi level undo,
multi windows and buffers, syntax highlighting, command line
editing, filename completion, on-line help, visual selection,
etc.. See ":help vi_diff.txt" for a summary of the differ‐
ences between Vim and Vi.

While running Vim a lot of help can be obtained from the on-
line help system, with the ":help" command. See the ON-LINE
HELP section below.

Most often Vim is started to edit a single file with the com‐
mand

vim file

More generally Vim is started with:

vim [options] [filelist]
If the filelist is missing, the editor will start with an
empty buffer. Otherwise exactly one out of the following four
may be used to choose one or more files to be edited.

file .. A list of filenames. The first one will be the
current file and read into the buffer. The cursor
will be positioned on the first line of the
buffer. You can get to the other files with the
":next" command. To edit a file that starts with
a dash, precede the filelist with "--".

- The file to edit is read from stdin. Commands are
read from stderr, which should be a tty.

-t {tag} The file to edit and the initial cursor position
depends on a "tag", a sort of goto label. {tag}
is looked up in the tags file, the associated file
becomes the current file and the associated com‐
mand is executed. Mostly this is used for C pro‐
grams, in which case {tag} could be a function
name. The effect is that the file containing that
function becomes the current file and the cursor
is positioned on the start of the function. See
":help tag-commands".

-q [errorfile]
Start in quickFix mode. The file [errorfile] is
read and the first error is displayed. If [error‐
file] is omitted, the filename is obtained from
the ’errorfile’ option (defaults to "AztecC.Err"
for the Amiga, "errors.err" on other systems).
Further errors can be jumped to with the ":cn"
command. See ":help quickfix".

Vim behaves differently, depending on the name of the command
(the executable may still be the same file).

vim The "normal" way, everything is default.

ex Start in Ex mode. Go to Normal mode with the ":vi"
command. Can also be done with the "-e" argument.
view Start in read-only mode. You will be protected from
writing the files. Can also be done with the "-R"
argument.

gvim gview
The GUI version. Starts a new window. Can also be
done with the "-g" argument.

evim eview
The GUI version in easy mode. Starts a new window.
Can also be done with the "-y" argument.

rvim rview rgvim rgview
Like the above, but with restrictions. It will not
be possible to start shell commands, or suspend Vim.
Can also be done with the "-Z" argument.

OPTIONS
The options may be given in any order, before or after file‐
names. Options without an argument can be combined after a
single dash.

+[num] For the first file the cursor will be positioned
on line "num". If "num" is missing, the cursor
will be positioned on the last line.

+/{pat} For the first file the cursor will be positioned
on the first occurrence of {pat}. See ":help
search-pattern" for the available search patterns.

+{command}

-c {command}
{command} will be executed after the first file
has been read. {command} is interpreted as an Ex
command. If the {command} contains spaces it must
be enclosed in double quotes (this depends on the
shell that is used). Example: Vim "+set si"
main.c
Note: You can use up to 10 "+" or "-c" commands.
-S {file} {file} will be sourced after the first file has
been read. This is equivalent to -c "source
{file}". {file} cannot start with ’-’. If {file}
is omitted "Session.vim" is used (only works when
-S is the last argument).

--cmd {command}
Like using "-c", but the command is executed just
before processing any vimrc file. You can use up
to 10 of these commands, independently from "-c"
commands.

-A If Vim has been compiled with ARABIC support for
editing right-to-left oriented files and Arabic
keyboard mapping, this option starts Vim in Arabic
mode, i.e. ’arabic’ is set. Otherwise an error
message is given and Vim aborts.

-b Binary mode. A few options will be set that makes
it possible to edit a binary or executable file.
-C Compatible. Set the ’compatible’ option. This
will make Vim behave mostly like Vi, even though a
.vimrc file exists.

-d Start in diff mode. There should be two, three or
four file name arguments. Vim will open all the
files and show differences between them. Works
like vimdiff(1).

-d {device} Open {device} for use as a terminal. Only on the
Amiga. Example: "-d con:20/30/600/150".

-D Debugging. Go to debugging mode when executing
the first command from a script.

-e Start Vim in Ex mode, just like the executable was
called "ex".

-E Start Vim in improved Ex mode, just like the exe‐
cutable was called "exim".
-f Foreground. For the GUI version, Vim will not
fork and detach from the shell it was started in.
On the Amiga, Vim is not restarted to open a new
window. This option should be used when Vim is
executed by a program that will wait for the edit
session to finish (e.g. mail). On the Amiga the
":sh" and ":!" commands will not work.

--nofork Foreground. For the GUI version, Vim will not
fork and detach from the shell it was started in.

-F If Vim has been compiled with FKMAP support for
editing right-to-left oriented files and Farsi
keyboard mapping, this option starts Vim in Farsi
mode, i.e. ’fkmap’ and ’rightleft’ are set. Oth‐
erwise an error message is given and Vim aborts.

-g If Vim has been compiled with GUI support, this
option enables the GUI. If no GUI support was
compiled in, an error message is given and Vim
aborts.

-h Give a bit of help about the command line argu‐
ments and options. After this Vim exits.

-H If Vim has been compiled with RIGHTLEFT support
for editing right-to-left oriented files and
Hebrew keyboard mapping, this option starts Vim in
Hebrew mode, i.e. ’hkmap’ and ’rightleft’ are set.
Otherwise an error message is given and Vim
aborts.

-i {viminfo}
When using the viminfo file is enabled, this
option sets the filename to use, instead of the
default "~/.viminfo". This can also be used to
skip the use of the .viminfo file, by giving the
name "NONE".

-L Same as -r.

-l Lisp mode. Sets the ’lisp’ and ’showmatch’
options on.

-m Modifying files is disabled. Resets the ’write’
option. You can still modify the buffer, but
writing a file is not possible.

-M Modifications not allowed. The ’modifiable’ and
’write’ options will be unset, so that changes are
not allowed and files can not be written. Note
that these options can be set to enable making
modifications.

-N No-compatible mode. Reset the ’compatible’
option. This will make Vim behave a bit better,
but less Vi compatible, even though a .vimrc file
does not exist.

-n No swap file will be used. Recovery after a crash
will be impossible. Handy if you want to edit a
file on a very slow medium (e.g. floppy). Can
also be done with ":set uc=0". Can be undone with
":set uc=200".

-nb Become an editor server for NetBeans. See the
docs for details.

-o[N] Open N windows stacked. When N is omitted, open
one window for each file.

-O[N] Open N windows side by side. When N is omitted,
open one window for each file.

-p[N] Open N tab pages. When N is omitted, open one tab
page for each file.

-R Read-only mode. The ’readonly’ option will be
set. You can still edit the buffer, but will be
prevented from accidently overwriting a file. If
you do want to overwrite a file, add an exclama‐
tion mark to the Ex command, as in ":w!". The -R
option also implies the -n option (see below).
The ’readonly’ option can be reset with ":set
noro". See ":help ’readonly’".

-r List swap files, with information about using them
for recovery.

-r {file} Recovery mode. The swap file is used to recover a
crashed editing session. The swap file is a file
with the same filename as the text file with
".swp" appended. See ":help recovery".

-s Silent mode. Only when started as "Ex" or when
the "-e" option was given before the "-s" option.

-s {scriptin}
The script file {scriptin} is read. The charac‐
ters in the file are interpreted as if you had
typed them. The same can be done with the command
":source! {scriptin}". If the end of the file is
reached before the editor exits, further
characters are read from the keyboard.
-T {terminal}
Tells Vim the name of the terminal you are using.
Only required when the automatic way doesn’t work.
Should be a terminal known to Vim (builtin) or
defined in the termcap or terminfo file.

-u {vimrc} Use the commands in the file {vimrc} for initial‐
izations. All the other initializations are
skipped. Use this to edit a special kind of
files. It can also be used to skip all initial‐
izations by giving the name "NONE". See ":help
initialization" within vim for more details.

-U {gvimrc} Use the commands in the file {gvimrc} for GUI ini‐
tializations. All the other GUI initializations
are skipped. It can also be used to skip all GUI
initializations by giving the name "NONE". See
":help gui-init" within vim for more details.

-V[N] Verbose. Give messages about which files are
sourced and for reading and writing a viminfo
file. The optional number N is the value for
’verbose’. Default is 10.

-v Start Vim in Vi mode, just like the executable was
called "vi". This only has effect when the exe‐
cutable is called "ex".

-w {scriptout}
All the characters that you type are recorded in
the file {scriptout}, until you exit Vim. This is
useful if you want to create a script file to be
used with "vim -s" or ":source!". If the
{scriptout} file exists, characters are appended.

-W {scriptout}
Like -w, but an existing file is overwritten.

-x Use encryption when writing files. Will prompt
for a crypt key.

-X Don’t connect to the X server. Shortens startup
time in a terminal, but the window title and clip‐
board will not be used.

-y Start Vim in easy mode, just like the executable
was called "evim" or "eview". Makes Vim behave
like a click-and-type editor.

-Z Restricted mode. Works like the executable starts
with "r".

-- Denotes the end of the options. Arguments after
this will be handled as a file name. This can be
used to edit a filename that starts with a ’-’.

--echo-wid GTK GUI only: Echo the Window ID on stdout.

--help Give a help message and exit, just like "-h".

--literal Take file name arguments literally, do not expand
wildcards. This has no effect on Unix where the
shell expands wildcards.

--noplugin Skip loading plugins. Implied by -u NONE.

--remote Connect to a Vim server and make it edit the files
given in the rest of the arguments. If no server
is found a warning is given and the files are
edited in the current Vim.

--remote-expr {expr}
Connect to a Vim server, evaluate {expr} in it and
print the result on stdout.

--remote-send {keys}
Connect to a Vim server and send {keys} to it.

--remote-silent
As --remote, but without the warning when no
server is found.

--remote-wait
As --remote, but Vim does not exit until the files
have been edited.

--remote-wait-silent
As --remote-wait, but without the warning when no
server is found.

--serverlist
List the names of all Vim servers that can be
found.

--servername {name}
Use {name} as the server name. Used for the cur‐
rent Vim, unless used with a --remote argument,
then it’s the name of the server to connect to.

--socketid {id}
GTK GUI only: Use the GtkPlug mechanism to run
gvim in another window.

--version Print version information and exit.

Monday, November 24, 2008

Man page - write

NAME
write - write to a file descriptor

SYNOPSIS
#include <unistd.h>

ssize_t write(int fd, const void *buf, size_t count);

DESCRIPTION
write() writes up to count bytes from the buffer pointed buf to the
file referred to by the file descriptor fd.

The number of bytes written may be less than count if, for example,
there is insufficient space on the underlying physical medium, or the
RLIMIT_FSIZE resource limit is encountered (see setrlimit(2)), or the
call was interrupted by a signal handler after having written less than
count bytes. (See also pipe(7).)

For a seekable file (i.e., one to which lseek(2) may be applied, for
example, a regular file) writing takes place at the current file off
set, and the file offset is incremented by the number of bytes actually
written. If the file was open(2)ed with O_APPEND, the file offset is
first set to the end of the file before writing. The adjustment of the
file offset and the write operation are performed as an atomic step.

POSIX requires that a read(2) which can be proved to occur after a
write() has returned returns the new data. Note that not all file sys
tems are POSIX conforming.

RETURN VALUE
On success, the number of bytes written is returned (zero indicates
nothing was written). On error, -1 is returned, and errno is set
appropriately.

If count is zero and fd refers to a regular file, then write() may
return a failure status if one of the errors below is detected. If no
errors are detected, 0 will be returned without causing any other
effect. If count is zero and fd refers to a file other than a regular
file, the results are not specified.

ERRORS
EAGAIN The file descriptor fd has been marked non-blocking (O_NONBLOCK)
and the write would block.

EBADF fd is not a valid file descriptor or is not open for writing.

EFAULT buf is outside your accessible address space.

EFBIG An attempt was made to write a file that exceeds the implementa
tion-defined maximum file size or the processs file size limit,
or to write at a position past the maximum allowed offset.

EINTR The call was interrupted by a signal before any data was writ
ten.

EINVAL fd is attached to an object which is unsuitable for writing; or
the file was opened with the O_DIRECT flag, and either the
address specified in buf, the value specified in count, or the
current file offset is not suitably aligned.

EIO A low-level I/O error occurred while modifying the inode.

ENOSPC The device containing the file referred to by fd has no room for
the data.

EPIPE fd is connected to a pipe or socket whose reading end is closed.
When this happens the writing process will also receive a SIG
PIPE signal. (Thus, the write return value is seen only if the
program catches, blocks or ignores this signal.)

Other errors may occur, depending on the object connected to fd.

CONFORMING TO
SVr4, 4.3BSD, POSIX.1-2001.

Under SVr4 a write may be interrupted and return EINTR at any point,
not just before any data is written.

NOTES
A successful return from write() does not make any guarantee that data
has been committed to disk. In fact, on some buggy implementations, it
does not even guarantee that space has successfully been reserved for
the data. The only way to be sure is to call fsync(2) after you are
done writing all your data.

If a write() is interrupted by a signal handler before any bytes are
written, then the call fails with the error EINTR; if it is interrupted
after at least one byte has been written, the call succeeds, and
returns the number of bytes written.

SEE ALSO
close(2), fcntl(2), fsync(2), ioctl(2), lseek(2), open(2), pwrite(2),
read(2), select(2), writev(2), fwrite(3)

Man page - wait, waitpid, waitid

NAME
wait, waitpid, waitid - wait for process to change state

SYNOPSIS
#include <sys/types.h>
#include <sys/wait.h>

pid_t wait(int *status);

pid_t waitpid(pid_t pid, int *status, int options);

int waitid(idtype_t idtype, id_t id, siginfo_t *infop, int options);

Feature Test Macro Requirements for glibc (see feature_test_macros(7)):

waitid(): _SVID_SOURCE || _XOPEN_SOURCE

DESCRIPTION
All of these system calls are used to wait for state changes in a child of the calling process, and obtain information about the child whose
state has changed. A state change is considered to be: the child terminated; the child was stopped by a signal; or the child was resumed by a signal. In the case of a terminated child, performing a wait allows the system to release the resources associated with the child; if a wait is not performed, then terminated the child remains in a "zombie" state (see NOTES below).

If a child has already changed state, then these calls return immediately. Otherwise they block until either a child changes state or a signal handler interrupts the call (assuming that system calls are not automatically restarted using the SA_RESTART flag of sigaction(2)). In the remainder of this page, a child whose state has changed and which has not yet been waited upon by one of these system calls is termed waitable.

wait() and waitpid()
The wait() system call suspends execution of the calling process until one of its children terminates. The call wait(&status) is equivalent
to:
waitpid(-1, &status, 0);

The waitpid() system call suspends execution of the calling process until a child specified by pid argument has changed state. By default, waitpid() waits only for terminated children, but this behavior is modifiable via the options argument, as described below.

The value of pid can be:

< -1 meaning wait for any child process whose process group ID is equal to the absolute value of pid.

-1 meaning wait for any child process.

0 meaning wait for any child process whose process group ID is equal to that of the calling process.

> 0 meaning wait for the child whose process ID is equal to the value of pid.

The value of options is an OR of zero or more of the following constants:

WNOHANG return immediately if no child has exited.

WUNTRACED also return if a child has stopped (but not traced via ptrace(2)). Status for traced children which have stopped is provided even if this option is not specified.

WCONTINUED (Since Linux 2.6.10) also return if a stopped child has been resumed by delivery of SIGCONT.

(For Linux-only options, see below.)

The WUNTRACED and WCONTINUED options are only effective if the SA_NOCLDSTOP flag has not been set for the SIGCHLD signal (see sigaction(2)).

If status is not NULL, wait() and waitpid() store status information in the int to which it points. This integer can be inspected with the following macros (which take the integer itself as an argument, not a pointer to it, as is done in wait() and waitpid()!):

WIFEXITED(status)
returns true if the child terminated normally, that is, by calling exit(3) or _exit(2), or by returning from main().

WEXITSTATUS(status)
returns the exit status of the child. This consists of the least significant 8 bits of the status argument that the child specified in a call to exit(3) or _exit(2) or as the argument for a return statement in main(). This macro should only be employed if WIFEXITED returned true.

WIFSIGNALED(status)
returns true if the child process was terminated by a signal.

WTERMSIG(status)
returns the number of the signal that caused the child process to terminate. This macro should only be employed if WIFSIGNALED returned true.

WCOREDUMP(status)
returns true if the child produced a core dump. This macro should only be employed if WIFSIGNALED returned true. This macro is not specified in POSIX.1-2001 and is not available on some Unix implementations (e.g., AIX, SunOS). Only use this enclosed in #ifdef WCOREDUMP ... #endif.

WIFSTOPPED(status)
returns true if the child process was stopped by delivery of a signal; this is only possible if the call was done using WUNTRACED or when the child is being traced (see ptrace(2)).

WSTOPSIG(status)
returns the number of the signal which caused the child to stop. This macro should only be employed if WIFSTOPPED returned true.

WIFCONTINUED(status)
(Since Linux 2.6.10) returns true if the child process was resumed by delivery of SIGCONT.

waitid()
The waitid() system call (available since Linux 2.6.9) provides more precise control over which child state changes to wait for.

The idtype and id arguments select the child(ren) to wait for, as follows:

idtype == P_PID
Wait for the child whose process ID matches id.

idtype == P_PGID
Wait for any child whose process group ID matches id.

idtype == P_ALL
Wait for any child; id is ignored.

The child state changes to wait for are specified by ORing one or more of the following flags in options:

WEXITED Wait for children that have terminated.

WSTOPPED Wait for children that have been stopped by delivery of a signal.

WCONTINUED Wait for (previously stopped) children that have been resumed by delivery of SIGCONT.

The following flags may additionally be ORed in options:

WNOHANG As for waitpid().

WNOWAIT Leave the child in a waitable state; a later wait call can be used to again retrieve the child status information.

Upon successful return, waitid() fills in the following fields of the siginfo_t structure pointed to by infop:

si_pid The process ID of the child.

si_uid The real user ID of the child. (This field is not set on most other implementations.)

si_signo Always set to SIGCHLD.

si_status Either the exit status of the child, as given to _exit(2)(or exit(3)), or the signal that caused the child to terminate, stop, or continue. The si_code field can be used to determine how to interpret this field.

si_code Set to one of: CLD_EXITED (child called _exit(2)); CLD_KILLED (child killed by signal); CLD_STOPPED (child stopped by signal); or CLD_CONTINUED (child continued by SIGCONT).

If WNOHANG was specified in options and there were no children in a waitable state, then waitid() returns 0 immediately and the state of the siginfo_t structure pointed to by infop is unspecified. To distinguish this case from that where a child was in a waitable state, zero out the si_pid field before the call and check for a nonzero value in this field after the call returns.

RETURN VALUE
wait(): on success, returns the process ID of the terminated child; on error, -1 is returned.

waitpid(): on success, returns the process ID of the child whose state has changed; if WNOHANG was specified and one or more child(ren) speci
fied by pid exist, but have not yet changed state, then 0 is returned. On error, -1 is returned.

waitid(): returns 0 on success or if WNOHANG was specified and no child(ren) specified by id has yet changed state; on error, -1 is
returned. Each of these calls sets errno to an appropriate value in the case of an error.

ERRORS
ECHILD (for wait()) The calling process does not have any unwaited-for children.

ECHILD (for waitpid() or waitid()) The process specified by pid (waitpid()) or idtype and id (waitid()) does not exist or is not a
child of the calling process. (This can happen for ones own child if the action for SIGCHLD is set to SIG_IGN. See also the
Linux Notes section about threads.)

EINTR WNOHANG was not set and an unblocked signal or a SIGCHLD was caught.

EINVAL The options argument was invalid.

CONFORMING TO
SVr4, 4.3BSD, POSIX.1-2001.

NOTES
A child that terminates, but has not been waited for becomes a "zombie". The kernel maintains a minimal set of information about the zombie process (PID, termination status, resource usage information) in order to allow the parent to later perform a wait to obtain information about the child. As long as a zombie is not removed from the system via a wait, it will consume a slot in the kernel process table, and if this table fills, it will not be possible to create further processes. If a parent process terminates, then its "zombie" children (if any) are adopted by init(8), which automatically performs a wait to remove the zombies.

POSIX.1-2001 specifies that if the disposition of SIGCHLD is set to SIG_IGN or the SA_NOCLDWAIT flag is set for SIGCHLD (see sigaction(2)),
then children that terminate do not become zombies and a call to wait() or waitpid() will block until all children have terminated, and then
fail with errno set to ECHILD. (The original POSIX standard left the behavior of setting SIGCHLD to SIG_IGN unspecified.) Linux 2.6 con
forms to this specification. However, Linux 2.4 (and earlier) doesnot: if a wait() or waitpid() call is made while SIGCHLD is being
ignored, the call behaves just as though SIGCHLD were not being ignored, that is, the call blocks until the next child terminates and
then returns the process ID and status of that child.

Linux Notes
In the Linux kernel, a kernel-scheduled thread is not a distinct construct from a process. Instead, a thread is simply a process that is
created using the Linux-unique clone(2) system call; other routines such as the portable pthread_create(3) call are implemented using
clone(2). Before Linux 2.4, a thread was just a special case of a process, and as a consequence one thread could not wait on the children of
another thread, even when the latter belongs to the same thread group. However, POSIX prescribes such functionality, and since Linux 2.4 a
thread can, and by default will, wait on children of other threads in the same thread group.

The following Linux-specific options are for use with children created using clone(2); they cannot be used with waitid():

__WCLONE
Wait for "clone" children only. If omitted then wait for "non-clone" children only. (A "clone" child is one which delivers no
signal, or a signal other than SIGCHLD to its parent upon termination.) This option is ignored if __WALL is also speci
fied.

__WALL (Since Linux 2.4) Wait for all children, regardless of type ("clone" or "non-clone").

__WNOTHREAD
(Since Linux 2.4) Do not wait for children of other threads in the same thread group. This was the default before Linux 2.4.

EXAMPLE
The following program demonstrates the use of fork(2) and waitpid().The program creates a child process. If no command-line argument is
supplied to the program, then the child suspends its execution using pause(2), to allow the user to send signals to the child. Otherwise,
if a command-line argument is supplied, then the child exits immediately, using the integer supplied on the command line as the exit sta
tus. The parent process executes a loop that monitors the child using waitpid(), and uses the W*() macros described above to analyze the wait
status value.

The following shell session demonstrates the use of the program:

$ ./a.out &
Child PID is 32360
[1] 32359
$ kill -STOP 32360
stopped by signal 19
$ kill -CONT 32360
continued
$ kill -TERM 32360
killed by signal 15
[1]+ Done ./a.out
$

#include <sys/wait.h>
#include <stdlib.h>
#include <unistd.h>
#include <stdio.h>

int
main(int argc, char *argv[])
{
pid_t cpid, w;
int status;

cpid = fork();
if (cpid == -1) {
perror("fork");
exit(EXIT_FAILURE);
}

if (cpid == 0) { /* Code executed by child */
printf("Child PID is %ld\n", (long) getpid());
if (argc == 1)
pause(); /* Wait for signals */
_exit(atoi(argv[1]));

} else { /* Code executed by parent */
do {
w = waitpid(cpid, &status, WUNTRACED | WCONTINUED);
if (w == -1) {
perror("waitpid");
exit(EXIT_FAILURE);
}

if (WIFEXITED(status)) {
printf("exited, status=%d\n", WEXITSTATUS(status));
} else if (WIFSIGNALED(status)) {
printf("killed by signal %d\n", WTERMSIG(status));
} else if (WIFSTOPPED(status)) {
printf("stopped by signal %d\n", WSTOPSIG(status));
} else if (WIFCONTINUED(status)) {
printf("continued\n");
}
} while (!WIFEXITED(status) && !WIFSIGNALED(status));
exit(EXIT_SUCCESS);
}
}

SEE ALSO
_exit(2), clone(2), fork(2), kill(2), ptrace(2), sigaction(2), signal(2), wait4(2), pthread_create(3), credentials(7), signal(7)

Man page - system

NAME
system - execute a shell command

SYNOPSIS
#include <stdlib.h>

int system(const char *command);

DESCRIPTION
system() executes a command specified in command by calling /bin/sh -c
command, and returns after the command has been completed. During exe‐
cution of the command, SIGCHLD will be blocked, and SIGINT and SIGQUIT
will be ignored.

RETURN VALUE
The value returned is -1 on error (e.g. fork(2) failed), and the
return status of the command otherwise. This latter return status is
in the format specified in wait(2). Thus, the exit code of the command
will be WEXITSTATUS(status). In case /bin/sh could not be executed,
the exit status will be that of a command that does exit(127).

If the value of command is NULL, system() returns nonzero if the shell
is available, and zero if not.

system() does not affect the wait status of any other children.

CONFORMING TO
C89, C99, POSIX.1-2001.

NOTES
If the _XOPEN_SOURCE feature test macro is defined, then the macros
described in wait(2) (WEXITSTATUS(), etc.) are made available when
including <stdlib.h>.

As mentioned, system() ignores SIGINT and SIGQUIT. This may make pro‐
grams that call it from a loop uninterruptible, unless they take care
themselves to check the exit status of the child. E.g.

while (something) {
int ret = system("foo");

if (WIFSIGNALED(ret) &&
(WTERMSIG(ret) == SIGINT || WTERMSIG(ret) == SIGQUIT))
break;
}

Do not use system() from a program with set-user-ID or set-group-ID
privileges, because strange values for some environment variables might
be used to subvert system integrity. Use the exec(3) family of func‐
tions instead, but not execlp(3) or execvp(3). system() will not, in
fact, work properly from programs with set-user-ID or set-group-ID
privileges on systems on which /bin/sh is bash version 2, since bash 2
drops privileges on startup. (Debian uses a modified bash which does
not do this when invoked as sh.)

In versions of glibc before 2.1.3, the check for the availability of
/bin/sh was not actually performed if command was NULL; instead it was
always assumed to be available, and system() always returned 1 in this
case. Since glibc 2.1.3, this check is performed because, even though
POSIX.1-2001 requires a conforming implementation to provide a shell,
that shell may not be available or executable if the calling program
has previously called chroot(2) (which is not specified by
POSIX.1-2001).

It is possible for the shell command to return 127, so that code is not
a sure indication that the execve(2) call failed.

If the _XOPEN_SOURCE feature test macro is defined, then the macros
described in wait(2) (WEXITSTATUS(), etc.) are made available when
including <stdlib.h>.

SEE ALSO
sh(1), signal(2), wait(2), exec(3)

Man page - stdio

NAME
stdio - standard input/output library functions

SYNOPSIS
#include <stdio.h>

FILE *stdin;
FILE *stdout;
FILE *stderr;

DESCRIPTION
The standard I/O library provides a simple and efficient buffered
stream I/O interface. Input and output is mapped into logical data
streams and the physical I/O characteristics are concealed. The func‐
tions and macros are listed below; more information is available from
the individual man pages.

A stream is associated with an external file (which may be a physical
device) by opening a file, which may involve creating a new file. Cre‐
ating an existing file causes its former contents to be discarded. If
a file can support positioning requests (such as a disk file, as
opposed to a terminal) then a file position indicator associated with
the stream is positioned at the start of the file (byte zero), unless
the file is opened with append mode. If append mode is used, it is
unspecified whether the position indicator will be placed at the start
or the end of the file. The position indicator is maintained by subse‐
quent reads, writes and positioning requests. All input occurs as if
the characters were read by successive calls to the fgetc(3) function;
all output takes place as if all characters were written by successive
calls to the fputc(3) function.

A file is disassociated from a stream by closing the file. Output
streams are flushed (any unwritten buffer contents are transferred to
the host environment) before the stream is disassociated from the file.
The value of a pointer to a FILE object is indeterminate after a file
is closed (garbage).

A file may be subsequently reopened, by the same or another program
execution, and its contents reclaimed or modified (if it can be reposi‐
tioned at the start). If the main function returns to its original
caller, or the exit(3) function is called, all open files are closed
(hence all output streams are flushed) before program termination.
Other methods of program termination, such as abort(3) do not bother
about closing files properly.

At program startup, three text streams are predefined and need not be
opened explicitly — standard input (for reading conventional input), —
standard output (for writing conventional input), and standard error
(for writing diagnostic output). These streams are abbreviated
stdin,stdout and stderr. When opened, the standard error stream is not
fully buffered; the standard input and output streams are fully
buffered if and only if the streams do not to refer to an interactive
device.

Output streams that refer to terminal devices are always line buffered
by default; pending output to such streams is written automatically
whenever an input stream that refers to a terminal device is read. In
cases where a large amount of computation is done after printing part
of a line on an output terminal, it is necessary to fflush(3) the stan‐
dard output before going off and computing so that the output will
appear.

The stdio library is a part of the library libc and routines are auto‐
matically loaded as needed by the compilers cc(1) and pc(1). The SYN‐
OPSIS sections of the following manual pages indicate which include
files are to be used, what the compiler declaration for the function
looks like and which external variables are of interest.

The following are defined as macros; these names may not be re-used
without first removing their current definitions with #undef: BUFSIZ,
EOF, FILENAME_MAX, FOPEN_MAX, L_cuserid, L_ctermid, L_tmpnam, NULL,
SEEK_END, SEEK_SET, SEE_CUR, TMP_MAX, clearerr, feof, ferror, fileno,
getc, getchar, putc, putchar, stderr, stdin, stdout. Function versions
of the macro functions feof, ferror, clearerr, fileno, getc, getchar,
putc, and putchar exist and will be used if the macros definitions are
explicitly removed.

List of Functions
Function ------ Description
-------------------------------------------------------------------
clearerr --- check and reset stream status
fclose ----- close a stream
fdopen ---- stream open functions
feof ------- check and reset stream status
ferror ----- check and reset stream status
fflush ----- flush a stream
fgetc ------ get next character or word from input stream
fgetpos --- reposition a stream
fgets ----- get a line from a stream
fileno ----- return the integer descriptor of the argument stream
fopen ----- stream open functions
fprintf ---- formatted output conversion
fpurge ---- flush a stream
fputc ----- output a character or word to a stream
fputs ----- output a line to a stream
fread ---- binary stream input/output
freopen --- stream open functions
fscanf --- input format conversion
fseek --- reposition a stream
fsetpos --- reposition a stream
ftell --- reposition a stream
fwrite --- binary stream input/output
getc --- get next character or word from input stream
getchar --- get next character or word from input stream
gets --- get a line from a stream
getw --- get next character or word from input stream
mktemp --- make temporary filename (unique)
perror --- system error messages
printf --- formatted output conversion
putc --- output a character or word to a stream
putchar --- output a character or word to a stream
puts --- output a line to a stream
putw --- output a character or word to a stream
remove --- remove directory entry
rewind --- reposition a stream
scanf --- input format conversion
setbuf --- stream buffering operations
setbuffer --- stream buffering operations
setlinebuf --- stream buffering operations
setvbuf --- stream buffering operations
sprintf --- formatted output conversion
sscanf --- input format conversion
strerror --- system error messages
sys_errlist --- system error messages
sys_nerr --- system error messages
tempnam --- temporary file routines
tmpfile --- temporary file routines

tmpnam --- temporary file routines
ungetc --- un-get character from input stream
vfprintf --- formatted output conversion
vfscanf --- input format conversion
vprintf --- formatted output conversion
vscanf --- input format conversion
vsprintf --- formatted output conversion
vsscanf --- input format conversion

CONFORMING TO
The stdio library conforms to C89.

SEE ALSO
close(2), open(2), read(2), write(2), stdout(3), unlocked_stdio(3)

Send SMS for Free