Northward Midget

Tag: hacking

  • Why 80 characters?

    Searching for reasonable values for the *.vt100.geometry[5-6] xterm menu font-menu options in my ~/.Xdefaults file, I re-stumbled a gem of computing history as the top-answer to a question on StackOverflow, and this pretty picture of an old IBM punch-card.

    Inspired by a perl script within the comments, I ran this shell pipe:

    2015-07-23 10:30:00 :: ~
 rons@rons-VM$ find /usr/share/terminfo/ -type f -printf '%f\n' |
   xargs -n1 infocmp | egrep -o 'cols#[0-9]+, *lines#[0-9]+' |
   sort | uniq -c | sort -nr | head
 489  cols#80,  lines#24
 58   cols#132, lines#24
 55   cols#80,  lines#25
 27   cols#80,  lines#34
 15   cols#80,  lines#40
 15   cols#80,  lines#31
 14   cols#80,  lines#33
 12   cols#126, lines#24
 10   cols#85,  lines#64
 8    cols#80,  lines#42

    Unsure if infocmp normalizes its output such that the cols and lines entries will always be adjoined, but this is good enough for my purposes.

    80×24 wins by a landslide, with 132×24 a distant second.   Then I found a Gnome help page which added 80×43 and 132×43 as options for its gooey{sic} terminal.  Next, a quick stop at the SVGA documentation in the Linux kernel with another list of common geometries.

    Finally, the Wikipedia Text Mode entry which included a neat table of common text modes:

    Text res. Char. size Graphics res. Colors Adapters
    80×25 9×14 720×350 B&W MDA, Hercules
    40×25 8×8 320×200 16 CGA, EGA
    80×25 8×8 640×200 16 CGA, EGA
    80×25 8×14 640×350 16 EGA
    80×43 8×8 640×350 16 EGA
    80×25 9×16 720×400 16 VGA
    80×30 8×16 640×480 16 VGA
    80×50 9×8 720×400 16 VGA
    80×60 16 VESA-compatible SVGA
    132×25 16 VESA-compatible SVGA
    132×43 16 VESA-compatible SVGA
    132×50 16 VESA-compatible SVGA
    132×60 16 VESA-compatible SVGA

    I think I’ll go with 80×50 and 132×60.

     

  • Shell Nuggets: Musing on Dates

    Nigh ever day I happen across some gem tucked away in the opaque vista of the *nix command-line shell.   While attempting to contrive the proper arguments for a date command interpolation, the following editorial injection from its GNU info entry caught my fancy.

    28 Date input formats
*********************
    First, a quote:
    Our units of temporal measurement, from seconds on up to months,
are so complicated, asymmetrical and disjunctive so as to make
coherent mental reckoning in time all but impossible. Indeed, had
some tyrannical god contrived to enslave our minds to time, to
make it all but impossible for us to escape subjection to sodden
routines and unpleasant surprises, he could hardly have done
better than handing down our present system. It is like a set of
trapezoidal building blocks, with no vertical or horizontal
surfaces, like a language in which the simplest thought demands
ornate constructions, useless particles and lengthy
circumlocutions. Unlike the more successful patterns of language
and science, which enable us to face experience boldly or at least
level-headedly, our system of temporal calculation silently and
persistently encourages our terror of time.
    ... It is as though architects had to measure length in feet,
width in meters and height in ells; as though basic instruction
manuals demanded a knowledge of five different languages. It is
no wonder then that we often look into our own immediate past or
future, last Tuesday or a week from Sunday, with feelings of
helpless confusion. ...
    -- Robert Grudin, `Time and the Art of Living'.
    This section describes the textual date representations that GNU
programs accept. These are the strings you, as a user, can supply as
arguments to the various programs. The C interface (via the `get_date'
function) is not described here.
    

    Now back to work.