Re: [dev] New utility "when"

From: Andrew Gwozdziewycz <>
Date: Thu, 12 Dec 2013 10:56:38 -0500

On Thu, Dec 12, 2013 at 10:32 AM, Truls Becken <> 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!

Received on Thu Dec 12 2013 - 16:56:38 CET

This archive was generated by hypermail 2.3.0 : Thu Dec 12 2013 - 17:00:14 CET