Samuel Holland wrote:
>>> On Dec 12, 2013, at 4:10 PM, "Fernando C.V."
>wrote:
>>> On Thu, Dec 12, 2013 at 10:49 PM, Fernando C.V.
>wrote:
>>> This way could do something like:
>>>
>>> $ when -t ssh host
xmessage DONE!
>>
>> Well... even if you didn't prompt it to the user interactively
On 2013-12-13, at 00:48, Samuel Holland wrote:
> And if you only need simple messages, then there's nothing wrong with having
> to
> quote the "on success" command:
>
> $ when -t -c "xmessage Success"
>
> The advantage of specifying the message command as an argument (as opposed to
> &&) is t
>> On Dec 12, 2013, at 4:10 PM, "Fernando C.V." wrote:
>> On Thu, Dec 12, 2013 at 10:49 PM, Fernando C.V. wrote:
>> This way could do something like:
>>
>> $ when -t ssh host
>>> xmessage DONE!
>
> Well... even if you didn't prompt it to the user interactively, it
> would still be nice for alia
On Thu, Dec 12, 2013 at 10:49 PM, Fernando C.V. wrote:
> This way could do something like:
>
> $ when -t ssh host
>> xmessage DONE!
Well... even if you didn't prompt it to the user interactively, it
would still be nice for aliases.
Probably most of the time you just want to get notfications:
$
An alternative would be to read one of the commands from stdin.
This way could do something like:
$ when -t ssh host
> xmessage DONE!
You won't get tab-completion and other interactive fancyness, but it
won't be missed for simple notification commands.
--
Fernando
consider submitting when to the moreutils package
On 11 December 2013 11:31, Andrew Gwozdziewycz wrote:
> Hey all,
>
> If you've used watch(1) you know that running a command repeatedly is
> useful. What I wished for yesterday though, is for a mechanism that
> notified me when a command succeeded
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 recognize
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.
On Thu, Dec 12, 2013 at 5:16 AM, Truls Becken 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
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
On Wed, Dec 11, 2013 at 11:53 PM, Patrick <201009-suckl...@haller.ws> wrote:
> On 2013-12-11 22:46, Andrew Gwozdziewycz wrote:
>> On Wed, Dec 11, 2013 at 6:02 PM, Charlie Kester
>> wrote:
>> > Maybe I'm have a dumb day (it happens, all too often), but is there a
>> > way to get the exit code of t
On 2013-12-11 22:46, Andrew Gwozdziewycz wrote:
> On Wed, Dec 11, 2013 at 6:02 PM, Charlie Kester wrote:
> > Maybe I'm have a dumb day (it happens, all too often), but is there a
> > way to get the exit code of the longrunningscript in case it fails
> > *after* the timebomb goes off?
> There will
On Wed, Dec 11, 2013 at 7:08 PM, Fernando C.V. wrote:
> On Thu, Dec 12, 2013 at 12:56 AM, Fernando C.V. wrote:
>> $ { ssh user@host &; } && xmessage connected
>
> Whoops, it's:
>
> $ { ssh user@host & } && xmessage connected
>
> Btw, what "when" does is that it considers that the program is r
On Wed, Dec 11, 2013 at 6:02 PM, Charlie Kester wrote:
> On Wed 11 Dec 2013 at 13:30:11 PST Andrew Gwozdziewycz wrote:
>>
>>
>> Using -t, you can notify when the longrunningscript is actually still
>> running. So it's very useful if you have something that fails
>> repeatedly and get an alert when
On Thu, 12 Dec 2013, Fernando C.V. wrote:
On Wed, Dec 11, 2013 at 10:36 PM, Rob wrote:
[local-machine %] ssh user@host & && xmessage connected
[ssh-machine %] ...
`xmessage connected' will be executed even though ssh hasn't exit(0)'d
yet.
bash: syntax error near unexpected token `&&'
You pr
On Thu, Dec 12, 2013 at 12:56 AM, Fernando C.V. wrote:
> $ { ssh user@host &; } && xmessage connected
Whoops, it's:
$ { ssh user@host & } && xmessage connected
Btw, what "when" does is that it considers that the program is running
successfully if it didn't exit with error after X seconds.
On Wed, Dec 11, 2013 at 10:36 PM, Rob wrote:
> [local-machine %] ssh user@host & && xmessage connected
> [ssh-machine %] ...
>
> `xmessage connected' will be executed even though ssh hasn't exit(0)'d
> yet.
bash: syntax error near unexpected token `&&'
You probably meant this:
$ { ssh user@ho
On Wed 11 Dec 2013 at 13:30:11 PST Andrew Gwozdziewycz wrote:
Using -t, you can notify when the longrunningscript is actually still
running. So it's very useful if you have something that fails
repeatedly and get an alert when it actually starts.
Maybe I'm have a dumb day (it happens, all too
Please lets just stay on topic. Make another thread to discuss about it.
On Thu, Dec 12, 2013 at 12:04 AM, koneu wrote:
> Markus Teich wrote:
>> koneu wrote:
>> > HELL, why use an _anything_ that is not scriptable?
>>
>> Did you notice dwm is not scriptable?
>
> Unless you consider xdotool scrip
Markus Teich wrote:
> koneu wrote:
> > HELL, why use an _anything_ that is not scriptable?
>
> Did you notice dwm is not scriptable?
Unless you consider xdotool scripting that is true, yes.
Luckily, there is wmii (even though wmii is a real mess).
koneu wrote:
> HELL, why use an _anything_ that is not scriptable?
Did you notice dwm is not scriptable?
--Markus
Well, I think that this is off-topic. I just said an idea that I had.
On Wed, 11 Dec 2013, Andrew Gwozdziewycz wrote:
On Wed, Dec 11, 2013 at 4:23 PM, Calvin Morrison wrote:
I'm confused how this is different than the usual
longrunningscript.sh && generic_notify_command
Could you clarify?
Using -t, you can notify when the longrunningscript is actually still
Dimitris Zervas wrote:
> Totally agree...
> BTW: I was also thinking about a new, suckless shell. Do we really
This is getting boring...
http://doc.cat-v.org/plan_9/4th_edition/papers/rc
http://mirbsd.de/mksh
> No more "scripting". Just some cool features (I really like some zsh features)
No scr
On Wed, Dec 11, 2013 at 4:23 PM, Calvin Morrison wrote:
> I'm confused how this is different than the usual
>
> longrunningscript.sh && generic_notify_command
>
> Could you clarify?
Using -t, you can notify when the longrunningscript is actually still
running. So it's very useful if you have some
I'm confused how this is different than the usual
longrunningscript.sh && generic_notify_command
Could you clarify?
On 11 December 2013 11:31, Andrew Gwozdziewycz wrote:
> Hey all,
>
> If you've used watch(1) you know that running a command repeatedly is
> useful. What I wished for yesterday th
Totally agree...
BTW: I was also thinking about a new, suckless shell. Do we really
need all the bash overhead?
No more "scripting". Just some cool features (I really like some zsh features)
On Wed, Dec 11, 2013 at 9:17 PM, sin wrote:
> On Wed, Dec 11, 2013 at 08:25:32PM +0200, Dimitris Zervas wr
On Wed, Dec 11, 2013 at 08:25:32PM +0200, Dimitris Zervas wrote:
> Suckless does not have tools that don't exist or can't be created with
> bash. It has some bash scripts implemented in C, something
> disgustingly performance efficient.
Let's stay away from bash, shall we? :D
Suckless does not have tools that don't exist or can't be created with
bash. It has some bash scripts implemented in C, something
disgustingly performance efficient.
On Wed, Dec 11, 2013 at 8:21 PM, Andrew Gwozdziewycz wrote:
> On Wed, Dec 11, 2013 at 1:14 PM, Patrick <201009-suckl...@haller.ws>
On Wed, Dec 11, 2013 at 1:14 PM, Patrick <201009-suckl...@haller.ws> wrote:
> On 2013-12-11 12:21, Andrew Gwozdziewycz wrote:
>> Yes. You can do exactly that. But you *can't* do:
Sorry, I shouldn't have said *can't*, since I knew it was *possible.*
>> when -t "ssh user@host" "xmessage 'Connec
On 2013-12-11 12:21, Andrew Gwozdziewycz wrote:
> Yes. You can do exactly that. But you *can't* do:
> when -t "ssh user@host" "xmessage 'Connected'"
Time to rock the IPC?
#!/bin/bash
MAGIC=5
system_time_epoch() { date +%s; }
file_time_mod() { stat --printf='%Y' $1 ; }
file_age() { echo $(( $
On Wed, Dec 11, 2013 at 12:36 PM, Manolo MartÃnez
wrote:
> fish has
>
> $ ssh user@host; and xmessage 'Connected'; or xmessage 'Problems!'
>
> Is this what you try to do with "when", or am I missing something? (Apart
> from the fact that many of you consider that fish sucks).
My problem with fish
fish has
$ ssh user@host; and xmessage 'Connected'; or xmessage 'Problems!'
Is this what you try to do with "when", or am I missing something? (Apart
from the fact that many of you consider that fish sucks).
Manolo
On 12/11/13 at 07:32pm, Dimitris Zervas wrote:
> @nicholas: Sorry, I didn't see
@nicholas: Sorry, I didn't see your email!
@Andrew:oh, that's nice!
On Wed, Dec 11, 2013 at 7:21 PM, Andrew Gwozdziewycz wrote:
> On Wed, Dec 11, 2013 at 12:15 PM, Nicholas Hall wrote:
>> On Wed, Dec 11, 2013 at 10:31 AM, Andrew Gwozdziewycz
>> wrote:
>>> I wondered if I could do it in shell,
On Wed, Dec 11, 2013 at 12:15 PM, Nicholas Hall wrote:
> On Wed, Dec 11, 2013 at 10:31 AM, Andrew Gwozdziewycz wrote:
>> I wondered if I could do it in shell, but figured it might be too
>> tricky to do concisely
>
> $ while ! command; do continue; done; xmessage 'returned truthy'
>
Yes. You can
well, you could implement this with shell while loop (while not
(command) do; done), but it's great to have this as utility.
Instead of passing a second argument, you could return zero and and it in shell
when "command" && echo "yup! :D"
On Wed, Dec 11, 2013 at 6:59 PM, Andrew Gwozdziewycz wrote:
On Wed, Dec 11, 2013 at 10:31 AM, Andrew Gwozdziewycz wrote:
> I wondered if I could do it in shell, but figured it might be too
> tricky to do concisely
$ while ! command; do continue; done; xmessage 'returned truthy'
On Wed, Dec 11, 2013 at 11:55 AM, Patrick <201009-suckl...@haller.ws> wrote:
> On 2013-12-11 11:31, Andrew Gwozdziewycz wrote:
>> Maybe one of you will stop laughing long enough to find it useful.
>
> So why isn't this a standard unix utility?
I'm certainly not smart enough to know why people do o
On 2013-12-11 11:31, Andrew Gwozdziewycz wrote:
> Maybe one of you will stop laughing long enough to find it useful.
So why isn't this a standard unix utility?
Hey all,
If you've used watch(1) you know that running a command repeatedly is
useful. What I wished for yesterday though, is for a mechanism that
notified me when a command succeeded, but is long running -- say an
ssh session.
I wondered if I could do it in shell, but figured it might be too
tri
40 matches
Mail list logo
