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

[bonefish]

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

[jackburton]

I'll have a look.

[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 ?

[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.

[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...

[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.

[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.

[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.

[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.

[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.

[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 ?

[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...

[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 :)

[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 ?

[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.

[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. :/

[jackburton]

Should be fixed in hrev21751. Can you confirm ?

[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 :-)

[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.

[jackburton]

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