bug#11044: bug & RFE

[Jim Meyering]

Hi Bruce,

Thanks for the patch.
[your subject also says "bug".
 Is there a bug fix somewhere in this patch? ]

Bruce Korb wrote:
> I guess nobody is listening.

If no one replies after a few days, it's best to presume
that your message requires more than casual feedback, and
that those inclined to provide feedback have not found time.

> BSD's implementation allows a goal specification and has a different
> default goal width computation anyway.  This change adds a "-g" option
> and allows the first two numeric operands to represent the goal width
> and actual line width.
>
> * src/fmt.c (main): implement the new option
> (check_for_goals): new function to implement the operands
> Based on BSD's and Plan-9's fmt programs.

...
> diff --git a/doc/coreutils.texi b/doc/coreutils.texi
> index 835c245..91ca957 100644
> --- a/doc/coreutils.texi
> +++ b/doc/coreutils.texi
> @@ -2133,7 +2133,7 @@ These commands reformat the contents of files.
>  a given number of characters (75 by default).  Synopsis:
>
>  @example
> -fmt address@hidden@dots{} address@hidden@dots{}
> +fmt address@hidden@dots{} address@hidden address@hidden address@hidden@dots{}
>  @end example
>
>  @command{fmt} reads from the specified @var{file} arguments (or standard
> @@ -2144,6 +2144,13 @@ preserved in the output; successive input lines with 
> different
>  indentation are not joined; tabs are expanded on input and introduced on
>  output.
>
> address@hidden and @var{width} are only recognized if neither
> address@hidden/@var{--goal} nor @var{-w}/@var{--width} have been specified; 
> and if
> +the strings represent numbers; and if the numbers do not exceed about 2,500;
> +and if these strings do not match existing file names.  If @var{GOAL} is
> +provided but @var{width} not, then @var{width} will be set to @var{goal}
> +plus 10.

The number of conditions in the above description is a red flag.

Adding a new goal-specifying option sounds fine,
but the part that makes fmt interpret the first two arguments
as non-file-names when they happen to be numeric is dubious,
even though it's limited to when those numbers do not name files.
With that, when someone writes "fmt 1" to process their file named 1,
your modified fmt would work fine, but if somehow they run that command
in a directory without that file, fmt would act differently.
The current fmt would complain about "file not found",
while with the proposed change, it would use 1 as the goal-specifying
number and read from stdin.  That seems too surprising.

Putting it another way, with the *BSD version, "fmt 72 72" is equivalent
to "fmt -w72", most of the time.  But when run in a directory containing
a file named 72, it uses that file as input, instead.

IMHO, it is best not to emulate such an interface.