On Thu, Dec 12, 2013 at 5:16 AM, Truls Becken <truls.becken_AT_gmail.com> wrote:
> On 2013-12-12 at 04:54, Andrew Gwozdziewycz wrote:
>
>> On 2013-12-11 at 19:08, Fernando C.V. wrote:
>>
>>> Sounds like a little nice useful utility, even thoguh I don't like
>>> that the commands have to be passed "quoted", as arguments just like
>>> that. Not sure if there's a much better way to do it, though.
>>
>> I was thinking about separating commands with ";" (I thought about --,
>> but lots of commands actually use it) which would of course need to be
>> escaped in the same way find(1) ends -exec and friends. However, I've
>> used find in the past for just this type of thing, so maybe it's not
>> the right choice, but the full command can always just be quoted --
>> you'd have to to use pipes anyway, which is certainly common.
>
> There is another way, as hinted at the beginning of the thread.
>
> On 2013-12-11 at 18:15, Dimitris Zervas wrote:
>
>> Instead of passing a second argument, you could return zero and and it in shell
>> when "command" && echo "yup! :D"
>
> Unless you want "when" to stay running and finally return the exit code of the
> long running process.
>
> If you go this route, "when" could consume arguments from the beginning of argv,
> and then pass the rest of argv to execvp.
>
> Your ssh example becomes:
>
> when -t ssh user_AT_host && xmessage 'Connected'
I think I'm missing something. Are you suggesting that the shell
handle the command after the &&? Or you let the subshell I spawn do
it? 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''"
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.
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.
But, I'm pretty sure you had other intentions, and I'm not following
your thinking. Could you clarify your point?
--
http://apgwoz.com
Received on Thu Dec 12 2013 - 13:28:44 CET