Subject: PROBLEM WITH FMT
To: None <netbsd-help@NetBSD.ORG, current-users@NetBSD.ORG>
From: Brian Buhrow <buhrow@cats.ucsc.edu>
List: current-users
Date: 02/10/1997 10:15:43
	One of our most sophisticated professor/users has this to say about the 
version of fmt we distribute with NetBSD systems.  Any thoughts on a
solution short of installing the GNU fmt on both Sun SunOS systems and
NetBSD systems and telling users to have at it?  We currently run Sun SunOS
machines and NetBSD machines in a way where we try to make them look as
similar to users as possible.  Unfortunately, things like this fmt
incompatibility create real probems for them.

Suggestions, thoughts, discussion on what the standard should be are
welcome.

Jim:

One of the nastiest incompatibilities between SunOS and NetBSD
around here lies in the behavior of "fmt".  Here is a brief analysis.

1.  SunOS behavior.

Under SunOS, "fmt" expects either an option of the form "-N" where
N is a reasonable-size integer or nothing, in which case a default
of -72 is assumed.  Integer arguments are assumed to be file names.

2.  NetBSD behavior.

The NetBSD "fmt" has a totally different syntax.  It does not use the
-N option syntax for setting width.  It expects two numbers, one a
target line length and the other a not-to-be-exceeded maximum, which
must be bigger than the first.  It strives to format lines getting as
close to the target as it can without exceeding the maximum.  The
target length defaults to 65 and the upper limit to 75.  If only one
number is given, it is assumed to be the target length, and so must
be less than 75.

A specific bit of lunacy about this syntax and semantics is that files
with names like "65" or "75" will be ignored, the integers on the
command being interpreted as line length settings.  There only way to
format two files called "65" and "75" would be to repeat the defaults
on the command line: "fmt 65 75 65 75".  But this means the syntax of
the command line varies according to what the file names happen to be!
Among other things, "fmt dirname/*" would be unpredictable in its
effects from minute to minute if a program was creating and removing
output files with integer names in directory "dirname" from minute to
minute.  This is not mentioned in the BUGS section of the manual entry
but should be.  I have not met with a bug this stupid since the early
years of MS DOS, when "ECHO OFF" and "ECHO OF" had two completely
different behaviors because ECHO was doing two jobs, echoing messages
and controlling on-screen repetition of batch-file command-lines.

3. Comparison of the behavior of different command lines.

   % fmt 65 75 testfile
   -- Under SunOS:                      | -- Under NetBSD:
      Error messages:                   |    Formats the file "testfile"
      65: No such file or directory     |    with goal 65 and maximum 75.
      75: No such file or directory     |
      Then formats the file "testfile"  |
      with default line length of 72.   |

   % fmt 63 testfile
   (in a directory where there exists no file called "63")
   -- Under SunOS:                      | -- Under NetBSD:
      Error message:                    |    Formats the file "testfile"
      63: No such file or directory     |    with goal length set to 63
      Then formats the file "testfile"  |    and maximum allowable set
      with default line length of 72.   |    to 75 characters.

   % fmt 77 testfile
   (in a directory where there exists no file called "77")
   -- Under SunOS:                      | -- Under NetBSD:
      Error message:                    |    Error message: "Max length must
      77: No such file or directory     |    be greater than goal length"
      Then formats the file "testfile"  |    File "testfile" is not read.
      with default line length of 72.   |

   % fmt 65 75
   (in a directory where there exist readable files called "65" and "75")
   -- Under SunOS:                      | -- Under NetBSD:
      Formats the concatenation of      |    Hangs waiting for standard
      files "65" and "75" with maximum  |    input from keyboard, to be
      line length 72.                   |    formatted with goal=65 and
                                        |    maximum=75.

   % fmt 65 75 65 75
   (in a directory where there exist readable files called "65" and "75")
   -- Under SunOS:                      | -- Under NetBSD:
      Formats the concatenation of      |    Formats files "65" and "75"
      files "65", "75", "65", and       |    with goal=65 and maximum=75.
      "75" in that order, with line     |
      length = maximum 72.              |

   % fmt -77 testfile
   -- Under SunOS:                      | -- Under NetBSD:
      Formats the file "testfile" with  |    Formats the file "testfile"
      77-character maximum line length. |    with maximum line length of
                                        |    one word (!), apparently
                                        |    because "-77" is treated as
                                        |    equivalent to the smallest
                                        |    possible line length.

I don't think it is an exaggeration to say that this is a nightmare of
incompatibility.  And since such tricks as "~|fmt" in "mail" or "!}fmt"
in "vi" are commonly recommended and used for quick formatting, it is
not as if it is unlikely to affect people's lives.  The only reason there
probably isn't much uproar yet is that most people use a habitual machine
-- either a Sun or a PC workstation -- and relatively few (except me, and
some of my poor students) switch back and forth very much.

What's the best course?  Replace the SunOS "fmt" with the stupid NetBSD one,
and put up with its brain-damaged syntax?  Surely it's not a good idea to
stick with the present mix.  It makes it (as I have observed before)
impossible (short of some ingenious hostname-sensitive .exrc-replacement
jiggery-pokery) to have built-in keyboard maps for formatting to particular
line lengths (and let me point out that neither version of "fmt" has the
right line length for formatting narrative evaluations of student work for
submission to the SCRIPT system).

GKP


--- End of forwarded message from pullum@cats.ucsc.edu (Geoffrey K. Pullum)