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).

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)

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)