Re: [dev] New utility "when"

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

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