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
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,
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).
Janis Papanagnou <janis_papanagnou@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.
On 07.08.2022 15:55, Ben Bacarisse wrote:
Janis Papanagnou <janis_papanagnou@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.
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.)
On Sun, 07 Aug 2022 05:59:49 -0400, Janis Papanagnou <janis_papanagnou@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
-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.
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.
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.
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.
"David W. Hodgins" <dwhodgins@nomail.afraid.org> writes:
On Sun, 07 Aug 2022 13:08:26 -0400, Dan Espen <dan1espen@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.
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.
On Sun, 07 Aug 2022 13:08:26 -0400, Dan Espen <dan1espen@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.
Janis Papanagnou <janis_papanagnou@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 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).
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.
Janis Papanagnou <janis_papanagnou@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.
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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 307 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 40:10:50 |
| Calls: | 6,910 |
| Files: | 12,376 |
| Messages: | 5,429,055 |