GNU diff output defaults

[Janis Papanagnou]

When using a side-by-side diff output with GNU diff(1) it just
occurred to me that the output didn't fit on the screen window
and I saw that there's a somewhat strange or arbitrary default
width of 130 columns defined

-y, --side-by-side
-W, --width=NUM
output at most NUM (default 130) print columns

Is there a reason for a number like that; I mean I'd have (if
only for historical reasons) expected, say, a value of 80, or,
since "any default value is wrong" considering diff to take the
actual display width as default (if not specified by the user).

It's no issue, but I was surprised about that default.

Janis

[Christian Weisgerber]

On 2022-08-07, Janis Papanagnou <janis_pa...@hotmail.com> wrote:

> When using a side-by-side diff output with GNU diff(1) it just
> occurred to me that the output didn't fit on the screen window
> and I saw that there's a somewhat strange or arbitrary default
> width of 130 columns defined

Indeed, I would expect 132 columns. I guess they wanted a round
number.

> Is there a reason for a number like that; I mean I'd have (if
> only for historical reasons) expected, say, a value of 80, or,

The DEC VT100 family of video terminals could be switched from the
default 80 columns into 132-column mode.

I have a vague memory that 1980s dot matrix printers also supported
such a condensed mode.

--
Christian "naddy" Weisgerber na...@mips.inka.de

[Ben Bacarisse]

Janis Papanagnou <janis_pa...@hotmail.com> writes:

> When using a side-by-side diff output with GNU diff(1) it just
> occurred to me that the output didn't fit on the screen window
> and I saw that there's a somewhat strange or arbitrary default
> width of 130 columns defined
>
> -y, --side-by-side
> -W, --width=NUM
> output at most NUM (default 130) print columns
>
> Is there a reason for a number like that; I mean I'd have (if
> only for historical reasons) expected, say, a value of 80, or,
> since "any default value is wrong" considering diff to take the
> actual display width as default (if not specified by the user).

80 columns comes from punched cards and, in those days, the most common
size of line printer paper accommodated 132 columns. (This predates
line printers and comes from 14 inch stock and a 10 pitch font. The
other 8 columns being lost to margins and the holes to move the paper
through.)

So 80 and 132 characters were often used widths. 130? Not sure but
it's close enough to 132 that someone might be remembering an old line
printer.

--
Ben.

[Janis Papanagnou]

I do recall the 80/132 devices quite well (actually I have still a
set of punch-cards and chain-printer output somewhere buried).[*]

But I don't see the point of such a default. In my code I now have
a (IMO unnecessary complex) call of

diff -W$(tput cols) -y ...

This could have been the implicit default to make usage simpler for
any terminal settings by only calling

diff -y ...

and anyone you wants a fixed number can just define that number as
-W80, -W132, -W160, or whatever, anyway.

But okay, it is what it is.

Janis

[*] Wikipedia, though, mentions for the most widespread IBM printer
a width of 120 character positions. (This deviates from my own, but
only faint, memories.)

[Dan Espen]

My memories are pretty clear.
I can't recall a shop with 120 character printers and I was in a LOT of
shops.

I spent 2 years in a 1440 shop. The 1443 printer was 144 or 120
characters. Never saw one of those with 120 characters either.

--
Dan Espen

[David W. Hodgins]

The fanfold paper used on older printers had 133 characters per line with the
first being used for carriage control. I guess they dropped a couple of characters
to allow for paper being not quite centered.

Regards, Dave Hodgins

[Janis Papanagnou]

On 07.08.2022 17:38, Dan Espen wrote:
>
> My memories are pretty clear.
> I can't recall a shop with 120 character printers and I was in a LOT of
> shops.
>
> I spent 2 years in a 1440 shop. The 1443 printer was 144 or 120
> characters. Never saw one of those with 120 characters either.

From the Wikipedia, IBM 1403 printer (for IBM 360 and other systems):

The IBM 1403 has the following models:

