different types of keyboard input in cmd.exe

[Martin Vieregg]

I have recognized another tricky problem for my cmd.exe frontend: The types of keyboard input

There are in my opinion three types of keyboard input which have to be handled different in my editor:

(1) Prompt: The user types input after a prompt, can edit it and sends the input to cmd.exe by pressing ENTER. Before pressing ENTER, cmd.exe does not see any input at all.

(2) program read input: A commandline program requests user input, e.g. a Y/N query, or a string. This input is also finished by pressing ENTER.

An important difference between (1) and (2): In (1), cmd.exe echos the input as stdout. (4os2 does not.)

(3) Collecting text lines via "COPY CON": The editor collects several lines of user input and the input is finished by typing Ctrl-Z. After pressing Ctrl-Z, all lines incl. line end characters (^M^J) are sent to cmd.exe in one step.

In type (3), both cmd.exe and 4os2.exe does not allow to edit the previous lines, you cannot use the up cursor key. (But I will manage this.)

Stdin/out programs always require ENTER after a user input. VIO programs also allow a single keyboard key to continue processing.

My PM editor frontend needs to know which of the three types of keyboard input is current. To distinguish between (1) and (2), I analyze the prompt string which is shown at the beginning of the line.

My question concerns the type (3) "COPY CON": I need to interpretate the command which the user types behind the prompt. My first idea is to search for "<space>CON<space>" ? Which example commands do you have where this type of edit mode gets activated?

[Sergey Posokhov]

The only useful command I still remember is "print device driver report":
  copy ibms506$ con:

[Laurence Pithie]

My question concerns the type (3) "COPY CON": I need to interpretate the command which the user types behind the prompt. My first idea is to search for "<space>CON<space>" ?

You'll need to search for COPY followed by CON because there are other contexts in which CON is used (redirection for example). Doing that in a robust way is going to require dealing with an arbitrary number of spaces and text (filenames for example)  between the COPY and the CON so I would suggest using a regular expression.

However the command shell expects line oriented input, so if you send a line containing COPY CON then the shell will then read input on stdin line by line and echo that input on stdout, up until  it receives an EOF, which you're writing and reading stdin and stdout already anyway.

If what you wish to do is send an arbitrary block of text, possibly containing newlines, as an argument to an arbitrary command then I would suggest using a separate command to do that. Something along the lines of a send marked block command.

If you are doing all this command line processing before sending a line to the command processor you're not really creating a command line front end, you are implementing half a command processor and  duplicating  functions that the shell already implements. If that's what you want to do then you should look at examples of scanners and parsers. In the C world there are tools for creating these, Lexx and Yacc (Flex and Bison) Free Pascal comes with Plex and Pyacc. Using specialised tools for this is advisable because, while creating a scanner and parser isn't complicated it's not trivial , and creating an efficient scanner and parser is definitely not an exercise for the faint of heart. 

[Martin Vieregg]

Laurence,

yes, I have to distinguish between the two directions to CON or from CON, and there's the notation "CON:" with semicolon. So "COPY CON" should fit the purpose, and I will delete obsolete spaces before.

However the command shell expects line oriented input, so if you send a line containing COPY CON then the shell will then read input on stdin line by line and echo that input on stdout, up until  it receives an EOF, which you're writing and reading stdin and stdout already anyway.

Yes, you are right and I was wrong. This simple test in cmd.exe shows the behaviour:

Code: [Select]

[Z:\]copy con test.txt
one
two
three^C

[Z:\]type test.txt
one
two

[Z:\]
But the behaviour in my editor when running cmd.exe as an "input to output compiler" without own window output is different:

Code: [Select]

[Z:\]copy con test.txt
one
two
^Cree

[Z:\]one
SYS1041: The name one is not recognized as an internal or external command, operable program or batch file.

[Z:\]two
SYS1041: The name two is not recognized as an internal or external command, operable program or batch file.
[Z:\]

I have no idea why the behaviour differs. I am sending "one" and "two" with carriage return + line feed to cmd.exe and nothing happens.


My intension is to have a behaviour close as possible to cmd.exe. It is a good idea to implement an editor functionality with a new unique command like "editz" , or you start an external editor.

Later, beta testing will find out the cases where the behaviour differs from cmd.exe and which I have not programmed yet. I can test it only for my own purpose, and everyone uses cmd.exe in a different way.

[Laurence Pithie]

There's another case that you'll have to handle that COPY CON will not.

Code: [Select]

COPY filename.txt CON


[Martin Vieregg]

Code: [Select]

COPY filename.txt CON
Yes. the output is:

Code: [Select]

[Z:\]copy test.txt con:
one
two
        1 file(s) copied.

And in this case again, I have problems. I send the command to cmd.exe via stdin, and the file content is not shown in stdout, but the "1 file(s) copied." remark is shown.

Now I think I understand the problem. CON is the VIO window, not STDOUT ! In the VIO window, "one two" is shown, and the "1 file(s) copied" command is sent via STDOUT. So I have to simulate CON.

In the other direction (see two code fragments above), the same problem occurs. It does not work because cmd.exe waits for input in the VIO window and it does not get any. So after finishing the CON VIO command, the "one two" lines are received and interpretated as user prompt lines.

Is there a virtual file name like CON or NUL where I can write to stdout/read from stdin? Then I could simply change CON to the other expression, if the user wants this behaviour. (I will implement a lot of stored user settings.) I found this list for Windows in the Internet, OS/2 should be the same:
CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, and LPT9

So there should be two different behaviours the user can choose: modify CON to stdin/stdout or popping up the VIO window like I want to program if a VIO program has been started.

[Laurence Pithie]

CON is the virtual file name. Child processes inherit the open file handles of the parent so opening CON read write in the parent process with the appropriate mode befire calling DosExecPgm should be inherited by the cmd.exe process.