Opened 12 years ago

Closed 12 years ago

#1340 closed bug (fixed)

Terminal doesn't produce the EOF character on Ctrl-D

Reported by: bonefish Owned by: jackburton
Priority: normal Milestone: R1
Component: Applications/Terminal Version: R1/pre-alpha1
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

It seems that the terminal produces a three character escape sequence when Ctrl-D is pressed instead of the correct (single) character. This causes Ctrl-D not to have the desired effect. E.g.

cat > /dev/null

can not be terminated with Ctrl-D. This works fine with Be's Terminal under Haiku.

Revision: hrev21735

Change History (20)

comment:1 Changed 12 years ago by jackburton

I'll have a look.

comment:2 Changed 12 years ago by jackburton

I added a printf() in TermView::KeyDown(), and on CTRL-d, I get "4", the correct ASCII value for EOT, which is the default value for EOF. Should I enable debugging in ttys to see that three charachter escape value ?

comment:3 Changed 12 years ago by bonefish

If you add the following in master_write() (src/add-ons/kernel/drivers/tty/master.cpp):

dprintf("master_write(%p, %p, %lu)\n", cookie, buffer, *_length);
for (size_t i = 0; i < *_length; i++) {
dprintf("  %d", ((const char*)buffer)[i]);
}
dprintf("\n");

you'll see that "27 91 91" is written to the master end of the tty when Ctrl-D is pressed. If the Terminal receives the correct char from the app server, it apparently translates it before writing to the tty.

comment:4 Changed 12 years ago by jackburton

Ok, I found the problem. CTRL-D is 4, which is exactly the enum for B_END. Since B_END is handled in a special way in TermView::KeyDown(), we get that three character sequence. I wonder how I fix this...

comment:5 in reply to:  4 ; Changed 12 years ago by jackburton

Replying to jackburton:

Ok, I found the problem. CTRL-D is 4, which is exactly the enum for B_END. Since B_END is handled in a special way in TermView::KeyDown(), we get that three character sequence. I wonder how I fix this...

Oh yeah. Now I see why there was that (supposedly) weird code in TermView::Keydown() (which I removed). Check hrev21557 for example. I'll reintroduce that code. This should fix the problem.

comment:6 in reply to:  5 ; Changed 12 years ago by korli

Replying to jackburton:

Oh yeah. Now I see why there was that (supposedly) weird code in TermView::Keydown() (which I removed). Check hrev21557 for example. I'll reintroduce that code. This should fix the problem.

bytes shouldn't be checked for B_END and others, keycode should be. The first one is generated from the keycode based on the keymap.

comment:7 in reply to:  6 ; Changed 12 years ago by jackburton

Replying to korli:

bytes shouldn't be checked for B_END and others, keycode should be. The first one is generated from the keycode based on the keymap.

Do you mean the int32 "key" field in the current message ? Or you mean the other way round ?

I'm confused.

comment:8 Changed 12 years ago by bonefish

You could get CurrentMessage() from the window and check the "raw_key" field. It should contain a "d", if indeed Ctrl=D has been pressed.

comment:9 in reply to:  7 ; Changed 12 years ago by korli

bytes shouldn't be checked for B_END and others, keycode should be. The first one is generated from the keycode based on the keymap.

Do you mean the int32 "key" field in the current message ? Or you mean the other way round ?

Sorry I meant "key" is the keycode and should be checked for B_END and co.

comment:10 in reply to:  9 ; Changed 12 years ago by jackburton

Replying to korli:

Sorry I meant "key" is the keycode and should be checked for B_END and co.

So BTextView::KeyDown() is wrong too ?

comment:11 in reply to:  10 Changed 12 years ago by jackburton

Replying to jackburton:

Replying to korli:

Sorry I meant "key" is the keycode and should be checked for B_END and co.

So BTextView::KeyDown() is wrong too ?

Replying to myself: http://www.beunited.org/bebook/The%20Interface%20Kit/ViewHooks.html#KeyDown()

"Single-byte characters can be tested against ASCII codes and these constants:"

B_BACKSPACE B_LEFT_ARROW B_INSERT

etc. etc.

I'm still confused...

comment:12 in reply to:  10 Changed 12 years ago by korli

Replying to jackburton:

Replying to korli:

Sorry I meant "key" is the keycode and should be checked for B_END and co.

So BTextView::KeyDown() is wrong too ?

Checking, and the keymap translates to B_* so it is OK to check bytes ... Sorry for the confusion :)

comment:13 in reply to:  8 ; Changed 12 years ago by jackburton

Replying to bonefish:

You could get CurrentMessage() from the window and check the "raw_key" field. It should contain a "d", if indeed Ctrl=D has been pressed.

Yeah, but then I should do that in any case, independently of the data I get from the "bytes" argument ?

comment:14 in reply to:  13 ; Changed 12 years ago by bonefish

Replying to jackburton:

Replying to bonefish:

You could get CurrentMessage() from the window and check the "raw_key" field. It should contain a "d", if indeed Ctrl=D has been pressed.

Yeah, but then I should do that in any case, independently of the data I get from the "bytes" argument ?

There are several B_* constants that hide actual characters. I suppose it would make sense to that special handling for all of those.

comment:15 in reply to:  14 Changed 12 years ago by jackburton

Replying to bonefish:

There are several B_* constants that hide actual characters. I suppose it would make sense to that special handling for all of those.

Ok. That's pretty much what the code did before. I'll revert it, then I'll try to see if I can clean it up. Never touch something you don't fully understand. :/

comment:16 Changed 12 years ago by jackburton

Status: newassigned

comment:17 Changed 12 years ago by jackburton

Should be fixed in hrev21751. Can you confirm ?

comment:18 Changed 12 years ago by axeld

Ingo just confirms that it is working now.

BTW I"key" is still wrong, and must actually be "raw_key" (from the message).

The "key" (or keycode) is indeed the physical key pressed on the keyboard - but that's not really what you want here. What you actually want is the key that says 'd' - and that's exactly what "raw_key" is about (it gives you the difference between the "End" key and the "d" in this case).

So I'm leaving this bug open for now for your measurement :-)

comment:19 in reply to:  18 Changed 12 years ago by jackburton

Replying to axeld:

Ingo just confirms that it is working now.

BTW I"key" is still wrong, and must actually be "raw_key" (from the message).

The "key" (or keycode) is indeed the physical key pressed on the keyboard - but that's not really what you want here. What you actually want is the key that says 'd' - and that's exactly what "raw_key" is about (it gives you the difference between the "End" key and the "d" in this case).

So I'm leaving this bug open for now for your measurement :-)

Ok. Thank you all for the help.

comment:20 Changed 12 years ago by jackburton

Resolution: fixed
Status: assignedclosed

Original bug is fixed, and in hrev22512 I also check against "raw_char" instead of using "key". Seems to work fine. Closing.

Note: See TracTickets for help on using tickets.