Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2004-01

CRT prevents break?

6 messages · 3 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Alan Mead

I'm using "Free Pascal Compiler version 1.0.10 [2003/06/26] for i386" on Linux 2.4.7-10 and when I use the CRT unit, I cannot break a program with Control-C. Even Control-Z doesn't stop the program's execution. I have to kill it. I've attached an example program (compile with "-dSCREWED_UP" to see the behavior I'm talking about).

Is this a known issue? Is there any work-around? Sorry if this is in the manual, I don't see anything about this in the CRT documentation.

-Alan

__________________________________
Do you Yahoo!?
Find out what made the Top Yahoo! Searches of 2003 http://search.yahoo.com/top2003

Reply by email

Michael Van Canneyt
to Alan Mead
Alan Mead wrote 10 lines
I'm using "Free Pascal Compiler version 1.0.10 [2003/06/26] for i386" on Linux 2.4.7-10 and when I use the CRT unit, I cannot break a program with Control-C. Even Control-Z doesn't stop the program's execution. I have to kill it. I've attached an example program (compile with "-dSCREWED_UP" to see the behavior I'm talking about). Is this a known issue? Is there any work-around? Sorry if this is in the manual, I don't see anything about this in the CRT documentation.

This is a 'known issue'. It's normal behaviour. AFAIK, CTRL-C and CTRL-Z are normally handled by the shell. The CRT unit takes over the terminal, preventing the shell from catching these keys. There is no work-around except catching these keys yourself.

Michael.

Reply by email

Alan Mead
to Michael Van Canneyt
--- Michael Van Canneyt wrote 8 lines
This is a 'known issue'. It's normal behaviour. AFAIK, CTRL-C and CTRL-Z are normally handled by the shell. The CRT unit takes over the terminal, preventing the shell from catching these keys. There is no work-around except catching these keys yourself.

Thanks for the information. Can you give me a pointer to "catching these keys" myself? Also, does this mean that I won't have this trouble on Windows? I want to run it on a Windows XP machine as well.

-Alan

__________________________________
Do you Yahoo!?
Find out what made the Top Yahoo! Searches of 2003 http://search.yahoo.com/top2003

Reply by email

Unknown author
to Alan Mead
Alan Mead wrote 13 lines
--- Michael Van Canneyt wrote: > > This is a 'known issue'. It's normal behaviour. AFAIK, CTRL-C and > CTRL-Z > are normally handled by the shell. The CRT unit takes over the > terminal, > preventing the shell from catching these keys. There is no > work-around > except catching these keys yourself. Thanks for the information. Can you give me a pointer to "catching these keys" myself?

Just check the result of the next key with readkey. It should return #3 for ctrl-c, and #26 for ctrl-Z.

Also, does this mean that I won't have this trouble on Windows? I want to run it on a Windows XP machine as well.

On windows, I don't know how it will behave. Normally the same way, but it's of course Windows...

Michael.

Reply by email

Alan Mead
to Unknown author
--- wrote 6 lines
> Thanks for the information. Can you give me a pointer to "catching > these keys" myself? Just check the result of the next key with readkey. It should return #3 for ctrl-c, and #26 for ctrl-Z.

Ah. Now I see.

It's been a while ... is ReadKey blocking? If so, is there a non-blocking function? I recall I used to access the keyring in the BIOS directly and I believe that is not proper (or possible).

I would have to insert this check inside a loop doing the real work. Well, I guess I could make a non-blocking ReadKey using KeyPressed.

Thanks again for your help.

-Alan

__________________________________
Do you Yahoo!?
Find out what made the Top Yahoo! Searches of 2003 http://search.yahoo.com/top2003

Reply by email

Unknown author
to Alan Mead
Alan Mead wrote 17 lines
--- wrote: > > Thanks for the information. Can you give me a pointer to > "catching > > these keys" myself? > > Just check the result of the next key with readkey. > It should return #3 for ctrl-c, and #26 for ctrl-Z. Ah. Now I see. It's been a while ... is ReadKey blocking? If so, is there a non-blocking function? I recall I used to access the keyring in the BIOS directly and I believe that is not proper (or possible). I would have to insert this check inside a loop doing the real work. Well, I guess I could make a non-blocking ReadKey using KeyPressed.

That is why it is there :-)

Michael.

Reply by email