Talk:Exec (system call)

Translation mode and further questions

• The exec calls do not preserve the translation modes of open files.
  • What is a translation mode of a file?
• The article currently talks about the return value of the exec* functions. Shouldn't it say exit status instead? Or can we say: from the perspective of the exiting process an exit status is returned, while from the parent process this looks like a return value?
• [With some exec* commands] the child process inherits the parent's environment.
  • Is it correct to speak of parent and child in the context of exec? With the fork command, we get two distinct processes, one being called parent and one being called child. But with exec, the process "creating the child" will be the child itself - the parent does not exist anymore (put in another way: the parent transforms to a child). So I feel it is a misnomer to talk about parent and child in exec contexts, especially when one considers that there usually (always?) is a parent to the process that executes the exec command. Maybe an expert can clarify the nomenclature?

Thanks, --Abdull (talk) 09:52, 25 July 2008 (UTC)

• I’m guessing translation mode refers to the DOS and Windows text-mode CRLF newline translation. In fact it looks like that text is copied straight from the exec functions entry in Microsoft’s MSDN. Probably not even worth mentioning in the article.
• The return value of the function call is only relevant if it fails to replace the process. I’ll try and make that clearer.
• Yes it is better to talk about the new and old processes with exec, rather than parent and child, I think. Somebody must have already fixed this.

Vadmium (talk) 08:47, 6 August 2011 (UTC).

What is a translation mode of a file? It's something no longer mentioned in the article, so that's been fixed.

The article currently talks about the return value of the exec* functions. Currently, it says:

A successful call replaces the current process image, so it cannot return anything to the program that made the call. Processes do have an exit status, but that value is collected by the parent process.

and

If the call fails, the return value is always -1, and errno is set to an appropriate value.

which accurately describe the behavior of exec-family call.

Is it correct to speak of parent and child in the context of exec? The article no longer does that. Guy Harris (talk) 23:30, 11 July 2025 (UTC)

Disputed - new process inheriting parent's settings when envp is null

The entry states the following: If envp itself is null, the new process inherits the current environment settings.

This is not true on a variety of systems (Linux comes to mind), and this can be trivially demonstrated. Furthermore, every POSIX/*nix source I've searched with regards to the exec family of functions (including Opengroup.org, kernel.org, [http://www.amazon.com/Advanced-Programming-UNIX-Environment-2nd/dp/0201433079/ref=sr_1_1?s=books&ie=UTF8&qid=1357652759&sr=1-1&keywords=advanced+programming+in+the+unix+environment Steven's Advanced Programming in the UNIX Environment], and [http://www.amazon.com/Professional-Linux-Kernel-Architecture-Programmer/dp/0470343435/ref=sr_1_1?s=books&ie=UTF8&qid=1357652832&sr=1-1&keywords=linux+architecture Mauerer's Professional Linux Kernel Architecture]) does not mention that type of behavior.

If there are systems whose implementation of exec does just that, they should be listed (with a caveat that this is no the typical behavior.) — Preceding unsigned comment added by Luis.a.espinal (talk • contribs) 13:49, 8 January 2013 (UTC)

The article no longer states that. Guy Harris (talk) 23:31, 11 July 2025 (UTC)

Disputed - Does only fcntl set FD_CLOEXEC?

See https://en.wikipedia.org/w/index.php?title=Exec_(system_call)&oldid=prev&diff=777115010

Since User:Schily just reverted my edit without explanation: please explain your rationale. The FD_CLOEXEC flag can be set by other means than by fcntl, e.g. by the openat call. Do you disagree with that. Best regards –Jérôme (talk) 09:29, 25 April 2017 (UTC)

Ah, I see that you have added a note about O_CLOEXEC; that's much better from my point of view. Cheers –Jérôme (talk) 09:31, 25 April 2017 (UTC)

O_CLOEXEC is a recent (I remember when we added it ;-) enhancement to allow to set it atomically. It is a non-clean flag as it sets another flag at a different location in the kernel and as it cannot be read back by fcntl(fd, GETFL). Schily (talk) 10:09, 25 April 2017 (UTC)

The first sentence.

Hi,
Imagine a reader with limited knowledge of Linux and no knowledge of exec reading this article in hope of understanding the purpose of exec. At 2025.04.18 the first sentence is "In computing, exec is a functionality of an operating system that runs an executable file in the context of an already existing process, replacing the previous executable." The reader is likely to wonder, "Which functionality and what previous executable?"

Someone please write an introductory sentence to make the purpose of exec evident to a Linux novice. Please think about the meaning of the words and the sentence. Think of the task as programming; in English rather than in C. Good code is understandable!

Thx, ... PeterEasthope (talk) 13:59, 18 April 2025 (UTC)

...and that doesn't imply that the exec calls are a Linux invention; they're present in all Unix-like systems, including the ones that existed long before Linux was created. Guy Harris (talk) 17:45, 19 April 2025 (UTC)

Furthermore, the article also talks about calls that perform similar functions on non-Unix-like systems, although spawn is not equivalent to exec - at least on operating systems that support multitasking, the former creates a new process to run the program, whereas exec causes the current process to run a new program, and a combination of fork that creates a new process running the same program and an exec in the new process is used for the spawn function.

I.e., the rest of the sentences could use some work as well. Guy Harris (talk) 17:53, 19 April 2025 (UTC)