As previously established (see Introduction), GNU Alive is a package that provides a command-line program to periodically make network contact with (aka “ping”) a specified host. This section describes some differences between ‘ping’ and ‘alive’ (the program).
Like all proper GNU programs, ‘alive’ supports these options, displaying the requested information to stdout and exiting successfully. See Invoking alive.
Note that Inetutils (see GNU Software) ping also supports these options, as it is also a proper GNU program. Other ping programs may or may not.
To keep things simple and consistent, ‘alive’ takes no arguments, and instead reads configuration information from files in the config directory, by default $HOME/.alive.d/.
If that dir does not exist and your system has ‘xdgdirs’1, then the
the config directory is taken to be what ‘xdgdirs alive’
config-home (you can influence this by
setting env var
In any case, if the config dir or those files don’t exist, ‘alive’ uses reasonable defaults.
Each configuration file is rescanned at the top of every loop iteration if its modification time differs from the last check. This means it’s enough to edit a file (and wait); no need to restart the program. See Configuration.
If you specify more than one host, ‘alive’ contacts them in a round-robin fashion. This reduces the annoyance level of some network administrators—always a good idea.
On the other hand, if you don’t specify any hosts, ‘alive’ contacts
The default period, i.e., time between successive contacts, is a random number of seconds in the range 149 to 420, inclusive.
All GNU programs are distributed as source code, of course, but GNU Alive goes further; the source code is also available when you run the program.
This is because ‘alive’ is implemented as a script, a sequence of textual instructions for an “interpreter” program to read and evaluate, rather than a binary file.
Most users don’t care about runtime access to source code, but perhaps you are not like most users.
GNU Alive uses Guile Scheme (see GNU Software) as the implementation language.
Each configuration file is a series of sexps, or
structured expressions, amenable to the Scheme
(Actually, the syntax is designed to be a subset of what Scheme
read can handle, to be friendly also to Emacs Lisp
Most programmers don’t care about sexps, but perhaps you are not like most programmers.