«

Can I use the return value provided to exit() for my own purposes?

(This is so that I can pick up the exit-value when I invoke the program from
another. BTW what's the best way of invoking a program under Linux so that
this value can be retrieved?)

--
Bartc

In <OY9Ts.231147$7> "BartC" <> writes:

> Can I use the return value provided to exit() for my own purposes?

Yes. However program exit codes are fairly limited in range; I believe
you can only use values from 0 to 255.

> (This is so that I can pick up the exit-value when I invoke the program from
> another. BTW what's the best way of invoking a program under Linux so that
> this value can be retrieved?)

From a shell, the exit status of the previous command is typically
available from the $? variable.

If you're invoking a program from another program, the invoking function
(typically something like system("command")) will usually return the exit
status. Although, in this case, the returned value may be a combination
of the program's exit command and the shell that was spawned to run it;
you may have to separate out the two values.

--
John Gordon A is for Amy, who fell down the stairs
B is for Basil, assaulted by bears
-- Edward Gorey, "The Gashlycrumb Tinies"

John Gordon <> writes:
> In <OY9Ts.231147$7> "BartC" <> writes:
>
>> Can I use the return value provided to exit() for my own purposes?
>
> Yes. However program exit codes are fairly limited in range; I believe
> you can only use values from 0 to 255.

That's true for Unix/Linux/POSIX systems. It may or may not be true for
other systems.

The C standard says that exit() takes an int argument. It causes the
program to terminate and return a implementation-defined status to
the environment (0 or EXIT_SUCCESS should return a status denoting
success, and EXIT_FAILURE should return a status denoting failure).

>> (This is so that I can pick up the exit-value when I invoke the program from
>> another. BTW what's the best way of invoking a program under Linux so that
>> this value can be retrieved?)
>
> From a shell, the exit status of the previous command is typically
> available from the $? variable.

That's for the Bourne shell and shells derived from it. csh and tcsh
use $status.

> If you're invoking a program from another program, the invoking function
> (typically something like system("command")) will usually return the exit
> status. Although, in this case, the returned value may be a combination
> of the program's exit command and the shell that was spawned to run it;
> you may have to separate out the two values.

The documentation for the system() function for your environment will
tell you how to interpret the result returned by system(). On Unix-like
systems, if a program invoked by system() calls exit(N), system() will
return N<<8. system() returns other values if the program terminated
due to a signal.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

"BartC" <> writes:

> Can I use the return value provided to exit() for my own purposes?
>
> (This is so that I can pick up the exit-value when I invoke the program from
> another. BTW what's the best way of invoking a program under Linux so that
> this value can be retrieved?)

Under Linux (and POSIX), the exit value has no predefined meaning (but a
limited range, and conventions). If you control the whole chain, you're
probably invoking from a parent process with fork/exec*. Then the parent
can use wait() to retrieve the exit code (after having checked whether
the child terminated by calling exit()). If you use higher-level
interfaces to launch the program (e.g., system()), you may loose some
accuracy

-- Alain.

Alain Ketterlin <> writes:
> "BartC" <> writes:
>> Can I use the return value provided to exit() for my own purposes?
>>
>> (This is so that I can pick up the exit-value when I invoke the program from
>> another. BTW what's the best way of invoking a program under Linux so that
>> this value can be retrieved?)
>
> Under Linux (and POSIX), the exit value has no predefined meaning (but a
> limited range, and conventions).

