aboutsummaryrefslogtreecommitdiff
path: root/slowbaud.rst
diff options
context:
space:
mode:
Diffstat (limited to 'slowbaud.rst')
-rw-r--r--slowbaud.rst58
1 files changed, 39 insertions, 19 deletions
diff --git a/slowbaud.rst b/slowbaud.rst
index e88f890..e270df7 100644
--- a/slowbaud.rst
+++ b/slowbaud.rst
@@ -2,6 +2,10 @@
.. rst2man.py slowbaud.rst > slowbaud.1
.. rst2man.py comes from the SBo development/docutils package.
+.. Note: if you edit this, run "make" to recreate the man page and README,
+.. *then* do a "git commit -a". Even though they're generated files, the man
+.. page and README.txt are tracked by git.
+
.. |version| replace:: 0.0.1
.. |date| date::
@@ -27,6 +31,8 @@ SYNOPSIS
**slowbaud** [*<bits-per-sec>*] **-e** *<string>* [*<string>* ...]
+**slowbaud** [*<bits-per-sec>*] **-b** [*<bytes>*]
+
DESCRIPTION
===========
@@ -36,7 +42,7 @@ to standard output... but slowly, at the given bits-per-second rate.
Input and output are unbuffered.
slowbaud can also act like **echo(1)** (the **-e** option), or run an
-interactive command (the **-c** option).
+interactive command in a pseudo-tty (the **-c** option).
The *<bits-per-sec>* argument is optional. If it's not given, the
bit rate will be set from **SLOWBAUD_BPS** in the environment, or a
@@ -46,21 +52,30 @@ OPTIONS
=======
**bits-per-sec**
- The bit ("baud") rate to simulate. This must be the first argument.
- slowbaud assumes that if the first argument is a number, it's the bit rate.
- If you're trying to pass a filename that consists only of digits, give
- **--** as the first argument, or use e.g. *./filename*.
+ The bit ("baud") rate to simulate. Range is 1 to 500000. This
+ must be the first argument. slowbaud assumes that if the first
+ argument is a number, it's the bit rate. If you're trying to pass
+ a filename that consists only of digits, give **--** as the first
+ argument, or use e.g. *./filename*.
**-e**
Echo mode. Prints all further arguments as strings to stdout, separated
by a single space, at the given bit rate. Does not support backslash-escapes, or any of
- the options of the regular **echo** command.
+ the options of the regular **echo** command. At least one argument is required
+ after **-e**.
**-c**
Command mode. Next argument (if present) is the command to run, any remaining arguments
become arguments to the command. With no arguments after **-c**, a shell is spawned.
This creates a pseudo-tty, so the command can be interactive.
+**-b**
+ Benchmark mode. Prints *<bytes>* (or 4096, if no *<bytes>* given) bytes of
+ zeroes to /dev/null. Mostly useful for development and troubleshooting.
+
+**-h**, **-?**
+ Show built-in help message and exit.
+
ENVIRONMENT
===========
@@ -79,22 +94,27 @@ ENVIRONMENT
EXIT STATUS
===========
-Without **-c**, 0 for success, non-zero on any error such as
+Without **-c** or **-e**, 0 for success, non-zero on any error such as
nonexistent/unreadable files. slowbaud exits immediately on such
errors (this is unlike **cat(1)**).
+With **-e**, exit status is 0, unless there were no arguments to echo.
+
With **-c**, exit status is that of the child process, or 127 if
the child process couldn't be spawned (e.g. command not found).
Of course, the child process could also exit with status 127...
+With **-b**, exit status is 0, unless something catastrophic happened
+(e.g. unable to open **/dev/null** for writing).
+
NOTES
=====
-The bitrate has a range of 1 to 500000. Timing accuracy depends on
-your OS, kernel config (HZ and/or NO_HZ on Linux), and system load. No
-"fancy" techniques like realtime scheduling or hardware event timers
-are used. At bitrates up to 57600, on a typical unloaded Linux system,
-the timing should be at least 99.7% accurate.
+Timing accuracy depends on your OS, kernel config (HZ and/or NO_HZ
+on Linux), and system load. No "fancy" techniques like realtime
+scheduling or hardware event timers are used. At bitrates up to 57600,
+on a typical unloaded Linux system, the timing should be at least
+99.7% accurate.
We can't really insert a delay between the bits of a byte, since
I/O is done with byte granularity. For calculation purposes,
@@ -108,9 +128,8 @@ than that, then busy-waiting until the rest of the interval expires.
At slower bitrates, this works well, and the CPU overhead is barely
noticeable (at least on reasonably fast modern systems).
-The timing error will almost always result in the bitrate
-being slightly too slow at lower bitrates and slightly too fast at
-higher ones.
+The timing inaccuracy will almost always result in the bitrate
+being slightly too slow.
Timing is more accurate on Linux than OSX. It's done with getitimer()
and sigwait(). This works out to be slightly more accurate than
@@ -120,22 +139,23 @@ possibly even better accuracy, but OSX doesn't have these (and I want to be
portable).
If this were a truly useful application, it would be worth trying to
-decrease latency further, with realtime process scheduling. I didn't
+increase accuracy further, with realtime process scheduling. I didn't
do this because slowbaud is just a toy, and because the RT stuff tends
to be unportable and require elevated privileges (root, or something
like setrtlimit or extended filesystem attributes to manage capabilities).
About the name... I'm aware that "baud" is not synonymous with bps. I
just think "slowbaud" sounds better than "slowbps", as a name. Anyway
-the stty command on Linux misuses the term ("speed 38400 baud"), so
-I'm in good company.
+the stty command on both Linux and OSX misuses the term ("speed
+38400 baud"), as well as the man page for termios(3), so I'm in good
+company.
BUGS
====
With **-c**, signals aren't handled gracefully. Window size changes
(SIGWINCH) don't get propagated to the child process, and pressing ^C
-doesn't interrupt the process. Yet.
+doesn't interrupt the process until all pending output is processed.
COPYRIGHT
=========