Question about scope of Mumps USE command

[Kevin Toppenberg]

I have a question about the 'scope' of the USE command. 

I have been digging around in the yottadb source to track down some IO quirks.  See my other posts about that.  But my initial idea for a fix has revealed some other issues.

In the yottadb code, there is a function called resetterm(), which sends a 'reset' state to the TTY system.  This function is called many places, for example before getting user input from the command line, at the time of an interrupt, during rundown code, and when exiting yottadb.  With this sense of resetting the terminal it makes sense for resetterm() to hold an INITIAL state (before any yottadb changes), to be used in terminal restoration.

But resetterm() is also called after iott_rdone(), which is code for reading one character (i.e. READ *X), and iott_readfl(), which is code for reading a fixed length (i.e. READ X#3).  These forms of reading require special interaction with the IO system, so the TTY system has to be put into a special mode.  And to turn off this special mode, resetterm() is used.  The problem is that this revokes the last USE command.  E.g. see code below:

USE $P:(NOCANONICAL) 

READ *X

<-----   resetterm() at end of READ puts TTY back to initial state here.  USE revoked.

READ Y

In my other message thread, when I detected that resetterm was revoking the last USE command, my solution was to save the state of the last USE command, such that resetterm would use that during resets.  But the side effect of this is that those times where one would expect it to be a true reset to state prior to yottadb changes, instead one gets only the last USE state.  For example, when exiting yottadb, the initial state is not restored and the linux command line prompt might not have ECHO enabled. 

I found this site http://71.174.62.16/Demo/AnnoStd?Frame=Main&Edition=1977&Page=a108054#Def_0002 that seems to give a formal definition of expected USE function. It states:

The specified device remains current until such time as a new USE command is executed.

QUESTION:

Under what circumstances would it be proper to restore the INITIAL state (before any yottadb changes).  And what about the following circumstances?

• A program is running and has changed the USE parameters for $P.  The user then breaks execution returning to the command prompt.  Should USE settings be reset to INITIAL state?  I would say "yes".
  
• What code exits back to the command prompt normally, without crash etc.  Should the USE state of the code be continued?  I would say "no".
  
• If the user types a USE command at the command prompt, and presses enter.  And then types an additional command.  Should that USE settings still be active?  Or should a reset be done after each command?  I'm not sure on this one.
  

Right now, I think I am going to leave resetterm() alone, and not change its functionality in the codebase I am editing.  Instead, in the special circumstances of iott_rdone() and iott_readfl(), I will save off the TTY state at the beginning of the command, and restore that state at the end of the command instead of calling resetterm().

Comments and feedback will be appreciated.

Kevin

[Sam Habiel]

Your question isn't clear. What do you mean by "Command prompt"? The Unix Shell or M Direct Mode?

But I know the answer to your question: in an M session, outside of Direct Mode, IO is a state machine. Any changes are permanent. So USE is permanent. But it would be nice to not expose the permanent stuff to the shell. So yes, you are correct, if you exit from M to the shell, you are supposed to set the echo to back on. See commit d3f56d1ac007236ef2e7dfdda880471e7ced8efc for a similar issue.

Inside an M session with DIRECT MODE, this depends on the decisions chosen by the implementor. I think in Cache, if you turn off echo, too bad, you're cooked. In GT.M, Direct Mode takes good care to reset the terminal on every invocation.

--Sam

--
You received this message because you are subscribed to the Google Groups "Everything MUMPS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to everythingmum...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/everythingmumps/2b5c660d-55c7-4d63-8794-61aee7c44220n%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Kevin Toppenberg]

OK, I'm going to change my other solution.  I'll post details when I get the files ready.

KT