[SFS] Fwd: 12 DAYS OF LINUX TECH TIPS #8

Fri Dec 14 08:02:39 MST 2018

It confuses me when linux/unix groups use the`>_` in icons to mean linux.
Where is that a default prompt on a linux/unix system?
It is the default prompt on dos other than the "drive spec" that usually
precedes it..

On Fri, Dec 14, 2018 at 7:56 AM DLWillson <DLWillson at thegeek.nu> wrote:

> Highly enjoyable. Today it's at.
>
>
> David L. Willson
> 720-333-LANS
>
>
> -------- Original message --------
> From: Linux Journal <subs at linuxjournal.com>
> Date: 12/14/18 5:30 AM (GMT-07:00)
> To: dlwillson at thegeek.nu
> Subject: 12 DAYS OF LINUX TECH TIPS #8
>
> 12 Days of Tech Tips #8
> <https://linuxjournal.cmail19.com/t/j-l-phdtkkl-jrhdlhhdjy-j/>
> view in browser »
> <https://linuxjournal.cmail19.com/t/j-e-phdtkkl-jrhdlhhdjy-n/>
>
> *12 DAYS OF LINUX TECH TIPS FOR YOU THIS HOLIDAY SEASON! JOIN US TODAY FOR
> TECH TIP #8*
> [image: Terminal]
> <https://linuxjournal.cmail19.com/t/j-l-phdtkkl-jrhdlhhdjy-t/>
>
> Schedule One-Time Commands with the UNIX at Tool
>
> Kyle Rankin
>
> *Cron is nice and all, but don't forget about its cousin at.*
>
> When I first started using Linux, it was like being tossed into the deep
> end of the UNIX pool. You were expected to use the command line heavily
> along with all the standard utilities and services that came with your
> distribution. At lot has changed since then, and nowadays, you can use a
> standard Linux desktop without ever having to open a terminal or use old
> UNIX services. Even as a sysadmin, these days, you often are a few layers
> of abstraction above some of these core services.
>
> I say all of this to point out that for us old-timers, it's easy to take
> for granted that everyone around us innately knows about all the
> command-line tools we use. Yet, even though I've been using Linux for 20
> years, I still learn about new (to me) command-line tools all the time. In
> this "Back to Basics" article series, I plan to cover some of the
> command-line tools that those new to Linux may never have used before. For
> those of you who are more advanced, I'll spread out this series, so you can
> expect future articles to be more technical. In this article, I describe
> how to use the at utility to schedule jobs to run at a later date.
> at vs. Cron
>
> at is one of those commands that isn't discussed very much. When people
> talk about scheduling commands, typically cron gets the most coverage. Cron
> allows you to schedule commands to be run on a periodic basis. With cron,
> you can run a command as frequently as every minute or as seldom as once a
> day, week, month or even year. You also can define more sophisticated
> rules, so commands run, for example, every five minutes, every weekday,
> every other hour and many other combinations. System administrators
> sometimes will use cron to schedule a local script to collect metrics every
> minute or to schedule backups.
>
> On the other hand, although the at command also allows you to schedule
> commands, it serves a completely different purpose from cron. While cron
> lets you schedule commands to run periodically, at lets you schedule
> commands that run only once at a particular time in the future. This means
> that at fills a different and usually more immediate need from cron.
> Using at
>
> At one point, the at command came standard on most Linux distributions,
> but these days, even on servers, you may find yourself having to install
> the at package explicitly. Once installed, the easiest way to use at is
> to type it on the command line followed by the time you want the command to
> run:
>
>
> $ at 18:00
>
> The at command also can accept a number of different time formats. For
> instance, it understands AM and PM as well as words like "tomorrow", so you
> could replace the above command with the identical:
>
>
> $ at 6pm
>
> And, if you want to run the same command at that time tomorrow instead:
>
>
> $ at 6pm tomorrow
>
> Once you press enter, you'll drop into an interactive shell:
>
>
> $ at 6pm tomorrow
> warning: commands will be executed using /bin/sh
> at>
>
> From the interactive shell, you can enter the command you want to run at
> that time. If you want to run multiple commands, press enter after each
> command and type the command on the new at> prompt. Once you're done
> entering commands, press Ctrl-D on an empty at> prompt to exit the
> interactive shell.
>
> For instance, let's say I've noticed that a particular server has had
> problems the past two days at 5:10am for around five minutes, and so far,
> I'm not seeing anything in the logs. Although I could just wake up early
> and log in to the server, instead I could write a short script that
> collects data from ps, netstat, tcpdump and other command-line tools for
> a few minutes, so when I wake up, I can go over the data it collected.
> Since this is a one-off, I don't want to schedule something with cron and
> risk forgetting about it and having it run every day, so this is how I
> would set it up with at:
>
>
> $ at 5:09am tomorrow
> warning: commands will be executed using /bin/sh
> at>
> at> /usr/local/bin/my_monitoring_script
>
> Then I would press Ctrl-D, and the shell would exit with this output:
>
>
> at> <EOT>
> job 1 at Wed Sep 26 05:09:00 2018
>
> Managing at Jobs
>
> Once you have scheduled at jobs, it's useful to be able to pull up a list
> of all the at jobs in the queue, so you know what's running and when. The
> atq command lists the current at queue:
>
>
> $ atq
> 1   Wed Sep 26 05:09:00 2018 a kyle
>
> The first column lists the number at assigned to each job and then lists
> the time the job will be run and the user it will run as. Let's say that in
> the above example I realize I've made a mistake, because my script won't be
> able to run as a regular user. In that case, I would want to use the atrm
> command to remove job number 1:
>
>
> $ atrm 1
>
> If I were to run atq again, I would see that the job no longer exists.
> Then I could sudo up to root and use the at command to schedule the job
> again.
> at One-Liners
>
> Although at supports an interactive mode, you also can pipe commands to
> it all on one line instead. So, for instance, I could schedule the above
> job with:
>
>
> $ echo /usr/local/bin/my_monitoring_script | at 5:09am tomorrow
>
> Conclusion
>
> If you didn't know that at existed, you might find yourself coming up
> with all sorts of complicated and convoluted ways to schedule a one-off
> job. Even worse, you might need to set an alarm clock so you can wake up
> extra early and log in to a problem server. Of course, if you don't have an
> alarm clock, you could use at:
>
>
> $ echo "aplay /home/kyle/alarm.wav" | at 7am tomorrow
>
> read more articles
> <https://linuxjournal.cmail19.com/t/j-l-phdtkkl-jrhdlhhdjy-i/>
>
> Subscribe to Linux Journal for only $2.88 an issue!
>
> Subscribe Now »
> <https://linuxjournal.cmail19.com/t/j-l-phdtkkl-jrhdlhhdjy-d/>
>
> Renew now » <https://linuxjournal.cmail19.com/t/j-l-phdtkkl-jrhdlhhdjy-h/>
> <https://linuxjournal.cmail19.com/t/j-l-phdtkkl-jrhdlhhdjy-k/>
> <https://linuxjournal.cmail19.com/t/j-l-phdtkkl-jrhdlhhdjy-u/>
> <https://linuxjournal.cmail19.com/t/j-l-phdtkkl-jrhdlhhdjy-o/>
> <https://linuxjournal.cmail19.com/t/j-l-phdtkkl-jrhdlhhdjy-b/>
>
> You are receiving this email because you signed up to receive newsletters
> from *Linux Journal*.
> You can update your preferences
> <https://linuxjournal.updatemyprofile.com/j-phdtkkl-08368EA2-jrhdlhhdjy-r>
> or unsubscribe
> <https://linuxjournal.cmail19.com/t/j-u-phdtkkl-jrhdlhhdjy-y/> from this
> list.
>
> Copyright © 2018 Linux Journal LLC, All rights reserved.
> Mailing address: 9597 Jones Rd, #331 Houston, TX 77065
> _______________________________________________
> SFS mailing list
> SFS at lists.sofree.us
> http://lists.sofree.us/cgi-bin/mailman/listinfo/sfs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sofree.us/pipermail/sfs/attachments/20181214/1f142715/attachment-0001.html>