19 Dec
2017
19 Dec
'17
6 a.m.
I blundered today into the GECOS field in /etc/passwd:
https://en.wikipedia.org/wiki/Gecos_field
"Some early Unix systems at Bell Labs used GECOS machines for print
spooling and various other services,[3] so this field was added to
carry information on a user's GECOS identity."
I had forgotten about this field and I don't recall it being
previously described as related to GECOS (I likely didn't take note at
the time I first encountered it).
Aside from the influence of Multics and other things on UNIX design
are there other tangible[1] manifestations of non-UNIX operating
system things like the GECOS field that were carried forward intact in
later UNIX implementations?
[1] things can be pointed at, rather than design ideas
19 Dec
19 Dec
6:21 a.m.
Nigel Williams wrote:
Aside from the influence of Multics and other things
on UNIX design
are there other tangible[1] manifestations of non-UNIX operating
system things like the GECOS field that were carried forward intact in
later UNIX implementations?
Job control was inspired by ITS job control capabilities. Control-Z
does pretty much the same thing in both operating systems.
7:07 a.m.
On ITS, you could pass a job back and forth between users, like a joint! ;) It was a very
social operating system.
http://victor.se/bjorn/its/ddt.html#Sophisticated
<http://victor.se/bjorn/its/ddt.html#Sophisticated>
:DISOWN
$$^K
"disowns" the current job. The job continues to exist, and if it was running
continues to run, but it ceases to be DDT's inferior. Any information DDT has about
the job that is not actually in the job itself is lost (for example, the starting address
and symbols of the program). When a job has been disowned it no longer has a terminal, and
if it tries to read from or print on its terminal it will halt. Disowning allows a job to
continue to exist after the DDT that created it has logged out or been killed. It makes it
possible to leave a job running without tying up a terminal.
A disowned job can be reowned by selecting it with :JOB. What's more, any user can
reown a job no matter who disowned it, using the :UJOB command and specifying the UNAME of
the disowned job, as in :UJOB FOOSH TECO to reown the TECO that user FOOSH disowned. This
makes it possible to hand a job to another user.
:UJOB <uname> <jname>
Selects the specified job (which can be any job in the system) for examination. If the job
is disowned, it will have it's UNAME changed to your UNAME and will be reowned.
Otherwise it will remain a foriegn job, i.e. can be examined but not modified or
proceeded.
:DETACH
detaches the user's whole job-tree. The console becomes free just as if it had logged
out, but the jobs are not destroyed. They remain in the system without a console. A
detached job is just like a disowned job (see :DISOWN), but got that way differently. The
opposite of detaching is attaching. There is a :ATTACH command which performs that
operation, but it is too primitive to be convenient in the usual case (don't use it
without reading the reference section). However, after logging in DDT automatically checks
for the existence of a detached tree and offers to attach to it. After a <space> is
typed, the formerly detached tree will be connected to the console (which need not be the
same one it was detached from). The new DDT that did the attaching will no longer exist.
If something "goes wrong" with the console, a tree may be detached automatically
by the system. For example, if a user coming over the ARPA network closes his connection,
his tree will be detached. The same thing happens to all users of TV terminals if the TV
front-end PDP-11 crashes. When this happens, the detached tree will be destroyed by the
system after an hour goes by, unless it is attached first. As described above, logging
back in will automatically tell the new DDT to look for the old detached one and offer to
attach it.
There is a program called REATTACH designed specifically for detaching jobs from consoles
and attaching jobs to consoles. It can be used to move your jobs to another console, from
either the old console, the new console, or someone else's console. :REATTACH
HELP<cr> will print its documentation.
:ATTACH
makes the current job (which must be running) become the top level job, in place of DDT.
That job's name is changed to HACTRN, and the existing HACTRN job (containing DDT) is
killed, along with any other inferiors it may have. :ATTACH is very dangerous for that
reason. Its main use is to set up a program other than DDT as the top-level command
processor. It is possible to use :ATTACH to do the opposite of :DETACH. Just reown the
detached former HACTRN (now called HACTRO or HACTRP or ...) using :JOB, and then :ATTACH
it. However, it is probably safer to use the REATTACH program. Type :REATTACH ?<cr>
for information.
:SNARF <jname>
When a HACTRN is detached because of trouble with the terminal, but is still basically
healthy, it can be attached. When a HACTRN is detached because of fatal errors, it stops
running and can't be attached (and, having run into such trouble, it would probably
be useless if it were attached). However, its inferiors are likely to be unharmed. The
:SNARF command exists to rescue those inferiors from under the sinking DDT. It is meant to
be used after reowning that DDT as a subjob of a new, healthy DDT. The dead DDT should be
the current job. :SNARF takes away the current job's inferior named <jname> and
makes it a direct inferior of the DDT executing the :SNARF. Thus, after a HACTRN dies
while having a TECO under it (and thus changes to a HACTRO), one can do (in a new HACTRN)
:JOB HACTRO to reown the dead DDT, and :SNARF TECO<cr> to take the TECO away from
it. The job TECO is then an inferior of the new HACTRN, and the HACTRO job can be killed
without harm to the TECO. If you try to :SNARF a nonexistent job, a "No such
job" error will result. :SNARF works by writing into the current job a program to
disown any inferior named <jname>, and then doing a :JOB <jname>. Thus, :SNARF
can garbage the job snarfed from. This is small loss when the job is already dead.
-Don
On 19 Dec 2017, at 07:21, Lars Brinkhoff
<lars(a)nocrew.org> wrote:
Nigel Williams wrote:
Aside from the influence of Multics and other
things on UNIX design
are there other tangible[1] manifestations of non-UNIX operating
system things like the GECOS field that were carried forward intact in
later UNIX implementations?
Job control was inspired by ITS job control capabilities. Control-Z
does pretty much the same thing in both operating systems. 
6:21 p.m.
On 12/18/2017 11:00 PM, Nigel Williams wrote:
I blundered today into the GECOS field in
/etc/passwd:
https://en.wikipedia.org/wiki/Gecos_field
"Some early Unix systems at Bell Labs used GECOS machines for print
spooling and various other services,[3] so this field was added to
carry information on a user's GECOS identity."
Was the GECOS field meant to be consumed by a computer or human?
All the descriptions I've seen about the GECOS field made me think that
it was for human friendly information [1] and not really machine parsable.
So, was there some sort of ID in the GECOS field in a users /etc/passwd
entry that was then used by the GECOS machine / OS to identify the user?
Or is my (complete) ignorance of GECOS (OS) showing that I'm not aware
of something about user IDs on GECOS (OS)?
I had forgotten about this field and I don't
recall it being
previously described as related to GECOS (I likely didn't take note at
the time I first encountered it).
I had often wondered why it was called "GECOS", but had never really
given it any thought as it seemed logical to have something to store the
users contact information somewhere convenient and easily accessible by
all applications. Thus the /etc/passwd file seemed like a logical choice.
Now I wonder if we are using the GECOS field to store the same data as
years ago? Or did we re-purpose the now unneeded GECOS to store name,
address, office phone number, home phone, etc?
I never knew about GECOS (OS) to put two and two together.
#questionsQuestions
--
Grant. . . .
unix || die
7:05 p.m.
Hi Grant,
Was the GECOS field meant to be consumed by a computer or human?
Computer for its original purpose. And computer again when things like
finger(1) would take it apart. As well as reading the above page,
there's http://catb.org/jargon/html/G/GECOS.html
--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy
8:03 p.m.
On 12/19/2017 12:05 PM, Ralph Corderoy wrote:
Hi Grant,
Hi Ralph,
Computer for its original purpose. And computer again
when things like
finger(1) would take it apart. As well as reading the above page,
there's http://catb.org/jargon/html/G/GECOS.html
Thank you for the Jargon file link. It clearly indicates that the GECOS
field held the GECOS user ID.
So I guess at some point we transitioned from the GECOS user ID to the
comma delimited format that we use today. I suppose it was after there
was no longer a need to store GECOS user IDs.
--
Grant. . . .
unix || die
8:14 p.m.
Grant Taylor via TUHS <tuhs(a)minnie.tuhs.org> wrote:
So I guess at some point we transitioned from the
GECOS user ID to the
comma delimited format that we use today. I suppose it was after there
was no longer a need to store GECOS user IDs.
I think this happened at UCB, where they split it into comma-separated
fields indicating full name, office, phone number and something else
I don't remember at the moment. Probably for the finger command. I'm
pretty sure the BSD passwd(7) (or was it passwd(5)?) man page described
things in detail.
HTH,
Arnold
10:30 p.m.
New subject: History of passwd fullname/info/"gecos" field (was Re: pre-UNIX legacy in UNIX?)
On Tue, Dec 19, 2017, at 13:21, Grant Taylor via TUHS wrote:
Now I wonder if we are using the GECOS field to store
the same data as
years ago? Or did we re-purpose the now unneeded GECOS to store name,
address, office phone number, home phone, etc?
The V6 and V7 passwd manpage says "GCOS job number, box number, optional GCOS
user-id", and "The GCOS field is used only when communicating with that system,
and in other installations can contain any desired information." (Has all information
on what tools were used to communicate with it and how they consumed the passwd file been
lost to history?)
V3 and V4 say "GCOS job number and box number".
V2 does not have the field.
PWB describes the field as "comment" and says "The comment field should
identify the user, e.g., <dept #> name (account #)." The distributed passwd
file seems to have some structure to this field, with system accounts (all of the accounts
in the file except "games") beginning with a dash and having (9999) after [the
use of which is unclear].
It looks like the usage to store the other things in the specific modern format originated
at Berkeley - the chfn utility appears in 3BSD, with a description of this format in the
manpage (which likely influenced other sites), and 4.2BSD prompts for each field
individually. The format is associated with the Finger utility, which first appears in
2BSD and has the following comment in its source code:
/* This is a finger program. It prints out useful information about users
* by digging it up from various system files. It is not very portable
* because the most useful parts of the information (the full user name,
* office, and phone numbers) are all stored in the VAX-unused gecos field
* of /etc/passwd, which, unfortunately, other UNIXes use for other things.
AUSAM contains extensive modifications to the code around the passwd handling - it uses a
binary hashtable-based passwd database, with separate first and last name fields and a
"staff or student number" (referred to in code as "other").
20 Dec
20 Dec
3:07 a.m.
New subject: History of passwd fullname/info/"gecos" field (was Re: pre-UNIX legacy in UNIX?)
On Wed, Dec 20, 2017 at 9:30 AM, Random832 <random832(a)fastmail.com> wrote:
AUSAM contains extensive modifications to the code
around the passwd
handling - it uses a binary hashtable-based passwd database, with separate
first and last name fields and a "staff or student number" (referred to in
code as "other").
And I have a dim memory that when we started using Eight Edition (at
Basser) the password file was a mounted process.
2329
days inactive
2330
days old
8 comments
8 participants
participants (8)
-
arnold＠skeeve.com -
Don Hopkins -
Grant Taylor -
Lars Brinkhoff -
Nigel Williams -
Noel Hunt -
Ralph Corderoy -
Random832