[TUHS] pre-UNIX legacy in UNIX?

[TUHS] pre-UNIX legacy in UNIX?

[Nigel Williams]

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

[TUHS] pre-UNIX legacy in UNIX?

[Lars Brinkhoff]

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.

[TUHS] pre-UNIX legacy in UNIX?

[Don Hopkins]

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 at 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171219/fa10fbd5/attachment.html>

[TUHS] pre-UNIX legacy in UNIX?

[Grant Taylor]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171219/443a14f3/attachment-0001.bin>

[TUHS] pre-UNIX legacy in UNIX?

[Ralph Corderoy]

Hi Grant,

> > https://en.wikipedia.org/wiki/Gecos_field
>
> 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

[TUHS] pre-UNIX legacy in UNIX?

[Grant Taylor]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171219/d17fe47d/attachment.bin>

[TUHS] pre-UNIX legacy in UNIX?

[arnold]

Grant Taylor via TUHS <tuhs at 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

[TUHS] History of passwd fullname/info/"gecos" field (was Re: pre-UNIX legacy in UNIX?)

[Random832]

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").

[TUHS] History of passwd fullname/info/"gecos" field (was Re: pre-UNIX legacy in UNIX?)

[Noel Hunt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 618 bytes --]

On Wed, Dec 20, 2017 at 9:30 AM, Random832 <random832 at 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.​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171220/160da76a/attachment.html>