Hi All:

What I need to do is to shell out to another program [GNUpg] and allow the user to interact with it (enter a pass phrase).

I have tried all the FpExec routines, the Shell routines.... etc. They ALL execute gpg correctly, with the proper command-line args, I see gpg's response on the console screen, and it's request for a pass phrase, but, the user can NOT interact with it as the keyboard is dead.

Now, this is understandable, since it is the main program which issued the shell command, and any input would have to come from the entity opening the shell (the parent program, not the console user).

Is there a way to re-direct the local console kybd to the new shell, allowing the user to interact with gpg? Or is there another way to do this? Perhaps shelling out is not the proper way to handle this?

The program is being compiled for Linux, with FPC 2.0.0

Best Regards
Bob

Do you use units or libraries that might put the terminal in raw mode? Ncurses,crt, video?

Marco van de Voort wrote

Do you use units or libraries that might put the terminal in raw mode? Ncurses,crt, video?

I am using "crt" for the readkey function in one of my procedures. No ncurses, no video. I am also smart-linking, so the only function compiled in from crt SHOULD be readkey.

I will look at unit CRT, and see if perhaps there is a termonal mode command I can issue. Thanks.

Bob

No, because the crt unit contains initialisation code, and initialisation code of a unit is obviously always linked in and executed. This initialisation code puts the terminal in raw mode, because it's required for crt's functionality. The crt unit does not contain an exported procedure to disable it, since that would also break all crt's functionality.

Jonas

Note that merely including crt already causes capturing of all output by the crt unit.

Try, - for testing purposes - to remove crt and use more basic input (readln), and see if it makes the problems disappear.

Thanks Jonas! That was the issue. So, I will just have to write my own readkey routine, and lose crt. Not a big deal.

Thanks again

Bob

Marco van de Voort wrote

Try, - for testing purposes - to remove crt and use more basic input (readln), and see if it makes the problems disappear.

Indeed! Problem gone! now to hide the user's typying from the screen. I was using readkey and echowing back a "*" during password input. I will have to do it another way.

Bob

Maybe not, depending on what OS you are working for, try using ncrt instead, I am pretty sure ncurses does NOT use raw mode so it may work.

A.J.

What do you use instead of readkey ?

Inpromptu

A.J. Venter wrote

Maybe not, depending on what OS you are working for, try using ncrt instead, I am pretty sure ncurses does NOT use raw mode so it may work.

Thanks for the reply A.J.

What I ended up using, and which worked perfectly was GetKeyEvent, TranslateKeyEvent(), KeyEventToString(), and GetKeyEventChar(), all in the keyboard unit.

The keyboard unit gives you very good control/access to keyboard events, without mucking with anything! The unit is a bit unfriendly, but powerful! A very good trade off.

The target platform for this job is Linux; but I believe the source should port to windows as well.

Bob