Model 1: 100 print positions, maximum of 600 lines per minute, or
1285 with the Numerical Print Special Feature.
Model 2: 132 print positions, maximum of 600 lines per minute, or
1285 with the Numerical Print Special Feature, or 750 with Universal
Character Set.
Model 3: 132 print positions, maximum of 1100 lines per minute, or
1400 with the Preferred or Universal Character Sets.
Model 4: 100 print positions, maximum of 465 lines per minute.
Model 5: 132 print positions, maximum of 465 lines per minute.
Model 6: 120 print positions, maximum of 340 lines per minute,
single-carriage.
Model 7: 120 print positions, maximum of 600 lines per minute,
single-carriage.

Obviously there's 100, 120, and 132 columns, it seems - the latter
(132) was what I remember to have been used in our computing centers
(that had been running CDC 175, Siemens 7.x (IBM clone, with HW from
Asia, IIRC), and TR 440, all with the same sort of chain-printers).

Janis

[si...@hotair.club]

One of my jobs in the late 70s was printing junk mail on these printers.
The outfit I worked for had apparently bought an IBM 370 system along
with the printers, punchcard readers and reel-to-reel tape storage for
pennies at auction. A room with 6 of these printers going is very loud;
should have been wearing earplugs but none of us did. Mostly we printed
offers for insurance and credit cards on pre-printed fan-fold forms; only
the text that varied -- names, addresses, terms of offer -- were printed
so getting things to line up was sometimes tricky. We went through a
lot of ribbons with these printers; usually they broke before all the dry
ink was worn off. Other times the forms would tear. In both cases the
tapes would have to be wound back a bit and the job restarted. Many of
the forms varied only slightly from eachother; the worst thing one could
do was run the entire print job on the wrong forms..

LOL -- think I still have my IBM printer smock from that place.

[Dan Espen]

Never did the printer have 133 characters per line.
One of the ways a program could indicate carriage control was thru
putting a character in the first byte of the output stream.
On S/360 that first character was converted to some bits in the write
CCW. Only 132 characters were sent to the printer.


--
Dan Espen

[David W. Hodgins]

On Sun, 07 Aug 2022 13:08:26 -0400, Dan Espen <dan1...@gmail.com> wrote:
> Never did the printer have 133 characters per line.
> One of the ways a program could indicate carriage control was thru
> putting a character in the first byte of the output stream.
> On S/360 that first character was converted to some bits in the write
> CCW. Only 132 characters were sent to the printer.

133 characters were sent to the printer. The first byte was not printed. A blank
in that character was for single spacing, 0 for double spacing, 1 for page advance,
and + for write without advancing for highlighting or underlining, using the
standard page ribbon.

The ribbon had to match the paper being used. The ribbon had columns, with one
colums having a hole for every line on the page, and the others being used for
vertical tabs and page advances.

Regards, Dave Hodgins

[Dan Espen]

"David W. Hodgins" <dwho...@nomail.afraid.org> writes:

> On Sun, 07 Aug 2022 13:08:26 -0400, Dan Espen <dan1...@gmail.com> wrote:
>> Never did the printer have 133 characters per line.
>> One of the ways a program could indicate carriage control was thru
>> putting a character in the first byte of the output stream.
>> On S/360 that first character was converted to some bits in the write
>> CCW. Only 132 characters were sent to the printer.
>
> 133 characters were sent to the printer. The first byte was not printed. A blank
> in that character was for single spacing, 0 for double spacing, 1 for page advance,
> and + for write without advancing for highlighting or underlining, using the
> standard page ribbon.

Nope.

That's how COBOL printing using RECFM FBA would look.
That's not what got sent the printer.

IOCS took that first character and converted it to the opcode for a CCW.
Check your green card.

With COBOL you didn't have to use the first byte. Make the print file
FB and WRITE using AFTER ADVANCING.

> The ribbon had to match the paper being used. The ribbon had columns, with one
> colums having a hole for every line on the page, and the others being used for
> vertical tabs and page advances.

The ribbon is where the ink was.

That's a carriage control tape.

--
Dan Espen

[David W. Hodgins]

On Sun, 07 Aug 2022 20:32:04 -0400, Dan Espen <dan1...@gmail.com> wrote:

