On Thu, Dec 12, 2013 at 10:32 AM, Truls Becken <truls.bec...@gmail.com> wrote: > On 2013-12-12, at 13:28, Andrew Gwozdziewycz wrote: > >> Are you suggesting that the shell handle the command after the &&? >> Or you let the subshell I spawn do it? > > The shell would handle the command after &&. The command after recognized > arguments is handled using fork + execvp, without a subshell. > >> For the -z mode (default) that could totally work. So, for example: >> >> when cat /file/that/will/eventually/exist && xmessage 'exists' >> >> Instead of running "/bin/sh -c 'cat /file/that/will/eventually/exist'" >> until the exit status is 0 and then running "/bin/sh xmessage >> 'exists'" you just repeatedly run "/bin/sh -c 'cat >> /file/that/will/eventually/exist && xmessage 'exists''" > > Yes, repeat cat until it succeeds. Then return 0 to the shell. > >> I agree that this works, but it's also incorrect because the second >> command must exit with 0, or it'll keep running. I've made the call >> that I don't care about what happens with the second command, only the >> first, and for that reason, that method produces the incorrect >> behavior. > > Huh? The when command exits once, letting the shell call xmessage once. > >> This doesn't work with -t for the simple reason that if you run >> everything after the when token via '/bin/sh -c ...' && waits for the >> first command to finish, which as stated previously is incorrect. > > No. The shell will only let "when" see the stuff before &&. > >> But, I'm pretty sure you had other intentions, and I'm not following >> your thinking. Could you clarify your point? > > > In my mind, when would simply: > > 1) Read all leading elements of argv that start with "-".
It does this currently. > 2) Repeatedly fork and exec argv (which now points to a command and its > arguments). Ah, ok. So let the shell do the -z mode. This makes sense. > 3) Return 0 when the child process returns 0, or in the case of -t when the > child process runs long enough. Currently in -t, it waits for the child to finish and returns what the child does (as of last night). > The first part is known as chain loading or Bernstein loading, and is done by > programs such as nice, env, sudo, etc. The only issue I see in the context of > "when" is that the repeated child process will be orphaned in -t mode. I'm calling waitpid to avoid orphaning (though, admittedly, I haven't checked ps to verify) > Perhaps my version should be called "retry" rather than "when". Yeah, retry is a good name for this. Maybe I'll extract the functionality from when later and call it retry. That is, unless you want to write it yourself. Thanks for the suggestions! -- http://apgwoz.com
