Well, thank you for your contributions. Go off and play with RSTS or something
equally suitable.
On Fri, 27 Jul 2001, Igor Podlesny wrote:
>
> > You're being somewhat obtuse.
>
> Really? it's probably because I don't multiply apple * milk wishing to
> receive gasoline in answer.
>
> > Complicated times such as 'teatime' and 'reboot' are explicitly allowed.
>
> It isn't a fact, what a pity...
>
> As I said before teatime is strictly defined in the manual... If you
> permanently reboots your system at "teatime" give us a call (911)
>
> > On Fri, 27 Jul 2001, Igor Podlesny wrote:
>
> >>
> >>
> >>
> >> > Hmm.
> >>
> >> > 'at teatime'
> >>
> >> > seems the same as
> >>
> >> > 'at reboot'
> >>
> >> excerpt from man 1 at which can be seen at
> >>
> >>
>http://www.freebsd.org/cgi/man.cgi?query=at&apropos=0&sektion=0&manpath=FreeBSD+4.3-RELEASE&format=html
> >>
> >> "...You may also specify midnight, noon, or teatime (4pm) and you can
> >> have..."
> >>
> >> So you mean you always reboot your system at 4pm? ;)
> >>
> >>
> >> > On Fri, 27 Jul 2001, Igor Podlesny wrote:
> >>
> >> >>
> >> >> > On Thu, 26 Jul 2001, Matthew Jacob wrote:
> >> >> >> It'd be nice if one could pass a time specification to at in the form
> >> >> >> of "next reboot".
> >> >>
> >> >> look... there is a big difference between time specification in
> >> >> at-program and suggested reboot keyword... I'd say it is like
> >> >> incompatible types... messing up time values and conditions like reboot
> >> >> which are certainly kept within time but AREN'T time values by itself.
> >> >>
> >> >> from man:
> >> >> "...
> >> >> At allows some moderately complex time specifications.
> >> >> ..."
> >> >>
> >> >> but it's always foreseen when precisely the action will have it place
> >> >> if the power is on and everything in system works ok.
> >> >> In case of reboot, this statement fails.
> >> >>
> >> >> So, I deem, it's not worth implementation within 'at' syntax. If
> >> >> somebody want such thing as 'do something on the next reboot', let's
> >> >> write another program (call it onreboot for e.g.) and try to use it.
> >> >> Although I bet, it isn't so necessary as it could seemed at first
> >> >> glance.
> >> >>
> >> >>
> >> >> >>
> >> >> >> -matt
> >> >>
> >> >> > On Thu, 26 Jul 2001, Matthew Emmerton replied:
> >> >> >> Why not just write a script for the command and stick it in
> >> >> >> /usr/local/etc/rc.d?
> >> >> >>
> >> >> >> -- Matt Emmerton
> >> >>
> >> >> > On Thu, Jul 26, 2001 at 03:45:58PM -0700, Matthew Jacob replied:
> >> >> >> Because I thought this might be of general utility.
> >> >>
> >> >>
> >> >> > Okay, try the attached patch. If this is really something that might be
> >> >> > generally usefully I can submit the patch as a PR.
> >> >>
> >> >> > It allows "at reboot" and "at reboot + 1 hour", etc.
> >> >>
> >> >> > It does it by sticking the job in the queue with the filename prefixed
> >> >> > with "_" (yeah, a bit ugly, it was the first thing that came to me) and
> >> >> > with the runtime based on the epoch instead of the current time.
> >> >>
> >> >> > Adding:
> >> >> > @reboot root /usr/libexec/atrun -b
> >> >> > to /etc/crontab causes atrun(8) to rename all of these jobs adding the
> >> >> > current time to the jobs runtime.
> >> >>
> >> >>
> >> >> > % echo "echo test" | at reboot
> >> >> > Job 19 will be executed using /bin/sh
> >> >>
> >> >> > % echo "echo test" | at reboot + 90 minutes
> >> >> > Job 20 will be executed using /bin/sh
> >> >>
> >> >> > % atq
> >> >> > Date Owner Queue Job#
> >> >> > REBOOT dchapes c 19
> >> >> > REBOOT+01:30:00 dchapes c 20
> >> >>
> >> >> what if a user rebooted the box, before this REBOOT+1:30:00 has been
> >> >> occured? will it be discarded or what?
> >> >>
> >> >> > $ date; /usr/libexec/atrun -b
> >> >>
> >> >> > % atq -v
> >> >> > Date Owner Queue Job#
> >> >> > 22:34:00 07/26/01 dchapes c 20
> >> >> > 21:04:00 07/26/01 dchapes c(done) 19
> >> >>
> >> >> --
> >> >> Igor mailto:[EMAIL PROTECTED]
> >> >>
> >> >>
> >> >>
> >>
> >>
> >> > To Unsubscribe: send mail to [EMAIL PROTECTED]
> >> > with "unsubscribe freebsd-hackers" in the body of the message
> >>
> >>
> >>
> >> --
> >> Igor mailto:[EMAIL PROTECTED]
> >>
> >>
> >>
>
>
>
> --
> Igor mailto:[EMAIL PROTECTED]
>
>
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