> "David W. Hodgins" <dwho...@nomail.afraid.org> writes:
>
>> On Sun, 07 Aug 2022 13:08:26 -0400, Dan Espen <dan1...@gmail.com> wrote:
>>> Never did the printer have 133 characters per line.
>>> One of the ways a program could indicate carriage control was thru
>>> putting a character in the first byte of the output stream.
>>> On S/360 that first character was converted to some bits in the write
>>> CCW. Only 132 characters were sent to the printer.
>>
>> 133 characters were sent to the printer. The first byte was not printed. A blank
>> in that character was for single spacing, 0 for double spacing, 1 for page advance,
>> and + for write without advancing for highlighting or underlining, using the
>> standard page ribbon.
>
> Nope.
>
> That's how COBOL printing using RECFM FBA would look.
> That's not what got sent the printer.

On the first computer/printer I used, it did. The computer was a DOS Honeywell
model 100/5. This was in 1975. I spent time helping out in the computer room for
bonus marks in my Fortran programming course, feeding the cards through the
punch or optical card readers, changing the paper on the printer, and with
forms, punching and changing the paper tape that controller the printer's
advancing.

> IOCS took that first character and converted it to the opcode for a CCW.
> Check your green card.
>
> With COBOL you didn't have to use the first byte. Make the print file
> FB and WRITE using AFTER ADVANCING.

Just because the programming language hid the first byte from the programmer,
doesn't mean it wasn't generated for sending to the printer.

Later, when I worked on an IBM 370, some times we'd print to a file instead of
the printer. In a file browser the first byte was visible.

>> The ribbon had to match the paper being used. The ribbon had columns, with one
>> colums having a hole for every line on the page, and the others being used for
>> vertical tabs and page advances.
>
> The ribbon is where the ink was.
>
> That's a carriage control tape.

Ah. I'd forgotten the term. Thanks for the correction.

Regards, Dave Hodgins

[Keith Thompson]

As discussed, VT100-based terminals and line printers commonly have a
132-column mode. 80 columns is likely to be too narrow for a
side-by-side diff. When the option was first added, it's likely that 80
and 132 columns were the only options on a lot of systems.

I think there's a strong hesitancy to make a text-processing command's
behavior depend on the current terminal characteristics. `ls` using
columns when writing to a tty is a notable exception.

It might be nice for diff to have an option to check the terminal width
itself, but as you say downthread you can roll your own:

diff -W$(tput cols) -y ...

Another useful option might be to use the actual maximum widths of the
input files (and again, you can roll your own).

--
Keith Thompson (The_Other_Keith) Keith.S.T...@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

[Janis Papanagnou]

On 07.08.2022 19:48, David W. Hodgins wrote:
>
> 133 characters were sent to the printer. The first byte was not
> printed. A blank in that character was for single spacing, 0 for
> double spacing, 1 for page advance, and + for write without advancing
> for highlighting or underlining, using the standard page ribbon.

I faintly recall that we had two printer-channels/queues, if we've
sent to the "raw" one the application data in character column 1
had triggered printer control operations like the ones you wrote.
It gave fancy "output" e.g. in form of many many empty pages - a
very fast way to produce toilet paper. The speed was amazing.

Janis

[Janis Papanagnou]

On 08.08.2022 03:08, Keith Thompson wrote:
> Janis Papanagnou <janis_pa...@hotmail.com> writes:
>> When using a side-by-side diff output with GNU diff(1) it just
>> occurred to me that the output didn't fit on the screen window
>> and I saw that there's a somewhat strange or arbitrary default
>> width of 130 columns defined
>>
>> -y, --side-by-side
>> -W, --width=NUM
>> output at most NUM (default 130) print columns
>>
>> Is there a reason for a number like that; I mean I'd have (if
>> only for historical reasons) expected, say, a value of 80, or,
>> since "any default value is wrong" considering diff to take the
>> actual display width as default (if not specified by the user).
>>
>> It's no issue, but I was surprised about that default.
>
> As discussed, VT100-based terminals and line printers commonly have a
> 132-column mode. 80 columns is likely to be too narrow for a
> side-by-side diff. When the option was first added, it's likely that 80
> and 132 columns were the only options on a lot of systems.

I'm aware of that, that's why I wrote elsethread "-W80, -W132, -W160",
with 160 to mean two screen contents side by side, which might also
be a [non-]"sensible" default.

I still think that any fixed default number is arbitrary and can only
be wrong (wrong = correct only by coincidence).
(On Unix systems we have such defaults in other places as well.)

>
> I think there's a strong hesitancy to make a text-processing command's
> behavior depend on the current terminal characteristics. `ls` using
> columns when writing to a tty is a notable exception.

