[Info-vax] CTRL/D Versus CTRL/Z

[John E. Malmberg]

On 6/30/2016 7:19 AM, John Reagan wrote:
> On Thursday, June 30, 2016 at 3:38:17 AM UTC-4, lawren... at gmail.com
> wrote:
>> Even though they started out very different, somehow along the way,
>> *nix systems managed to pick up most of the DEC conventions for
>> control characters (CTRL/C to interrupt a process, CTRL/Q and
>> CTRL/S for flow control, CTRL/U to discard the input line), except
>> one: the end-of-file indicator is CTRL/D, not CTRL/Z as it is on
>> DEC systems.
>>
>> Instead, CTRL/Z means “suspend the foreground process group”. This
>> is part of the job-control facility for managing multiple
>> concurrent processes. I also see a mention in the bash docs of a
>> “delayed-suspend” character, which defaults to (wait for it)
>> CTRL/Y. However, this might be a Hurd or BSD feature; it doesn’t
>> seem to be available on Linux.
>>
>> Did VMS ever pick up the idea of foreground/background process
>> groups?
>
> There is the ATTACH command that might solve some similar problems
> but isn't quite the same since it is a DCL command.

There are a couple of CRTL routines that claim to support process 
groups.  The documentation for them is insufficient to ues them.

For a group of programs that you have source for, the feature can be 
implemented using the VMS SYS$ENQ() have the foreground process hold the 
lock.

A generic solution would potentially need a change to how VMS starts up 
processes if that code is not already present.

For those not familiar with process groups, this would be the VMS 
equivalent (Going a bit from memory in the early morning, so I probably 
have a few things wrong).

1. Foreground process takes out a foreground lock which indicates that 
it gets access to data (and signals?) from sys$command:.

2. Foreground process has queued an blocking ast to relinquish the 
foreground lock on request.

3. Processes not holding the foreground lock treat reads from 
sys$command to be EOF.

4. A process moves from the background to the foreground by requesting 
the foreground lock.

And none of this deals with handling changing a child process to be a 
parent process or changing which process is the parent for a child, 
which would also be needed.

I suspect that a VMS implementation would require that the holder of the 
foreground lock to always be the parent process and that as long as the 
parent process is alive, any orphaned child processes would be adopted 
by it.

Control-D is the ancient modem disconnect character.  Sending it used to 
cause some modems to hang up according to some documentation I have 
read.  (DecSystem 10 manuals)

Which would have made it a very questionable control character to use 
for communication to a operating system, and probably why Digital 
operating systems did not use it.

Even odder is the Unix selection of Control-H (Backspace) character for 
delete, since no terminals at that time would send that code when you 
pushed the key labeled delete or rubout.

Terminals that could be configured to send a Control-H instead of delete 
did not appear until well after Unix was established.
(As well a various broken emulators that only sent Control-H, defaulted 
to Control-H, and sent the delete (0x7F) character for the keypad delete 
key)

The GNV Coreutils updated package reports the VMS settings for the 
control characters by providing a termios emulation layer.

Linux Utilities that assume Control-D is EOF instead of looking it up 
have a bug in them, as you can change the EOF character on Linux.

Regards,
-John
wb8tyw at qsl.net_work