I'm developing a simple shell for an assignment. I read a command entered by the user, tokenize it, fork(), then in the child process use execvp() to execute the command in the background.
The problem is I need to implement a history feature that records valid commands. The only way I know to check if the string the user enters is a valid command is to check if execvp() returns -1. This is a fine way to check for an invalid command, but since the call to execvp() happens in the child process and the data structure I use for my history is copied to the child on fork() rather than shared, I can't update the history using the results of the execvp() within the child (since the history structure is a copy any changes I make won't be reflected in the parent's copy of the structure).
Is there any way I can check if execvp() would return -1 without actually calling it (i.e. before or after the fork)? If I could figure out a way to do that I'd be able to verify in the parent processes whether or not execvp() will succeed and use that info to update my history data structure properly.
What you are asking for is a system call which would let you implement the classic check-before-do race condition.
In that error, a program verifies whether an action is possible and then performs the action, leaving open the possibility that some external event will happen just after the check which makes the action illegal.
So then the action fails, even though the program checked that it was possible. This often results in chaos.
You should avoid this antipattern, and the system API should help by not tempting you with system calls you would only use to get yourself into trouble. In this case, the system does the right thing; there is no such API.
The parent process must eventually retrieve the exit status of the child. That is the moment you need to update (or not) the history. If a failed execvp causes the child to exit() with a failure status code, the parent will notice the failure and can react by not adding the command line to the history.
To retrieve the status code of the child process, the parent will call wait or waitpid. For synchronous execution, the parent will likely do so immediately; for asynchronous execution, the parent will do so when it receives a SIGCHLD signal. But it is imperative that the parent does this, to avoid zombie processes.
In the case of asynchronous execution, it is not possible to use this strategy to avoid putting invalid commands into the history, because asynchronous commands must be recorded in the history when they are started. For a similar reason, Posix shells also count asynchronous execution of a command as successful, even if the command is invalid.
While this exercise undoubtedly has pedagogic value (as I hope this answer demonstrates), it is actually a terrible way of doing shell history. While shell users occasionally use history to retrieve and re-execute successful commands, the history feature is much more useful to retrieve and edit an unsuccessful command. It's intensely annoying to not be able to make corrections from a history feature. (Many Android applications exhibit precisely this annoying flaw with search history: after a search which gives you undesired results, you can retrieve the incorrect search and rerun it, but not modify it. I'm glad to say that things have improved since my first Android.)