Questions about CANONICAL

[Kevin Toppenberg]

I have been making good progress in sorting out the TTY IO issues in ydb, in regards to the terminal.   I am now trying to look at all the various combinations of states that might commonly arise.

One of the most vexing is "canonical" -- wherein the TTY IO subsystem is asked to provide line editing.  And when the end of input is provided, then return the entire buffer to ydb. 

In mupip, it makes sense to use canonical mode, because there is no fancy line editing etc needed.  But in straight ydb direct mode (dm) it really makes no sense to every use it from what I can tell. 

For example:

USE $IO:CANONICAL READ X#1

makes no sense.  In canonical mode, the TTY IO system won't release or return the IO to ydb until the user enters a LF or EOF or EOL.  So if they type 1 character, the read doesn't terminate. From the user's point of view, they are suddenly in a hung state where nothing they type seems to return control.  And if ECHO is off, it is especially confusing. If they happen to know that ^D can provide an EOF signal, sometimes they can get out.  But why would anyone want this pitfall to exist?

So what I have been doing in my corrections, is to look for special reads, e.g. READ *X or READ X#5 etc, and in those cases temporarily turn canonical back off until the READ is completed. 

What do you all think.  It is better to try to keep the user from putting themselves in a bind with canoncial by putting up guard rails?  Or better to let canonical be canonical -- pitfalls and all?  NOTE: I'm not sure ydb can be made to work well with it. 

In ydb, I can't think of any reason why I would ever want to use canonical. 

Feedback will be appreciated.

Kevin

[Maury Pepper]

KT, I'll not dig in to the TTY details, but just provide a warning: you (generally) can't remove a feature because you will break someone else's code. Now that you see something to avoid, you can program around it, but others may have already gone down that path and might be in dire straights if they upgraded ydb. On the other hand, if you find a need for adding a new feature, push on.

[Kevin Toppenberg]

I agree.  I don't want to remove any features for risk of breaking code.

Thanks

KT