From cym224 at gmail.com Fri Mar 5 05:34:10 2021
From: cym224 at gmail.com (Nemo Nusquam)
Date: Thu, 04 Mar 2021 14:34:10 -0500
Subject: [COFF] Quote from Wilkes
Message-ID: <60413632.9060500@gmail.com>
I am currently reading "Memoirs of a Computer Pioneer" by Maurice
Wilkes, MIT press. The following text from p. 145 may amuse readers.
[p. 145] By June 1949 people had begun to realize that it was not so
easy to get a program right as had at one time appeared. I well
remember then this realization first came on me with full force. The
EDSAC was on the top floor of the building and the tape-punching and
editing equipment one floor below [...]. I was trying to get working my
first non-trivial program, which was one for the numerical integration
of Airy's differential equation. It was on one of my journeys between
the EDSAC room and the punching equipment that "hesitating at the angles
of stairs" the realization came over me with full force that a good part
of the remainder of my life was going to spent in finding errors in my
own programs.
N.
From dave at horsfall.org Sun Mar 7 07:06:33 2021
From: dave at horsfall.org (Dave Horsfall)
Date: Sun, 7 Mar 2021 08:06:33 +1100 (EST)
Subject: [COFF] Quote from Wilkes
In-Reply-To: <60413632.9060500@gmail.com>
References: <60413632.9060500@gmail.com>
Message-ID: <alpine.BSF.2.21.9999.2103070800260.99507@aneurin.horsfall.org>
On Thu, 4 Mar 2021, Nemo Nusquam wrote:
> I am currently reading "Memoirs of a Computer Pioneer" by Maurice
> Wilkes, MIT press. The following text from p. 145 may amuse readers.
[...]
You were lucky! Back in my Uni days (punched cards on the 029) we only
had the overnight batch run on the 360/50, so we quickly learned to code
properly lest the output be returned with the dreaded "syntax error".
-- Dave
From cym224 at gmail.com Mon Mar 8 01:18:01 2021
From: cym224 at gmail.com (Nemo Nusquam)
Date: Sun, 7 Mar 2021 10:18:01 -0500
Subject: [COFF] Ancient Pi [Was: Re: [TUHS] tabs vs spaces - entab, detab]
In-Reply-To: <202103070003.12703Crs2866116@darkstar.fourwinds.com>
References: <alpine.BSF.2.21.9999.2103070814170.99507@aneurin.horsfall.org>
<C82B92AB-9EEE-4ED7-89C1-9CEC66D40E3D@iitbombay.org>
<202103070003.12703Crs2866116@darkstar.fourwinds.com>
Message-ID: <91231bf6-9b3b-a890-829f-0f2a30a7a685@gmail.com>
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20210307/80ed049a/attachment.htm>
From gtaylor at tnetconsulting.net Fri Mar 12 03:13:50 2021
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Thu, 11 Mar 2021 10:13:50 -0700
Subject: [COFF] Pondering the hosts file
Message-ID: <02d10a8e-2f39-4f88-f4c9-ecb295e0f01e@spamtrap.tnetconsulting.net>
Hi,
I'm not sure where this message best fits; TUHS, COFF, or Internet
History, so please forgive me if this list is not the best location.
I'm discussing the hosts file with someone and was wondering if there's
any historical documentation around it's format and what should and
should not be entered in the file.
I've read the current man page on Gentoo Linux, but suspect that it's
far from authoritative. I'm hoping that someone can point me to
something more authoritative to the hosts file's format, guidelines
around entering data, and how it's supposed to function.
A couple of sticking points in the other discussion revolve around how
many entries a host is supposed to have in the hosts file and any
ramifications for having a host appear as an alias on multiple lines /
entries. To whit, how correct / incorrect is the following:
192.0.2.1 host.example.net host
127.0.0.1 localhost host.example.net host
--
Grant. . . .
unix || die
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4013 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20210311/979ec8d0/attachment.bin>
From steffen at sdaoden.eu Fri Mar 12 03:29:23 2021
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Thu, 11 Mar 2021 18:29:23 +0100
Subject: [COFF] Pondering the hosts file
In-Reply-To: <02d10a8e-2f39-4f88-f4c9-ecb295e0f01e@spamtrap.tnetconsulting.net>
References: <02d10a8e-2f39-4f88-f4c9-ecb295e0f01e@spamtrap.tnetconsulting.net>
Message-ID: <20210311172923.3f-gd%steffen@sdaoden.eu>
Grant Taylor wrote in
<02d10a8e-2f39-4f88-f4c9-ecb295e0f01e at spamtrap.tnetconsulting.net>:
|Hi,
|
|I'm not sure where this message best fits; TUHS, COFF, or Internet
|History, so please forgive me if this list is not the best location.
|
|I'm discussing the hosts file with someone and was wondering if there's
|any historical documentation around it's format and what should and
|should not be entered in the file.
|
|I've read the current man page on Gentoo Linux, but suspect that it's
|far from authoritative. I'm hoping that someone can point me to
|something more authoritative to the hosts file's format, guidelines
|around entering data, and how it's supposed to function.
|
|A couple of sticking points in the other discussion revolve around how
|many entries a host is supposed to have in the hosts file and any
|ramifications for having a host appear as an alias on multiple lines /
|entries. To whit, how correct / incorrect is the following:
|
|192.0.2.1 host.example.net host
|127.0.0.1 localhost host.example.net host
Address, "official name", aliases.
And as many as you want i'd say. It is just that an alias might
be hidden and never be found (if actually hidden). This is at
least how i interpreted it.
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
From bakul at iitbombay.org Fri Mar 12 03:40:02 2021
From: bakul at iitbombay.org (Bakul Shah)
Date: Thu, 11 Mar 2021 09:40:02 -0800
Subject: [COFF] [TUHS] Pondering the hosts file
In-Reply-To: <02d10a8e-2f39-4f88-f4c9-ecb295e0f01e@spamtrap.tnetconsulting.net>
References: <02d10a8e-2f39-4f88-f4c9-ecb295e0f01e@spamtrap.tnetconsulting.net>
Message-ID: <120EC052-FB1F-438F-985F-64E9CD82A9C1@iitbombay.org>
From https://www.freebsd.org/cgi/man.cgi?hosts(5)
For each host a single line should be present with the following information:
Internet address
official host name
aliases
HISTORY
The hosts file format appeared in 4.2BSD.
> On Mar 11, 2021, at 9:14 AM, Grant Taylor via TUHS <tuhs at minnie.tuhs.org> wrote:
> Hi,
>
> I'm not sure where this message best fits; TUHS, COFF, or Internet History, so please forgive me if this list is not the best location.
>
> I'm discussing the hosts file with someone and was wondering if there's any historical documentation around it's format and what should and should not be entered in the file.
>
> I've read the current man page on Gentoo Linux, but suspect that it's far from authoritative. I'm hoping that someone can point me to something more authoritative to the hosts file's format, guidelines around entering data, and how it's supposed to function.
>
> A couple of sticking points in the other discussion revolve around how many entries a host is supposed to have in the hosts file and any ramifications for having a host appear as an alias on multiple lines / entries. To whit, how correct / incorrect is the following:
>
> 192.0.2.1 host.example.net host
> 127.0.0.1 localhost host.example.net host
>
>
>
> --
> Grant. . . .
> unix || die
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20210311/f2e213b8/attachment.htm>
From clemc at ccc.com Fri Mar 12 04:02:22 2021
From: clemc at ccc.com (Clem Cole)
Date: Thu, 11 Mar 2021 13:02:22 -0500
Subject: [COFF] Pondering the hosts file
In-Reply-To: <02d10a8e-2f39-4f88-f4c9-ecb295e0f01e@spamtrap.tnetconsulting.net>
References: <02d10a8e-2f39-4f88-f4c9-ecb295e0f01e@spamtrap.tnetconsulting.net>
Message-ID: <CAC20D2NgRziycz+25N3NfM1Q49dBz0Owzx+xOn3J2+dYcihrNQ@mail.gmail.com>
Grant, are you asking about a multi-homed host?
IIRC the original BSD code did the first hit and stop, when looking
something up. What we sometimes did was give the host an alias : host-en
for the ethernet and host-pro proteon HW. Host would be on both lines, so
you wanted to make the first 'host' to be the default.
á§
On Thu, Mar 11, 2021 at 12:13 PM Grant Taylor via COFF <coff at minnie.tuhs.org>
wrote:
> Hi,
>
> I'm not sure where this message best fits; TUHS, COFF, or Internet
> History, so please forgive me if this list is not the best location.
>
> I'm discussing the hosts file with someone and was wondering if there's
> any historical documentation around it's format and what should and
> should not be entered in the file.
>
> I've read the current man page on Gentoo Linux, but suspect that it's
> far from authoritative. I'm hoping that someone can point me to
> something more authoritative to the hosts file's format, guidelines
> around entering data, and how it's supposed to function.
>
> A couple of sticking points in the other discussion revolve around how
> many entries a host is supposed to have in the hosts file and any
> ramifications for having a host appear as an alias on multiple lines /
> entries. To whit, how correct / incorrect is the following:
>
> 192.0.2.1 host.example.net host
> 127.0.0.1 localhost host.example.net host
>
>
>
> --
> Grant. . . .
> unix || die
>
> _______________________________________________
> COFF mailing list
> COFF at minnie.tuhs.org
> https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20210311/305b2414/attachment-0001.htm>
From imp at bsdimp.com Fri Mar 12 04:08:03 2021
From: imp at bsdimp.com (Warner Losh)
Date: Thu, 11 Mar 2021 11:08:03 -0700
Subject: [COFF] [TUHS] Pondering the hosts file
In-Reply-To: <120EC052-FB1F-438F-985F-64E9CD82A9C1@iitbombay.org>
References: <02d10a8e-2f39-4f88-f4c9-ecb295e0f01e@spamtrap.tnetconsulting.net>
<120EC052-FB1F-438F-985F-64E9CD82A9C1@iitbombay.org>
Message-ID: <CANCZdfrfKBcj3s4gW=y2bLd2nuM0nnSVMA0ZkcJ300p6szyzWw@mail.gmail.com>
On Thu, Mar 11, 2021 at 10:40 AM Bakul Shah <bakul at iitbombay.org> wrote:
> From https://www.freebsd.org/cgi/man.cgi?hosts(5)
>
> For each host a single line should be present with the following information:
>
> Internet address
> official host name
> aliases
>
> *HISTORY* <https://www.freebsd.org/cgi/man.cgi?hosts(5)#end>
> The *hosts* file format appeared in 4.2BSD.
>
>
While this is true wrt the history of FreeBSD/Unix, I'm almost positive
that BSD didn't invent it. I'm pretty sure it was picked up from the
existing host file that was published by sri-nic.arpa before DNS.
Warner
> On Mar 11, 2021, at 9:14 AM, Grant Taylor via TUHS <tuhs at minnie.tuhs.org>
> wrote:
>
> Hi,
>
> I'm not sure where this message best fits; TUHS, COFF, or Internet
> History, so please forgive me if this list is not the best location.
>
> I'm discussing the hosts file with someone and was wondering if there's
> any historical documentation around it's format and what should and should
> not be entered in the file.
>
> I've read the current man page on Gentoo Linux, but suspect that it's far
> from authoritative. I'm hoping that someone can point me to something more
> authoritative to the hosts file's format, guidelines around entering data,
> and how it's supposed to function.
>
> A couple of sticking points in the other discussion revolve around how
> many entries a host is supposed to have in the hosts file and any
> ramifications for having a host appear as an alias on multiple lines /
> entries. To whit, how correct / incorrect is the following:
>
> 192.0.2.1 host.example.net host
> 127.0.0.1 localhost host.example.net host
>
>
>
> --
> Grant. . . .
> unix || die
>
> _______________________________________________
> COFF mailing list
> COFF at minnie.tuhs.org
> https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20210311/a5d2f615/attachment.htm>
From clemc at ccc.com Fri Mar 12 04:12:55 2021
From: clemc at ccc.com (Clem Cole)
Date: Thu, 11 Mar 2021 13:12:55 -0500
Subject: [COFF] [TUHS] Pondering the hosts file
In-Reply-To: <CANCZdfrfKBcj3s4gW=y2bLd2nuM0nnSVMA0ZkcJ300p6szyzWw@mail.gmail.com>
References: <02d10a8e-2f39-4f88-f4c9-ecb295e0f01e@spamtrap.tnetconsulting.net>
<120EC052-FB1F-438F-985F-64E9CD82A9C1@iitbombay.org>
<CANCZdfrfKBcj3s4gW=y2bLd2nuM0nnSVMA0ZkcJ300p6szyzWw@mail.gmail.com>
Message-ID: <CAC20D2OF_ERtaioLWdw5N3vik6orb34ZKt=fgfM4PyEq8Mnfjw@mail.gmail.com>
The SRI file was different format. There was a tool that fetched and
converted from the PDP-10 scheme to the UNIX scheme - gethtable(8) or
something like that.
á§
á§
On Thu, Mar 11, 2021 at 1:08 PM Warner Losh <imp at bsdimp.com> wrote:
>
>
> On Thu, Mar 11, 2021 at 10:40 AM Bakul Shah <bakul at iitbombay.org> wrote:
>
>> From https://www.freebsd.org/cgi/man.cgi?hosts(5)
>>
>> For each host a single line should be present with the following information:
>>
>> Internet address
>> official host name
>> aliases
>>
>> *HISTORY* <https://www.freebsd.org/cgi/man.cgi?hosts(5)#end>
>> The *hosts* file format appeared in 4.2BSD.
>>
>>
> While this is true wrt the history of FreeBSD/Unix, I'm almost positive
> that BSD didn't invent it. I'm pretty sure it was picked up from the
> existing host file that was published by sri-nic.arpa before DNS.
>
> Warner
>
>
>> On Mar 11, 2021, at 9:14 AM, Grant Taylor via TUHS <tuhs at minnie.tuhs.org>
>> wrote:
>>
>> Hi,
>>
>> I'm not sure where this message best fits; TUHS, COFF, or Internet
>> History, so please forgive me if this list is not the best location.
>>
>> I'm discussing the hosts file with someone and was wondering if there's
>> any historical documentation around it's format and what should and should
>> not be entered in the file.
>>
>> I've read the current man page on Gentoo Linux, but suspect that it's far
>> from authoritative. I'm hoping that someone can point me to something more
>> authoritative to the hosts file's format, guidelines around entering data,
>> and how it's supposed to function.
>>
>> A couple of sticking points in the other discussion revolve around how
>> many entries a host is supposed to have in the hosts file and any
>> ramifications for having a host appear as an alias on multiple lines /
>> entries. To whit, how correct / incorrect is the following:
>>
>> 192.0.2.1 host.example.net host
>> 127.0.0.1 localhost host.example.net host
>>
>>
>>
>> --
>> Grant. . . .
>> unix || die
>>
>> _______________________________________________
>> COFF mailing list
>> COFF at minnie.tuhs.org
>> https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20210311/f3337c06/attachment.htm>
From bakul at iitbombay.org Fri Mar 12 04:30:40 2021
From: bakul at iitbombay.org (Bakul Shah)
Date: Thu, 11 Mar 2021 10:30:40 -0800
Subject: [COFF] [TUHS] Pondering the hosts file
Message-ID: <ACFA5AEB-B17A-4A5B-88CA-ABF611DD1E2E@iitbombay.org>
On Mar 11, 2021, at 10:08 AM, Warner Losh <imp at bsdimp.com> wrote:
>
> On Thu, Mar 11, 2021 at 10:40 AM Bakul Shah <bakul at iitbombay.org> wrote:
>> From https://www.freebsd.org/cgi/man.cgi?hosts(5)
>> For each host a single line should be present with the following information:
>> Internet address
>> official host name
>> aliases
>> HISTORY
>> The hosts file format appeared in 4.2BSD.
>
> While this is true wrt the history of FreeBSD/Unix, I'm almost positive that BSD didn't invent it. I'm pretty sure it was picked up from the existing host file that was published by sri-nic.arpa before DNS.
A different and more verbose format. See RFCs 810 & 952. Possibly because it had to serve more purposes?
> Warner
>
>>> On Mar 11, 2021, at 9:14 AM, Grant Taylor via TUHS <tuhs at minnie.tuhs.org> wrote:
>>> Hi,
>>>
>>> I'm not sure where this message best fits; TUHS, COFF, or Internet History, so please forgive me if this list is not the best location.
>>>
>>> I'm discussing the hosts file with someone and was wondering if there's any historical documentation around it's format and what should and should not be entered in the file.
>>>
>>> I've read the current man page on Gentoo Linux, but suspect that it's far from authoritative. I'm hoping that someone can point me to something more authoritative to the hosts file's format, guidelines around entering data, and how it's supposed to function.
>>>
>>> A couple of sticking points in the other discussion revolve around how many entries a host is supposed to have in the hosts file and any ramifications for having a host appear as an alias on multiple lines / entries. To whit, how correct / incorrect is the following:
>>>
>>> 192.0.2.1 host.example.net host
>>> 127.0.0.1 localhost host.example.net host
>>>
>>>
>>>
>>> --
>>> Grant. . . .
>>> unix || die
>> _______________________________________________
>> COFF mailing list
>> COFF at minnie.tuhs.org
>> https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20210311/5ba7c753/attachment-0001.htm>
From jpl.jpl at gmail.com Fri Mar 12 06:02:11 2021
From: jpl.jpl at gmail.com (John P. Linderman)
Date: Thu, 11 Mar 2021 15:02:11 -0500
Subject: [COFF] Was [TUHS] tabs vs spaces - entab, detab
Message-ID: <CAC0cEp9GVsYbjYhsYk2Hjjj90FxYFAia2Luy_vg854NTrV3Hww@mail.gmail.com>
The tab/detab horse was still twitching, so I decided to beat it a little
more.
Doug's claim that tabs saving space was an urban legend didn't ring true,
but betting again Doug is a good way to get poor quick. So I tossed
together a perl script (version run through col -x is at the end of this
note) to measure savings. A simpler script just counted tabs,
distinguishing leading tabs, which I expected to be very common, from
embedded tabs, which I expected to be rare. In retrospect, embedded tabs
are common in (my) C code, separating structure types from the element
names and trailing comments. As Norman pointed out, genuine tabs often
preserve line to line alignment in the presence of small changes. So the
fancier script distinguishes between leading tabs and embedded tabs for
various possible tab stops. Small tab stops keep heavily indented code
lines short, large tab stops can save more space when tabbing past leading
blanks. My coding style uses "set-width" of 4, which vi turns into spaces
or tabs, with "standard" tabs every 8 columns. My code therefore benefits
most with tabstops every 4 columns. A lot of code is indented 4 spaces,
which saves 3 bytes when replaced by a tab, but there is no saving with
tabstops at 8. Here's the output when run on itself (before it was
detabbed) and on a largish C program:
/home/jpl/bin/tabsave.pl /home/jpl/bin/tabsave.pl rsort.c
/home/jpl/bin/tabsave.pl, size 1876
2: Leading 202, Embedded 3, Total 205
4: Leading 303, Embedded 4, Total 307
8: Leading 238, Embedded 5, Total 243
rsort.c, size 209597
2: Leading 13186, Embedded 4219, Total 17405
4: Leading 19776, Embedded 5990, Total 25766
8: Leading 16506, Embedded 6800, Total 23306
The bytes saved by using tabs compared to the (detabbed) original size are
not chump change, with 2, 4 or 8 column tabstops. On ordinary text, savings
are totally unimpressive, usually 0. Your savings may vary. I think the
horse is now officially deceased. -- jpl
===
#!/usr/bin/perl -w
use strict;
my @Tab_stops = ( 2, 4, 8 );
sub check_stop {
my ($line, $stop_at) = @_;
my $pos = length($line);
my ($leading, $embedded) = (0,0);
while ($pos >= $stop_at) {
$pos -= ($pos % $stop_at); # Get to previous tab stop
my $blanks = 0;
while ((--$pos >= 0) && (substr($line, $pos, 1) eq ' ')) {
++$blanks; }
if ($blanks > 1) {
my $full = int($blanks/$stop_at);
my $partial = $blanks - $full * $stop_at;
my $savings = (--$partial > 0) ? $partial : 0;
$savings += $full * ($stop_at - 1);
if ($pos < 0) {
$leading += $savings;
} else {
$embedded += $savings;
}
}
}
return ($leading, $embedded);
}
sub dofile {
my $file = shift;
my $command = "col -x < $file";
my $notabsfh;
unless (open($notabsfh, "-|", $command)) {
printf STDERR ("Open failed on '$command': $!");
return;
}
my $size = 0;
my ($leading, $embedded) = (0,0);
my @savings;
for (my $i = 0; $i < @Tab_stops; ++$i) { $savings[$i] = [0,0]; }
while (my $line = <$notabsfh>) {
my $n = length($line);
$size += $n;
$line =~ s/(\s*)$//;
for (my $i = 0; $i < @Tab_stops; ++$i) {
my @l_e = check_stop($line, $Tab_stops[$i]);
for (my $j = 0; $j < @l_e; ++$j) {
$savings[$i][$j] += $l_e[$j];
}
}
}
print("$file, size $size\n");
for (my $i = 0; $i < @Tab_stops; ++$i) {
print(" $Tab_stops[$i]: ");
my $l = $savings[$i][0];
my $e = $savings[$i][1];
my $t = $l + $e;
print("Leading $l, Embedded $e, Total $t\n");
}
print("\n");
}
sub main {
for my $file (@ARGV) {
dofile($file);
}
}
main();
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20210311/63c904e4/attachment.htm>
From gtaylor at tnetconsulting.net Fri Mar 12 07:03:09 2021
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Thu, 11 Mar 2021 14:03:09 -0700
Subject: [COFF] Pondering the hosts file
In-Reply-To: <20210311172923.3f-gd%steffen@sdaoden.eu>
References: <02d10a8e-2f39-4f88-f4c9-ecb295e0f01e@spamtrap.tnetconsulting.net>
<20210311172923.3f-gd%steffen@sdaoden.eu>
Message-ID: <80d8f9bc-31d6-6bb8-03e6-ce53cc4a9cdb@spamtrap.tnetconsulting.net>
On 3/11/21 10:29 AM, Steffen Nurpmeso wrote:
> Address, "official name", aliases.
> And as many as you want i'd say. It is just that an alias might be
> hidden and never be found (if actually hidden). This is at least
> how i interpreted it.
Please clarify what you mean by "And as many as you want".
Do you man as many /aliases/ and / or as many /entries/ (lines) in the file?
--
Grant. . . .
unix || die
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4013 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20210311/cde6f420/attachment.bin>
From gtaylor at tnetconsulting.net Fri Mar 12 07:08:31 2021
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Thu, 11 Mar 2021 14:08:31 -0700
Subject: [COFF] Pondering the hosts file
In-Reply-To: <CAC20D2NgRziycz+25N3NfM1Q49dBz0Owzx+xOn3J2+dYcihrNQ@mail.gmail.com>
References: <02d10a8e-2f39-4f88-f4c9-ecb295e0f01e@spamtrap.tnetconsulting.net>
<CAC20D2NgRziycz+25N3NfM1Q49dBz0Owzx+xOn3J2+dYcihrNQ@mail.gmail.com>
Message-ID: <a9c39035-4037-200e-b883-a87f5a7dc6bd@spamtrap.tnetconsulting.net>
On 3/11/21 11:02 AM, Clem Cole wrote:
> Grant, are you asking about a multi-homed host?
I had specifically elided multi-homing for simplicity.
> IIRC the original BSD code did the first hit and stop, when looking
> something up.
*nod*
That's my understanding.
> What we sometimes did was give the host an alias : host-en for the
> ethernet and host-pro proteon HW.
If I understand what you're saying:
192.0.2.1 host.example.net host-en
198.51.100.1 host.example.net host-pro
> Host would be on both lines, so you wanted to make the first 'host'
> to be the default.
I guess I shouldn't elide multi-homing and instead address it directly.
Or at least clarify the paradigm.
Should a given host name appear on more than one entry / line in the
hosts file if it's only got one IP (other than 127.0.0.1 / ::1)?
--
Grant. . . .
unix || die
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4013 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20210311/ba582657/attachment-0001.bin>
From steffen at sdaoden.eu Fri Mar 12 07:18:38 2021
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Thu, 11 Mar 2021 22:18:38 +0100
Subject: [COFF] Was [TUHS] tabs vs spaces - entab, detab
In-Reply-To: <CAC0cEp9GVsYbjYhsYk2Hjjj90FxYFAia2Luy_vg854NTrV3Hww@mail.gmail.com>
References: <CAC0cEp9GVsYbjYhsYk2Hjjj90FxYFAia2Luy_vg854NTrV3Hww@mail.gmail.com>
Message-ID: <20210311211838.Z2QAs%steffen@sdaoden.eu>
John P. Linderman wrote in
<CAC0cEp9GVsYbjYhsYk2Hjjj90FxYFAia2Luy_vg854NTrV3Hww at mail.gmail.com>:
|The tab/detab horse was still twitching, so I decided to beat it a little
|more.
|
|Doug's claim that tabs saving space was an urban legend didn't ring true,
|but betting again Doug is a good way to get poor quick. So I tossed
|together a perl script (version run through col -x is at the end of this
|note) to measure savings. A simpler script just counted tabs,
|distinguishing leading tabs, which I expected to be very common, from
|embedded tabs, which I expected to be rare. In retrospect, embedded tabs
|are common in (my) C code, separating structure types from the element
|names and trailing comments. As Norman pointed out, genuine tabs often
|preserve line to line alignment in the presence of small changes. So the
|fancier script distinguishes between leading tabs and embedded tabs for
|various possible tab stops. Small tab stops keep heavily indented code
|lines short, large tab stops can save more space when tabbing past leading
|blanks. My coding style uses "set-width" of 4, which vi turns into spaces
|or tabs, with "standard" tabs every 8 columns. My code therefore benefits
|most with tabstops every 4 columns. A lot of code is indented 4 spaces,
|which saves 3 bytes when replaced by a tab, but there is no saving with
|tabstops at 8. Here's the output when run on itself (before it was
|detabbed) and on a largish C program:
|
| /home/jpl/bin/tabsave.pl /home/jpl/bin/tabsave.pl rsort.c
|/home/jpl/bin/tabsave.pl, size 1876
| 2: Leading 202, Embedded 3, Total 205
| 4: Leading 303, Embedded 4, Total 307
| 8: Leading 238, Embedded 5, Total 243
|
|rsort.c, size 209597
| 2: Leading 13186, Embedded 4219, Total 17405
| 4: Leading 19776, Embedded 5990, Total 25766
| 8: Leading 16506, Embedded 6800, Total 23306
|
|The bytes saved by using tabs compared to the (detabbed) original size are
|not chump change, with 2, 4 or 8 column tabstops. On ordinary text, savings
|are totally unimpressive, usually 0. Your savings may vary. I think the
|horse is now officially deceased. -- jpl
Not really. I mean, i do not insist of this, but i looked at the
numbers. And despite col(1) 2.36.2 giving the wrong line when
failing to dig a LATIN1 in UTF-8 (should be 7, gave 11), when
i sum up the total of 8: in an old project with tests,
documentation etc. here the output is 1044401. This is without
generated data. I mean, even today i strip whitespace in shipout
code, of generated data, of documentation parsed through
processors. This includes mangling of internal interface headers
and removal of their documentation and comments, but copyright.
You know, only this automatized pre-release step of the pretty
small open source MUA i maintain causes this line count change:
37 files changed, 2441 insertions(+), 10537 deletions(-)
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
From bakul at iitbombay.org Fri Mar 12 07:21:43 2021
From: bakul at iitbombay.org (Bakul Shah)
Date: Thu, 11 Mar 2021 13:21:43 -0800
Subject: [COFF] Pondering the hosts file
In-Reply-To: <80d8f9bc-31d6-6bb8-03e6-ce53cc4a9cdb@spamtrap.tnetconsulting.net>
References: <02d10a8e-2f39-4f88-f4c9-ecb295e0f01e@spamtrap.tnetconsulting.net>
<20210311172923.3f-gd%steffen@sdaoden.eu>
<80d8f9bc-31d6-6bb8-03e6-ce53cc4a9cdb@spamtrap.tnetconsulting.net>
Message-ID: <7DA0AB0F-BE0A-4ADD-B160-DCEEDEED87A8@iitbombay.org>
On Mar 11, 2021, at 1:03 PM, Grant Taylor via COFF <coff at minnie.tuhs.org> wrote:
>
> On 3/11/21 10:29 AM, Steffen Nurpmeso wrote:
>> Address, "official name", aliases.
>> And as many as you want i'd say. It is just that an alias might be hidden and never be found (if actually hidden). This is at least how i interpreted it.
>
> Please clarify what you mean by "And as many as you want".
>
> Do you man as many /aliases/ and / or as many /entries/ (lines) in the file?
The FreeBSD man page I quoted from (prob. orig. from 4.2BSD or so) shows no such
restriction so you can have as many aliases as you wnat as and many entries as you
want. But an implementation may have its own limits.
And if you have non-unique names or addresses, be prepared for surprises.
From steffen at sdaoden.eu Fri Mar 12 07:29:12 2021
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Thu, 11 Mar 2021 22:29:12 +0100
Subject: [COFF] Pondering the hosts file
In-Reply-To: <80d8f9bc-31d6-6bb8-03e6-ce53cc4a9cdb@spamtrap.tnetconsulting.net>
References: <02d10a8e-2f39-4f88-f4c9-ecb295e0f01e@spamtrap.tnetconsulting.net>
<20210311172923.3f-gd%steffen@sdaoden.eu>
<80d8f9bc-31d6-6bb8-03e6-ce53cc4a9cdb@spamtrap.tnetconsulting.net>
Message-ID: <20210311212912.nQaYz%steffen@sdaoden.eu>
Grant Taylor wrote in
<80d8f9bc-31d6-6bb8-03e6-ce53cc4a9cdb at spamtrap.tnetconsulting.net>:
|On 3/11/21 10:29 AM, Steffen Nurpmeso wrote:
|> Address, "official name", aliases.
|> And as many as you want i'd say. It is just that an alias might be
|> hidden and never be found (if actually hidden). This is at least
|> how i interpreted it.
|
|Please clarify what you mean by "And as many as you want".
|
|Do you man as many /aliases/ and / or as many /entries/ (lines) in \
|the file?
Both. Here, that is. The first generated AorAAAA, the latter
were "system alias" names (not even cname or something) which were
search in preference unless the query gave a conf_noaliases flag.
And the reading was just readLine(). And one thing why i loved
C++, writing something like "_line.trim().squeeze().data()" in
C is terrible.
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
From jpl.jpl at gmail.com Fri Mar 12 09:31:09 2021
From: jpl.jpl at gmail.com (John P. Linderman)
Date: Thu, 11 Mar 2021 18:31:09 -0500
Subject: [COFF] Was [TUHS] tabs vs spaces - entab, detab
In-Reply-To: <20210311211838.Z2QAs%steffen@sdaoden.eu>
References: <CAC0cEp9GVsYbjYhsYk2Hjjj90FxYFAia2Luy_vg854NTrV3Hww@mail.gmail.com>
<20210311211838.Z2QAs%steffen@sdaoden.eu>
Message-ID: <CAC0cEp93762jEt4BAed-tQ7-vi1YGVEket=B8Z-F-3finWUHbw@mail.gmail.com>
On Thu, Mar 11, 2021 at 4:18 PM Steffen Nurpmeso <steffen at sdaoden.eu> wrote:
> John P. Linderman wrote in
> <CAC0cEp9GVsYbjYhsYk2Hjjj90FxYFAia2Luy_vg854NTrV3Hww at mail.gmail.com>:
> |The tab/detab horse was still twitching, so I decided to beat it a little
> |more.
> |
> |Doug's claim that tabs saving space was an urban legend didn't ring true,
> |but betting again Doug is a good way to get poor quick.
>
> Not really. I mean, i do not insist of this, but i looked at the
> numbers. And despite col(1) 2.36.2 giving the wrong line when
> failing to dig a LATIN1 in UTF-8 (should be 7, gave 11), when
> i sum up the total of 8: in an old project with tests,
> documentation etc. here the output is 1044401. This is without
> generated data.
>
I'm not certain what you are referring to by "Not Really". But there is a
general issue about the ability of historical commands (like "ed") to
properly handle unicode. I would expect that many early commands do very
poorly. -- jpl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20210311/3e93c4bb/attachment.htm>
From steffen at sdaoden.eu Fri Mar 12 10:31:30 2021
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Fri, 12 Mar 2021 01:31:30 +0100
Subject: [COFF] Was [TUHS] tabs vs spaces - entab, detab
In-Reply-To: <CAC0cEp93762jEt4BAed-tQ7-vi1YGVEket=B8Z-F-3finWUHbw@mail.gmail.com>
References: <CAC0cEp9GVsYbjYhsYk2Hjjj90FxYFAia2Luy_vg854NTrV3Hww@mail.gmail.com>
<20210311211838.Z2QAs%steffen@sdaoden.eu>
<CAC0cEp93762jEt4BAed-tQ7-vi1YGVEket=B8Z-F-3finWUHbw@mail.gmail.com>
Message-ID: <20210312003130.L6HcL%steffen@sdaoden.eu>
John P. Linderman wrote in
<CAC0cEp93762jEt4BAed-tQ7-vi1YGVEket=B8Z-F-3finWUHbw at mail.gmail.com>:
|On Thu, Mar 11, 2021 at 4:18 PM Steffen Nurpmeso <steffen at sdaoden.eu> \
|wrote:
|> John P. Linderman wrote in
|> <CAC0cEp9GVsYbjYhsYk2Hjjj90FxYFAia2Luy_vg854NTrV3Hww at mail.gmail.com>:
|>|The tab/detab horse was still twitching, so I decided to beat it a little
|>|more.
|>|
|>|Doug's claim that tabs saving space was an urban legend didn't ring true,
|>|but betting again Doug is a good way to get poor quick.
|
|> Not really. I mean, i do not insist of this, but i looked at the
|> numbers. And despite col(1) 2.36.2 giving the wrong line when
|> failing to dig a LATIN1 in UTF-8 (should be 7, gave 11), when
|> i sum up the total of 8: in an old project with tests,
|> documentation etc. here the output is 1044401. This is without
|> generated data.
|
|I'm not certain what you are referring to by "Not Really". But there is a
I am sorry. It must have been bad english and a misunderstanding.
Especially surrounding the dead horse that was mentioned in the
original message of yours.
|general issue about the ability of historical commands (like "ed") to
|properly handle unicode. I would expect that many early commands do very
|poorly. -- jpl
Yes. Of course. It is one of these days were whatever i do
i stumble over errors in my own as well as in other peoples
software, and then this script of years was a nice try (i never
actually did that test), and then the find(1) i did spit out
masses of errors, and it took quite some trials to get it done.
I apologise. Just one of these days.
$ echo Müßig | iconv -f utf8 -t latin1 | LC_ALL=C col -x
col: failed on line 1: Invalid or incomplete multibyte or wide character
This should not happen. (Now also clarified by POSIX standard.)
#?1|kent:tmp$ cat <<_EOT | iconv -f utf8 -tlatin1 | LC_ALL=C col -x
one
two
three
four
five
älter
_EOT
col: failed on line 11: Invalid or incomplete multibyte or wide character
one
two
three
four
five
No fun for me today.
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
From henry.r.bent at gmail.com Fri Mar 12 04:18:20 2021
From: henry.r.bent at gmail.com (Henry Bent)
Date: Thu, 11 Mar 2021 13:18:20 -0500
Subject: [COFF] [TUHS] Pondering the hosts file
In-Reply-To: <CANCZdfrfKBcj3s4gW=y2bLd2nuM0nnSVMA0ZkcJ300p6szyzWw@mail.gmail.com>
References: <02d10a8e-2f39-4f88-f4c9-ecb295e0f01e@spamtrap.tnetconsulting.net>
<120EC052-FB1F-438F-985F-64E9CD82A9C1@iitbombay.org>
<CANCZdfrfKBcj3s4gW=y2bLd2nuM0nnSVMA0ZkcJ300p6szyzWw@mail.gmail.com>
Message-ID: <CAEdTPBfejUkNfxW2efF5eQW5kCtX30AMVOMwvv1bTrcWNyHBLQ@mail.gmail.com>
While this is true wrt the history of FreeBSD/Unix, I'm almost positive
> that BSD didn't invent it. I'm pretty sure it was picked up from the
> existing host file that was published by sri-nic.arpa before DNS.
>
> Warner
>
The CSRG history doesn't seem to have saved the full SCCS history of the
hosts manpage, but it must have appeared sometime around the addition of
ARP support to 4.1BSD - it's not in the 4.1C sources without ARP, but it is
in the sources with it. That version does indeed mention its origins:
HOSTS(5) File Formats Manual
HOSTS(5)
NAME
hosts - host name data base
DESCRIPTION
The hosts file contains information regarding the known hosts on
the
DARPA Internet. For each host a single line should be present with
the
following information:
official host name
Internet address
aliases
Items are separated by any number of blanks and/or tab characters.
A
``#'' indicates the beginning of a comment; characters up to the end
of
the line are not interpreted by routines which search the file.
This
file is normally created from the official host data base maintained
at
the Network Information Control Center (NIC), though local changes
may
be required to bring it up to date regarding unofficial aliases
and/or
unknown hosts.
Network addresses are specified in the conventional ``.'' notation
us-
ing the inet_addr() routine from the Internet address manipulation
li-
brary, inet(3). Host names may contain any printable character
other
than a field delimiter, newline, or comment character.
FILES
/etc/hosts
SEE ALSO
gethostent(3N)
BUGS
A name server should be used instead of a static file. A binary
in-
dexed file format should be available for fast access.
15 January 1983
HOSTS(5)
-Henry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20210311/79017fce/attachment-0001.htm>
From henry.r.bent at gmail.com Fri Mar 12 04:27:48 2021
From: henry.r.bent at gmail.com (Henry Bent)
Date: Thu, 11 Mar 2021 13:27:48 -0500
Subject: [COFF] [TUHS] Pondering the hosts file
In-Reply-To: <CAC20D2OF_ERtaioLWdw5N3vik6orb34ZKt=fgfM4PyEq8Mnfjw@mail.gmail.com>
References: <02d10a8e-2f39-4f88-f4c9-ecb295e0f01e@spamtrap.tnetconsulting.net>
<120EC052-FB1F-438F-985F-64E9CD82A9C1@iitbombay.org>
<CANCZdfrfKBcj3s4gW=y2bLd2nuM0nnSVMA0ZkcJ300p6szyzWw@mail.gmail.com>
<CAC20D2OF_ERtaioLWdw5N3vik6orb34ZKt=fgfM4PyEq8Mnfjw@mail.gmail.com>
Message-ID: <CAEdTPBdck300XiXwKyihJGHRsOeu0uOgNjTgs74UT3sfU6cgVA@mail.gmail.com>
On Thu, 11 Mar 2021 at 13:14, Clem Cole <clemc at ccc.com> wrote:
> The SRI file was different format. There was a tool that fetched and
> converted from the PDP-10 scheme to the UNIX scheme - gethtable(8) or
> something like that.
> á§
> á§
>
gettable(8) and htable(8):
GETTABLE(8C)
GETTABLE(8C)
NAME
gettable - get NIC format host tables from a host
SYNOPSIS
/etc/gettable host
DESCRIPTION
Gettable is a simple program used to obtain the NIC standard host
tables from a ``nicname'' server. The indicated host is queried for the
tables.
The tables, if retrieved, are placed in the file hosts.txt.
Gettable operates by opening a TCP connection to the port indicated
in the service specification for ``nicname''. A request is then made
for
``ALL'' names and the resultant information is placed in the output
file.
Gettable is best used in conjunction with the htable(8) program
which converts the NIC standard file format to that used by the network
library
lookup routines.
SEE ALSO
intro(3N), htable(8)
BUGS
Should allow requests for only part of the database.
4th Berkeley Distribution 4
March 1983
GETTABLE(8C)
HTABLE(8) System Manager's Manual
HTABLE(8)
NAME
htable - convert NIC standard format host tables
SYNOPSIS
/etc/htable file
DESCRIPTION
Htable is used to convert host files in the format specified in
Inter-
net RFC 810 to the format used by the network library routines.
Three
files are created as a result of running htable: hosts, networks,
and
gateways. The hosts file is used by the gethostent(3N) routines
in
mapping host names to addresses. The networks file is used by the
get-
netent(3N) routines in mapping network names to numbers. The
gateways
file is used by the routing daemon in identifying ``passive''
Internet
gateways; see routed(8C) for an explanation.
If any of the files localhosts, localnetworks, or localgateways
are
present in the current directory, the file's contents is prepended
to
the output file without interpretation. This allows sites to
maintain
local aliases and entries which are not normally present in the
master
database.
Htable is best used in conjunction with the gettable(8C) program
which
retrieves the NIC database from a host.
SEE ALSO
intro(3N), gettable(8C)
BUGS
Does not properly calculate the gateways file.
4th Berkeley Distribution 4 March 1983
HTABLE(8)
-Henry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20210311/fa66b6d0/attachment-0001.htm>
From jaapna at xs4all.nl Fri Mar 12 04:21:18 2021
From: jaapna at xs4all.nl (Jaap Akkerhuis)
Date: Thu, 11 Mar 2021 19:21:18 +0100
Subject: [COFF] [TUHS] Pondering the hosts file
In-Reply-To: <CAC20D2OF_ERtaioLWdw5N3vik6orb34ZKt=fgfM4PyEq8Mnfjw@mail.gmail.com>
References: <02d10a8e-2f39-4f88-f4c9-ecb295e0f01e@spamtrap.tnetconsulting.net>
<120EC052-FB1F-438F-985F-64E9CD82A9C1@iitbombay.org>
<CANCZdfrfKBcj3s4gW=y2bLd2nuM0nnSVMA0ZkcJ300p6szyzWw@mail.gmail.com>
<CAC20D2OF_ERtaioLWdw5N3vik6orb34ZKt=fgfM4PyEq8Mnfjw@mail.gmail.com>
Message-ID: <33B7C007-DFD4-42E9-94A6-534246F3F38F@xs4all.nl>
The "new" host table format is described in RFC 810 <https://tools.ietf.org/html/rfc810 <https://tools.ietf.org/html/rfc810> (mentions UNIX) but it goes back to RFC 608 (1974) or so.
jaap
> On Mar 11, 2021, at 19:12, Clem Cole <clemc at ccc.com> wrote:
>
> The SRI file was different format. There was a tool that fetched and converted from the PDP-10 scheme to the UNIX scheme - gethtable(8) or something like that.
> á§
> á§
>
> On Thu, Mar 11, 2021 at 1:08 PM Warner Losh <imp at bsdimp.com <mailto:imp at bsdimp.com>> wrote:
>
>
> On Thu, Mar 11, 2021 at 10:40 AM Bakul Shah <bakul at iitbombay.org <mailto:bakul at iitbombay.org>> wrote:
> From https://www.freebsd.org/cgi/man.cgi?hosts(5) <https://www.freebsd.org/cgi/man.cgi?hosts(5)>
> For each host a single line should be present with the following information:
> Internet address
> official host name
> aliases
> HISTORY <https://www.freebsd.org/cgi/man.cgi?hosts(5)#end>
> The hosts file format appeared in 4.2BSD.
>
> While this is true wrt the history of FreeBSD/Unix, I'm almost positive that BSD didn't invent it. I'm pretty sure it was picked up from the existing host file that was published by sri-nic.arpa before DNS.
>
> Warner
>
>> On Mar 11, 2021, at 9:14 AM, Grant Taylor via TUHS <tuhs at minnie.tuhs.org <mailto:tuhs at minnie.tuhs.org>> wrote:
>>
>> Hi,
>>
>> I'm not sure where this message best fits; TUHS, COFF, or Internet History, so please forgive me if this list is not the best location.
>>
>> I'm discussing the hosts file with someone and was wondering if there's any historical documentation around it's format and what should and should not be entered in the file.
>>
>> I've read the current man page on Gentoo Linux, but suspect that it's far from authoritative. I'm hoping that someone can point me to something more authoritative to the hosts file's format, guidelines around entering data, and how it's supposed to function.
>>
>> A couple of sticking points in the other discussion revolve around how many entries a host is supposed to have in the hosts file and any ramifications for having a host appear as an alias on multiple lines / entries. To whit, how correct / incorrect is the following:
>>
>> 192.0.2.1 host.example.net <http://host.example.net/> host
>> 127.0.0.1 localhost host.example.net <http://host.example.net/> host
>>
>>
>>
>> --
>> Grant. . . .
>> unix || die
>>
> _______________________________________________
> COFF mailing list
> COFF at minnie.tuhs.org <mailto:COFF at minnie.tuhs.org>
> https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff <https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20210311/ee786176/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 267 bytes
Desc: Message signed with OpenPGP
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20210311/ee786176/attachment-0001.sig>
From beebe at math.utah.edu Fri Mar 12 04:21:38 2021
From: beebe at math.utah.edu (Nelson H. F. Beebe)
Date: Thu, 11 Mar 2021 11:21:38 -0700
Subject: [COFF] [TUHS] Pondering the hosts file
In-Reply-To: <CAC20D2OF_ERtaioLWdw5N3vik6orb34ZKt=fgfM4PyEq8Mnfjw@mail.gmail.com>
Message-ID: <CMM.0.95.0.1615486898.beebe@gamma.math.utah.edu>
The hosts file format definition appears in
RFC 752: Universal host table
RFC 810: DoD Internet host table specification
RFC 952: DoD Internet host table specification
A 1986 hosts.txt file in my PDP-10 archives notes:
; The format for entries is:
;
; NET : NET-ADDR : NETNAME :
; GATEWAY : ADDR, ADDR : NAME : CPUTYPE : OPSYS : PROTOCOLS :
; HOST : ADDR, ALTERNATE-ADDR (if any): HOSTNAME,NICKNAME : CPUTYPE :
; OPSYS : PROTOCOLS :
;
; Where:
;; ADDR = internet address in decimal, e.g., 26.0.0.73
;; CPUTYPE = machine type (PDP-11/70, VAX-11/780, FOONLY-F3, C/30, etc.)
;; OPSYS = operating system (UNIX, TOPS20, TENEX, ITS, etc.)
;; PROTOCOLS = transport/service (TCP/TELNET,TCP/FTP, etc.)
;; : (colon) = field delimiter
;; :: (2 colons) = null field
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu -
- 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------