[Shr-User] at command-line tools for SHR-T ?

[Łukasz Pankowski]

Olivier Berger <oberger at ouvaton.org> writes:

> Hi.
>
> Thanks for the additional details, but I'm still not completely sure I
> get it right :
>
> lukpank at o2.pl (Łukasz Pankowski) writes:
>
>> Olivier Berger <oberger at ouvaton.org> writes:
>>
>>>
>>> Is there any piece of docs somewere about this ?
>>>
>>> Any plans to implement these at* commands ?
>>>
>>> I noticed that once the script is executed, it remains in place... is it
>>> safe to remove itiself at the end of the script ?
>>
>> That is right, you are *responsible* to remove the script when
>> unnecessary.  It will run once more, if you/other program write to
>> trigger file during the execution,
>
> You mean... if it happens during the same second ? Or once again because
> it is older than current time ? I'm not sure I understand right.

when atd is awoken by
a) time to execute next job (rtc interrupt)
a) other process writing to the trigger file
it does two thinks:
1. runs all of the past jobs
2. schedules to wait for the next future job

so if you write to the triger file while your script is running the
script will be reexecuted by atd (as it has timestamp in the past and is
executable)

>
>> so you may consider removing the executable flag of the script (if it
>> is long running).
>
> Any difference with removing the script simply (from inside it) ?

Should be working. I leave the script file so to have its exact name when
deciding which process should be killed to stop the alarm...

>
>> I in ffalarms rename the script with
>>
>> mv "$0" "x$0.$$"
>
> OK... why ? debug purposes ?
>

... any proces with PID running command "sh TIME.ffalarms.NUM" if file
"xTIME.ffalarms.NUM.PID" exists in /var/spool/at.

>>
>> Here is atd 0.70 (atd-over-fso is based on this, 0.80 only adds
>> autotools which brings no value for me):
>>
>> http://handhelds.org/cgi-bin/cvsweb.cgi/apps/atd/
>>
>> and here 0.80
>>
>> http://projects.linuxtogo.org/scm/viewvc.php/?root=atd&sortby=date
>>
>> see README file for design decisions.
>>
>
> Ah, maybe not exactly the traditional atd Unix daemon, then... I'm not
> sure it should be called atd if there ain't any at, atq or atrm commands
> alongside... rather confusing IMHO.
>
it is an embedded micro atd, right may be misleading

>> I do not know of at* commands,
>
> Well... these are in Unix for quite a long time ;) : man at on any
> regular GNU/Linux distro should tell you more ;)
>
>> ffalarms does it for its own scripts via
>> command line options:
>>
>>   -s, --set=HH:MM|now     set alarm at given time
>>   -l, --list              list scheduled alarms
>>
>
> OK.
>
> But wait... looking at the sources again, I noticed an at command script
> in dist/usr/bin/ ... maybe worth adding it to atd-over-fso, then, and
> hence the packages in SHR ?

never seen it, should look at it

>
> Thanks for the details.
>
> Best regards,