exit(0) and exit(EXIT_SUCCESS) are well defined, both by C and by
POSIX, as an indication of success. exit(EXIT_FAILURE) denotes
failure. (EXIT_FAILURE is typically 1 on POSIX systems, but the
POSIX standard doesn't require that.)

> If you control the whole chain, you're
> probably invoking from a parent process with fork/exec*. Then the parent
> can use wait() to retrieve the exit code (after having checked whether
> the child terminated by calling exit()). If you use higher-level
> interfaces to launch the program (e.g., system()), you may loose some
> accuracy

The value returned by system() is well defined for POSIX; it's the same
as the result returned by waitpid(). If you evaluate

system("some_command");

and some_command calls exit(42), you can reliably get the value 42 from
the result returned by system().

Some specific commands define meanings for exit statuses other than 0 or
1. For example, the grep command exits with a status of 0 on success, 1
on failure, and 2 on error. The curl command defines 88 different error
codes, but that's an extreme case.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

On Thu, 14 Feb 2013 16:21:20 -0800, Keith Thompson wrote:

> The value returned by system() is well defined for POSIX; it's the same as
> the result returned by waitpid(). If you evaluate
>
> system("some_command");
>
> and some_command calls exit(42), you can reliably get the value 42 from
> the result returned by system().

Note that if execve() failed to execute the shell, the result is the same
as a program which does exit(127), so you probably shouldn't use 127 as
one of your program's exit codes.

Also, note that you need to use the macros from <sys/wait.h> to extract
the actual exit status (and to determine if there is an exit status to
extract, as opposed to e.g. a signal). The value returned from waitpid(),
system() etc combines various pieces of information into a single integer.

BartC wrote:

> Can I use the return value provided to exit() for my own purposes?

As others have pointed out, the answer is platform-dependent.

> (This is so that I can pick up the exit-value when I invoke the program from
> another. BTW what's the best way of invoking a program under Linux so that
> this value can be retrieved?)

Try comp.unix.programmer or comp.os.linux.development.apps

Keith Thompson <kst-> writes:

> Alain Ketterlin <> writes:
>> "BartC" <> writes:
>>> Can I use the return value provided to exit() for my own purposes?
>>>
>>> (This is so that I can pick up the exit-value when I invoke the
>>> program from another. BTW what's the best way of invoking a program
>>> under Linux so that this value can be retrieved?)
>>
>> Under Linux (and POSIX), the exit value has no predefined meaning (but a
>> limited range, and conventions).
>
> exit(0) and exit(EXIT_SUCCESS) are well defined, both by C and by
> POSIX, as an indication of success. exit(EXIT_FAILURE) denotes
> failure. (EXIT_FAILURE is typically 1 on POSIX systems, but the
> POSIX standard doesn't require that.)

See, a value of 42 has no predefined meaning.

>> If you control the whole chain, you're
>> probably invoking from a parent process with fork/exec*. Then the parent
>> can use wait() to retrieve the exit code (after having checked whether
>> the child terminated by calling exit()). If you use higher-level
>> interfaces to launch the program (e.g., system()), you may loose some
>> accuracy
>
> The value returned by system() is well defined for POSIX; it's the same
> as the result returned by waitpid().

This is wrong if system() returns 127.

[...]
> Some specific commands define meanings for exit statuses other than 0 or
> 1. For example, the grep command exits with a status of 0 on success, 1
> on failure, and 2 on error. The curl command defines 88 different error
> codes, but that's an extreme case.

It seems obvious to me that BartC needs something like that.

-- Alain.

On 02/15/2013 07:51 AM, Alain Ketterlin wrote:
> Keith Thompson <kst-> writes:
>
>> Alain Ketterlin <> writes:
....
>>> Under Linux (and POSIX), the exit value has no predefined meaning (but a
>>> limited range, and conventions).
>>
>> exit(0) and exit(EXIT_SUCCESS) are well defined, both by C and by
>> POSIX, as an indication of success. exit(EXIT_FAILURE) denotes
>> failure. (EXIT_FAILURE is typically 1 on POSIX systems, but the
>> POSIX standard doesn't require that.)
>
> See, a value of 42 has no predefined meaning.

But a value of 0 does. Therefore, saying that "the exit value has no
predefined meaning", without restricting that statement to a particular
range of exit values, was incorrect.

Alain Ketterlin <> writes:
> Keith Thompson <kst-> writes:
>> Alain Ketterlin <> writes:
>>> "BartC" <> writes:
>>>> Can I use the return value provided to exit() for my own purposes?
>>>>
>>>> (This is so that I can pick up the exit-value when I invoke the
>>>> program from another. BTW what's the best way of invoking a program
>>>> under Linux so that this value can be retrieved?)
>>>
>>> Under Linux (and POSIX), the exit value has no predefined meaning (but a
>>> limited range, and conventions).
>>
>> exit(0) and exit(EXIT_SUCCESS) are well defined, both by C and by
>> POSIX, as an indication of success. exit(EXIT_FAILURE) denotes
>> failure. (EXIT_FAILURE is typically 1 on POSIX systems, but the
>> POSIX standard doesn't require that.)
>
> See, a value of 42 has no predefined meaning.

Certainly -- but 0 does. Your statement that "the exit value has no
predefined meaning" is mostly correct, but incomplete.

[...]

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"