There's yet more commands than that; pr(1) immediately comes to mind.

>
> It might be nice for diff to have an option to check the terminal width
> itself, but as you say downthread you can roll your own:
>
> diff -W$(tput cols) -y ...

The point is that making that a default will be "correct" for any
terminal size (as opposed to one hard coded value that can anyway
be simply specified as all the other arbitrary constant values).
(If one wants any fixed value it can be written in compact form.)

>
> Another useful option might be to use the actual maximum widths of the
> input files (and again, you can roll your own).

I think taking the maximum width of data/file contents might not
be a good choice. Think about the consequences!
Usually it's the physical display that you see that should be the
limiting factor. (Whether line-wraps or truncation is appropriate
in that case could be defined by an option. See also "pr -<N>",
vim: set nowrap, and other data displaying programs.)

But as it is with design issues that are already implemented;
changing that now would break code that relies on that. <sigh>

Janis

[David W. Hodgins]

On Sun, 07 Aug 2022 22:25:38 -0400, Janis Papanagnou <janis_pa...@hotmail.com> wrote:
> I faintly recall that we had two printer-channels/queues, if we've
> sent to the "raw" one the application data in character column 1
> had triggered printer control operations like the ones you wrote.
> It gave fancy "output" e.g. in form of many many empty pages - a
> very fast way to produce toilet paper. The speed was amazing.

I remember similar pranks. Putting a 2 in the fba, which since the tape didn't
have a hole in column 2 would dump out the box of fan fold paper. Really
annoyed whoever was operator at the time it ran, especially if they'd just
put in a new box.

Regards, Dave Hodgins

[Dan Espen]

"David W. Hodgins" <dwho...@nomail.afraid.org> writes:

My first programming instructor demonstrated the printer trying to empty
a box of paper in seconds. Then he told us, "that is why all carriage
control tapes must have _all_ channels punched".

--
Dan Espen

[Keith Thompson]

Janis Papanagnou <janis_pa...@hotmail.com> writes:
> On 08.08.2022 03:08, Keith Thompson wrote:

[...]

>> I think there's a strong hesitancy to make a text-processing command's
>> behavior depend on the current terminal characteristics. `ls` using
>> columns when writing to a tty is a notable exception.
>
> There's yet more commands than that; pr(1) immediately comes to mind.

I'm not aware that pr's behavior depends on whether it's writing to a
tty. As I recall, its defaults are optimized for line printers with 66
lines per page.

[...]

[Janis Papanagnou]

On 08.08.2022 06:12, Keith Thompson wrote:
> Janis Papanagnou <janis_pa...@hotmail.com> writes:
>> On 08.08.2022 03:08, Keith Thompson wrote:
> [...]
>>> I think there's a strong hesitancy to make a text-processing command's
>>> behavior depend on the current terminal characteristics. `ls` using
>>> columns when writing to a tty is a notable exception.
>>
>> There's yet more commands than that; pr(1) immediately comes to mind.
>
> I'm not aware that pr's behavior depends on whether it's writing to a
> tty. As I recall, its defaults are optimized for line printers with 66
> lines per page.

...and 72 columns widths (per default). - Yes you are right, I confused
that.

Janis

[Christian Weisgerber]

On 2022-08-08, Keith Thompson <Keith.S.T...@gmail.com> wrote:

> As discussed, VT100-based terminals and line printers commonly have a
> 132-column mode. 80 columns is likely to be too narrow for a
> side-by-side diff. When the option was first added, it's likely that 80
> and 132 columns were the only options on a lot of systems.

On BSD, adding the w flag will also expand the output of ps(1) from
80 to 132 columns. (Well, 79 to 131 really, because once upon a
time, not every terminal had the newline glitch.)

I still carry these aliases:
alias c132='printf "\033[?3h"; stty columns 132; kill -WINCH $$' # set DECCOLM
alias c80='printf "\033[?3l"; stty columns 80; kill -WINCH $$' # reset DECCOLM

> I think there's a strong hesitancy to make a text-processing command's
> behavior depend on the current terminal characteristics. `ls` using
> columns when writing to a tty is a notable exception.

column(1) also does this. Which is presumably where ls(1) got it
from.