Need help in 'at' command

Hello,
While using the 'at' command it works when I pipe the command I
want to schedule to 'at'

So
$ date | at now + 2 minutes works well.
but
a) $ ls -l | at now + 2 minutes accepts the job, but gives a very
strange output in /var/spool/mail/root....

b) $killall <exec name> | at now + 2 minutes results in killall
getting executed immediately...

Am I missing something while using 'at' with those commands which have
some parameters/switches.
Also how do I get the output on the screen instead of .../mail/root..
Do I use some other command to schedule jobs using shell scripts.

Thanks,
R C

R C V wrote:
> Hello,
> While using the 'at' command it works when I pipe the command I
> want to schedule to 'at'
>
> So
> $ date | at now + 2 minutes works well.
> but
> a) $ ls -l | at now + 2 minutes accepts the job, but gives a very
> strange output in /var/spool/mail/root....
>
> b) $killall <exec name> | at now + 2 minutes results in killall
> getting executed immediately...
>
> Am I missing something while using 'at' with those commands which have
> some parameters/switches.
> Also how do I get the output on the screen instead of .../mail/root..
> Do I use some other command to schedule jobs using shell scripts.
>
> Thanks,
> R C

a) echo "ls -l" | at now + 2 minutes works for me
b) echo "killall foobar | at now + 2 minutes" works for me too

It's all in the echo...

R C V wrote:
> Hello,
> While using the 'at' command it works when I pipe the command I
> want to schedule to 'at'
>
> So
> $ date | at now + 2 minutes works well.
> but
> a) $ ls -l | at now + 2 minutes accepts the job, but gives a very
> strange output in /var/spool/mail/root....
>
> b) $killall <exec name> | at now + 2 minutes results in killall
> getting executed immediately...
>
> Am I missing something while using 'at' with those commands which have
> some parameters/switches.
> Also how do I get the output on the screen instead of .../mail/root..
> Do I use some other command to schedule jobs using shell scripts.
>
> Thanks,
> R C

You're actually inserting the output of 'ls -l' and 'killall' into at.
It kinda makes sense at does not understand it.
The pipe '|' passes STDOUT of one process through to STDIN of another
process.

Output of at is sent to the mail spooler because at does not run in an
attached TTY. It's a service that runs in the background, so it cannot
output stuff to the TTY from which you inserted the task.

But erm. If you really just wat to delay stuff a bit, you might try
using 'sleep' instead.

'sleep 120 && ls -l'

-R-

Jurgen Haan wrote:
> R C V wrote:

[cut]

> But erm. If you really just wat to delay stuff a bit, you might try
> using 'sleep' instead.
>
> 'sleep 120 && ls -l'
>
> -R-

Not quite the same. at lets you log out (or close the console window),
whereas sleep requires you to stay logged on or else it gets killed.

/peter

Peter Ludikovsky wrote:
> Jurgen Haan wrote:
>> R C V wrote:
>
> [cut]
>
>> But erm. If you really just wat to delay stuff a bit, you might try
>> using 'sleep' instead.
>>
>> 'sleep 120 && ls -l'
>>
>> -R-
>
> Not quite the same. at lets you log out (or close the console window),
> whereas sleep requires you to stay logged on or else it gets killed.
>
> /peter

That's true, but that also kinda summarizes the reason why output from
AT is not possible. Ofc, 'screen' can be used for sleep.

-R-

> Not quite the same. at lets you log out (or close the console window),
> whereas sleep requires you to stay logged on or else it gets killed.

Jurgen Haan <(E-Mail Removed)> wrote:
> That's true, but that also kinda summarizes the reason why output from
> AT is not possible

So redirect your "at" command to write to a file
Chris

Chris Davies wrote:
>> Not quite the same. at lets you log out (or close the console window),
>> whereas sleep requires you to stay logged on or else it gets killed.
>
> Jurgen Haan <(E-Mail Removed)> wrote:
>> That's true, but that also kinda summarizes the reason why output from
>> AT is not possible
>
> So redirect your "at" command to write to a file
> Chris

Yup... Not a bad plan, or wrap your command in a script.