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

[Johnny Billquist]

On 2016-06-30 15:36, John E. Malmberg wrote:
> 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:
>>> 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.

I seem to remember some some select other programs also have an 
ATTACH/DETACH 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.

If this are to model how things are in Unix, a background process trying 
to read from stdin is blocked. It does not get 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)

Wow. That is more than I knew. But it sounds pretty plausible.

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

You know that ^H as delete is a very modern thing in Unix, right?
It only came about after the IBM PC became widespread, and Unix was 
ported to it.

Before then, DEL was more common, as most terminals had a key that sent 
that character, and not BS. (As you note.)

But original Unix used neither. It instead, horribly enough, used # for 
delete. (Hard to believe.)

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

Yes. And personally, I still consider using ^H for delete to be a broken 
idea.

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

Correct. And very few (if any) programs I've seen actually explicitly 
check for ^D, but instead just expects the terminal driver to give an 
EOF error when reading, which the terminal does based on what the 
settings are.

	Johnny