Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #125938 > unrolled thread

Correct way to detect F1

Back to article view | Back to comp.lang.c

Contents

  Correct way to detect F1 shinobi@f122.n1.z21.fsxnet (shinobi) - 2018-01-29 03:44 +1200
    Re: Correct way to detect F1 Lorinczy Zsigmond <zsiga@nospam.for.me> - 2018-01-29 10:34 +0100
      Re: Correct way to detect F1 Keith Thompson <kst-u@mib.org> - 2018-01-29 09:24 -0800
        Re: Correct way to detect F1 "James R. Kuyper" <jameskuyper@verizon.net> - 2018-01-29 12:43 -0500
          Re: Correct way to detect F1 scott@slp53.sl.home (Scott Lurndal) - 2018-01-29 18:20 +0000
        Re: Correct way to detect F1 ais523 <ais523@nethack4.org> - 2018-01-29 21:03 +0000
          Re: Correct way to detect F1 Robert Wessel <robertwessel2@yahoo.com> - 2018-01-29 20:47 -0600
            Re: Correct way to detect F1 Keith Thompson <kst-u@mib.org> - 2018-01-29 20:01 -0800
              Re: Correct way to detect F1 Robert Wessel <robertwessel2@yahoo.com> - 2018-01-29 22:43 -0600
    Re: Correct way to detect F1 Ike Naar <ike@iceland.freeshell.org> - 2018-01-29 10:26 +0000
    Re: Correct way to detect F1 "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2018-01-30 14:14 +0800
    Re: Correct way to detect F1 luser droog <luser.droog@gmail.com> - 2018-01-30 09:26 -0800
    Re: Correct way to detect F1 bartc <bc@freeuk.com> - 2018-01-30 18:39 +0000
    Re: Correct way to detect F1 Egor <egor@ruby.local> - 2018-02-08 14:21 +0200
      Re: Correct way to detect F1 shinobi@f153.n1.z21.fsxnet (shinobi) - 2018-02-08 16:41 +1200
        Re: Correct way to detect F1 Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-02-08 20:43 +0000
          Re: Correct way to detect F1 Keith Thompson <kst-u@mib.org> - 2018-02-08 13:13 -0800
            Re: Correct way to detect F1 scott@slp53.sl.home (Scott Lurndal) - 2018-02-08 22:14 +0000
      Re: Correct way to detect F1 Keith Thompson <kst-u@mib.org> - 2018-02-08 10:29 -0800
        Re: Correct way to detect F1 Egor <egor@ruby.local> - 2018-02-09 15:05 +0200
          Re: Correct way to detect F1 Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-02-09 17:30 +0000
          Re: Correct way to detect F1 Keith Thompson <kst-u@mib.org> - 2018-02-09 10:06 -0800
      Re: Correct way to detect F1 luser droog <luser.droog@gmail.com> - 2018-02-08 16:31 -0800

Page 1 of 2  [1] 2  Next page →

#125938 — Correct way to detect F1

Hello All,

I wonder. What's the correct way to detect F1 in Linux Console?

I guess getchar() returns character. And to my wonder it dispays
different value using %d and %c. That's the best I came up with
recently. Is there any better method?

___ CUT HERE ---

//
// BASIC HELPER FOR REWRITE TO 2.7.11                                          

//
#include <stdio.h>

int main () {

  int c;
  int e;
  printf("Enter key\n");
  for (;;) {
    c=getchar();
    if (c==27) {
      e=getchar();
      printf("Detected ESC %d %c\n",c,e);
      if (e == '1') {
        printf("F1\n");
      }
    } else {
      printf("No ESC Detected %d %c\n",c);
    }
  }
  return 0;
}


___ CUT HERE ---

Thanks for any help / hint


... Internal Error: The system has been taken over by sheep at line 19960
___ MultiMail/Linux v0.49

[toc] | [next] | [standalone]

#125939

On 2018-01-28 16:44, shinobi wrote:
> I wonder. What's the correct way to detect F1 in Linux Console?

It would be getch of ncurses
https://linux.die.net/man/3/getch
https://linux.die.net/man/3/keypad

[toc] | [prev] | [next] | [standalone]

#125954

Lorinczy Zsigmond <zsiga@nospam.for.me> writes:
> On 2018-01-28 16:44, shinobi wrote:
>> I wonder. What's the correct way to detect F1 in Linux Console?
>
> It would be getch of ncurses
> https://linux.die.net/man/3/getch
> https://linux.die.net/man/3/keypad

ncurses, at least in normal use, takes over the terminal screen.
That's fine for something like a text editor or file viewer, but
it's overkill for a program that just wants to detect F1 on input.

The sequence sent by F1 can vary depending on what kind of terminal
you're using, though (almost?) all terminal emulators these days
use VT100-like sequences by default.

There's probably a clean way to handle function keys on UNIX-like
systems without resorting to ncurses.  comp.unix.programmer would
be a good place to ask.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#125955

On 01/29/2018 12:24 PM, Keith Thompson wrote:
> Lorinczy Zsigmond <zsiga@nospam.for.me> writes:
>> On 2018-01-28 16:44, shinobi wrote:
>>> I wonder. What's the correct way to detect F1 in Linux Console?
>>
>> It would be getch of ncurses
>> https://linux.die.net/man/3/getch
>> https://linux.die.net/man/3/keypad
> 
> ncurses, at least in normal use, takes over the terminal screen.
> That's fine for something like a text editor or file viewer, but
> it's overkill for a program that just wants to detect F1 on input.

There's a problem though - if your program doesn't take over the 
terminal screen, there's a good chance that something else is currently 
using it, and intercepting F1 before your program has a chance to see it.
On my current machine, while using thunderbird to write this message, F1 
opens my web browser and takes me to 
<https://support.mozilla.org/en-US/products/thunderbird>. In a terminal 
window, F1 opens a window providing help with using the terminal. If I 
make sure that no window is selected, F1 brings up GNOME help for 
"Files, folders, and search".

[toc] | [prev] | [next] | [standalone]

#125956

"James R. Kuyper" <jameskuyper@verizon.net> writes:
>On 01/29/2018 12:24 PM, Keith Thompson wrote:
>> Lorinczy Zsigmond <zsiga@nospam.for.me> writes:
>>> On 2018-01-28 16:44, shinobi wrote:
>>>> I wonder. What's the correct way to detect F1 in Linux Console?
>>>
>>> It would be getch of ncurses
>>> https://linux.die.net/man/3/getch
>>> https://linux.die.net/man/3/keypad
>> 
>> ncurses, at least in normal use, takes over the terminal screen.
>> That's fine for something like a text editor or file viewer, but
>> it's overkill for a program that just wants to detect F1 on input.
>
>There's a problem though - if your program doesn't take over the 
>terminal screen, there's a good chance that something else is currently 
>using it, and intercepting F1 before your program has a chance to see it.
>On my current machine, while using thunderbird to write this message, F1 
>opens my web browser and takes me to 
><https://support.mozilla.org/en-US/products/thunderbird>. In a terminal 
>window, F1 opens a window providing help with using the terminal. If I 
>make sure that no window is selected, F1 brings up GNOME help for 
>"Files, folders, and search".

Well, one can use xterm instead of gnome-terminal....

[toc] | [prev] | [next] | [standalone]

#125961

Keith Thompson wrote:
> The sequence sent by F1 can vary depending on what kind of terminal
> you're using, though (almost?) all terminal emulators these days
> use VT100-like sequences by default.

This is a problem with F1 in particular, though. The VT100's physical F1
key is interpreted directly by the terminal itself and can't be
intercepted by software. As a result, terminal emulators that use
VT100-like sequences don't generally agree on what code should be used
for F1 (because they can't just copy from a VT100 as it didn't have one).

Note also that similarly to a VT100, some terminal emulators will use F1
for their own purposes (e.g. showing a help screen), rather than passing
it on to an application running inside the terminal emulator.

-- 
ais523

[toc] | [prev] | [next] | [standalone]

#125977

On Mon, 29 Jan 2018 21:03:41 -0000 (UTC), ais523 <ais523@nethack4.org>
wrote:

>Keith Thompson wrote:
>> The sequence sent by F1 can vary depending on what kind of terminal
>> you're using, though (almost?) all terminal emulators these days
>> use VT100-like sequences by default.
>
>This is a problem with F1 in particular, though. The VT100's physical F1
>key is interpreted directly by the terminal itself and can't be
>intercepted by software. As a result, terminal emulators that use
>VT100-like sequences don't generally agree on what code should be used
>for F1 (because they can't just copy from a VT100 as it didn't have one).
>
>Note also that similarly to a VT100, some terminal emulators will use F1
>for their own purposes (e.g. showing a help screen), rather than passing
>it on to an application running inside the terminal emulator.


Well a VT220 doesn't have an F1 key at all, the first key on the top
row is "hold screen".  And none of the first five keys on the top row
are really programmable, as are the sixth (and subsequent) keys (which
start with F6).

I have seen emulators map the PC keyboard's F1 key to the VT220 "Help"
key, which is a user definable key often called F15.

[toc] | [prev] | [next] | [standalone]

#125978

Robert Wessel <robertwessel2@yahoo.com> writes:
> On Mon, 29 Jan 2018 21:03:41 -0000 (UTC), ais523 <ais523@nethack4.org>
> wrote:
>>Keith Thompson wrote:
>>> The sequence sent by F1 can vary depending on what kind of terminal
>>> you're using, though (almost?) all terminal emulators these days
>>> use VT100-like sequences by default.
>>
>>This is a problem with F1 in particular, though. The VT100's physical F1
>>key is interpreted directly by the terminal itself and can't be
>>intercepted by software. As a result, terminal emulators that use
>>VT100-like sequences don't generally agree on what code should be used
>>for F1 (because they can't just copy from a VT100 as it didn't have one).
>>
>>Note also that similarly to a VT100, some terminal emulators will use F1
>>for their own purposes (e.g. showing a help screen), rather than passing
>>it on to an application running inside the terminal emulator.
>
> Well a VT220 doesn't have an F1 key at all, the first key on the top
> row is "hold screen".  And none of the first five keys on the top row
> are really programmable, as are the sixth (and subsequent) keys (which
> start with F6).
>
> I have seen emulators map the PC keyboard's F1 key to the VT220 "Help"
> key, which is a user definable key often called F15.

The Wikipedia article on the VT220 has a photo of one with a keyboard
that definitely has a key labeled "F1".  I think the label strip might
be replaceable.  I'll take your word for the rest of it, though.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#125979

On Mon, 29 Jan 2018 20:01:38 -0800, Keith Thompson <kst-u@mib.org>
wrote:

>Robert Wessel <robertwessel2@yahoo.com> writes:
>> On Mon, 29 Jan 2018 21:03:41 -0000 (UTC), ais523 <ais523@nethack4.org>
>> wrote:
>>>Keith Thompson wrote:
>>>> The sequence sent by F1 can vary depending on what kind of terminal
>>>> you're using, though (almost?) all terminal emulators these days
>>>> use VT100-like sequences by default.
>>>
>>>This is a problem with F1 in particular, though. The VT100's physical F1
>>>key is interpreted directly by the terminal itself and can't be
>>>intercepted by software. As a result, terminal emulators that use
>>>VT100-like sequences don't generally agree on what code should be used
>>>for F1 (because they can't just copy from a VT100 as it didn't have one).
>>>
>>>Note also that similarly to a VT100, some terminal emulators will use F1
>>>for their own purposes (e.g. showing a help screen), rather than passing
>>>it on to an application running inside the terminal emulator.
>>
>> Well a VT220 doesn't have an F1 key at all, the first key on the top
>> row is "hold screen".  And none of the first five keys on the top row
>> are really programmable, as are the sixth (and subsequent) keys (which
>> start with F6).
>>
>> I have seen emulators map the PC keyboard's F1 key to the VT220 "Help"
>> key, which is a user definable key often called F15.
>
>The Wikipedia article on the VT220 has a photo of one with a keyboard
>that definitely has a key labeled "F1".  I think the label strip might
>be replaceable.  I'll take your word for the rest of it, though.


Most VT-220s has LK201 keyboards, which DEC used, with different
labels, on a number of machines, including some of their PCs.  I
suspect this picture is of a off model keyboard (they were all
interchangeable, the host system.  These are the standard VT-220
labels (along with the scancodes):

http://www.netbsd.org/docs/Hardware/Machines/DEC/LK201_large_keycodes.jpg

And yes, that strip was at least semi-removable.

[toc] | [prev] | [next] | [standalone]

#125941

On 2018-01-28, shinobi <shinobi@f122.n1.z21.fsxnet> wrote:
> I wonder. What's the correct way to detect F1 in Linux Console?
>
> I guess getchar() returns character. And to my wonder it dispays
> different value using %d and %c. That's the best I came up with
> recently. Is there any better method?

%d prints its argument as a decimal value
%c prints its argument as a character

it should not be a suprise that %d and %c produce different output.

What character sequence do you expect to receive from typing F1 ?
Here, on an xterm, pressing F1 on the keyboard
produces the character sequence

  ESC [ 1 1 ~

or, in decimal

  27 91 49 49 126

five getchar() calls are needed to read that sequence.

[toc] | [prev] | [next] | [standalone]

#125984

On 28/1/2018 23:44, shinobi wrote:
> Hello All,
>
> I wonder. What's the correct way to detect F1 in Linux Console?
>
> I guess getchar() returns character. And to my wonder it dispays
> different value using %d and %c. That's the best I came up with
> recently. Is there any better method?

What operating system are you using to run this program?

-- 
   @~@   Remain silent! Drink, Blink, Stretch! Live long and prosper!!
  / v \  Simplicity is Beauty!
/( _ )\ May the Force and farces be with you!
   ^ ^   (x86_64 Ubuntu 9.10)  Linux 2.6.39.3
不借貸! 不詐騙! 不援交! 不打交! 不打劫! 不自殺! 請考慮綜援 (CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa

[toc] | [prev] | [next] | [standalone]

#126032

On Monday, January 29, 2018 at 3:15:20 AM UTC-6, shinobi wrote:
> Hello All,
> 
> I wonder. What's the correct way to detect F1 in Linux Console?
> 
> I guess getchar() returns character. And to my wonder it dispays
> different value using %d and %c. That's the best I came up with
> recently. Is there any better method?
> 
> ___ CUT HERE ---
> 
> //
> // BASIC HELPER FOR REWRITE TO 2.7.11                                          
> 
> //
> #include <stdio.h>
> 
> int main () {
> 
>   int c;
>   int e;
>   printf("Enter key\n");
>   for (;;) {
>     c=getchar();
>     if (c==27) {
>       e=getchar();
>       printf("Detected ESC %d %c\n",c,e);
>       if (e == '1') {
>         printf("F1\n");
>       }
>     } else {
>       printf("No ESC Detected %d %c\n",c);
>     }
>   }
>   return 0;
> }
> 
> 
> ___ CUT HERE ---


I have written up my discoveries in this area on SO:

https://stackoverflow.com/questions/34824604/how-do-you-read-the-arrow-keys

Although elsethread there are suggestions the F1-F5 might be trickier to 
get working than other special keys.

[toc] | [prev] | [next] | [standalone]

#126037

On 28/01/2018 15:44, shinobi wrote:
> Hello All,
> 
> I wonder. What's the correct way to detect F1 in Linux Console?
> 
> I guess getchar() returns character. And to my wonder it dispays
> different value using %d and %c. That's the best I came up with
> recently. Is there any better method?
> 
> ___ CUT HERE ---
> 
> //
> // BASIC HELPER FOR REWRITE TO 2.7.11
> 
> //
> #include <stdio.h>
> 
> int main () {
> 
>    int c;
>    int e;
>    printf("Enter key\n");
>    for (;;) {
>      c=getchar();
>      if (c==27) {
>        e=getchar();
>        printf("Detected ESC %d %c\n",c,e);
>        if (e == '1') {
>          printf("F1\n");
>        }
>      } else {
>        printf("No ESC Detected %d %c\n",c);
>      }
>    }
>    return 0;
> }

I believe getchar() waits for a whole line of input before delivering 
your keys, then it will give them all at once. So it needs to wait for 
Enter to be pressed.

For Linux, I've played around with programs like that below, which do 
key-at-a-time input.

Special keys (non-printable characters) are usually presented as 
multi-key escape sequences starting with ESC, so are not so easy to 
detect. (And the sequences can vary across OS versions, as well as which 
key combinations are returned. So some may support Ctrl-Page-Up, some 
might not.)

Note that F1 is typically intercepted to mean Help or whatever, but 
Ctrl-F1 or Shift-F1 might be detectable.

(Here's an example of what's involved in converting an escape sequence 
of multiple key presses, into a single key event; a function written in 
a scripting language: https://pastebin.com/raw/84FJCJtL)

--------------------------------------------------------

#include <termios.h>
#include <stdio.h>
#include <stddef.h>

static struct termios old, new;

/* Initialize new terminal i/o settings */
void initTermios(int echo)
{
   tcgetattr(0, &old); /* grab old terminal i/o settings */
   new = old; /* make new settings same as old settings */
   new.c_lflag &= ~ICANON; /* disable buffered i/o */
   new.c_lflag &= echo ? ECHO : ~ECHO; /* set echo mode */
   tcsetattr(0, TCSANOW, &new); /* use these new terminal i/o settings 
now */
}

/* Restore old terminal i/o settings */
void resetTermios(void)
{
   tcsetattr(0, TCSANOW, &old);
}

/* Read 1 character - echo defines echo mode */
char getch_(int echo)
{
   char ch;
   initTermios(echo);
   ch = getchar();
   resetTermios();
   return ch;
}

int main(void) {
int c;

puts("Press keys. Ctrl-C to quit.");

while(1) {
	c=getch_(0);

	if (c==27)
		printf("\nESC ");
	else if (c>=32 &&c<127)
		printf("%c",c);
	else if (c==10)
		printf("<10>\n");
	else
		printf("<%d>",c);
	fflush(stdout);
}

}

-- 
bartc

[toc] | [prev] | [next] | [standalone]

#126433

shinobi <shinobi@f122.n1.z21.fsxnet> wrote:
> I wonder. What's the correct way to detect F1 in Linux Console?

Various terminals produce different sequences for F-keys. The terminal 
I use (PuTTY) produces the following sequences under different
configurations:

 \33[[A
 \33OP
 \33[11~
 \33[M

(\33 is ESC)

Linux console produces \33[[A, but it is a bad practice to hardcode
terminal escape sequences. If you want your code to work on variety of
terminals, you need to use terminfo library.

Here's an example of how to get escape sequence for F1 using terminfo:

 #include <term.h>
 #include <stdio.h>
 ...
 setupterm(NULL, fileno(stdio), NULL);
 char* kf1 = tigetstr("kf1");

"kf1" is a terminal capability. There are many different ones, but this
particular one is responsible for input of the F1 key.
Manpage terminfo(5) has a full list of capabilities.

A very important thing to note is that tigetstr returns -1 on error,
and not NULL as one might expect.

To get proper input you need to enable raw mode using termios, as been
shown by another poster in this thread.

[toc] | [prev] | [next] | [standalone]

#126442

 Eg> Linux console produces \33[[A, but it is a bad practice to hardcode
 Eg> terminal escape sequences. If you want your code to work on variety of
 Eg> terminals, you need to use terminfo library.
 Eg> 
 Eg> Here's an example of how to get escape sequence for F1 using terminfo:

Thanks so much. This is really good to know. That trouble detecting F1 was
is quite a complex one. Aside from that it's different in almost every
single terminal. I mean I would like to handle possible as much as possible
of it (PuTTY, xterm, gnome-terminal). Well xterm is possible obsolete. But
there could be some users.

[toc] | [prev] | [next] | [standalone]

#126458

On Thu, 2018-02-08, shinobi wrote:
...
> Thanks so much. This is really good to know. That trouble detecting F1 was
> is quite a complex one. Aside from that it's different in almost every
> single terminal.

Unless you let terminfo deal with the differences, if I understand correctly.

> I mean I would like to handle possible as much as possible
> of it (PuTTY, xterm, gnome-terminal). Well xterm is possible obsolete. But
> there could be some users.

Here's one -- I've been a happy xterm user for about 25 years.

And I've yet to see a piece of software which broke in xterm, so if
yours did that would look odd.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#126459

Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
> On Thu, 2018-02-08, shinobi wrote:
> ...
>> Thanks so much. This is really good to know. That trouble detecting F1 was
>> is quite a complex one. Aside from that it's different in almost every
>> single terminal.
>
> Unless you let terminfo deal with the differences, if I understand correctly.
>
>> I mean I would like to handle possible as much as possible
>> of it (PuTTY, xterm, gnome-terminal). Well xterm is possible obsolete. But
>> there could be some users.
>
> Here's one -- I've been a happy xterm user for about 25 years.
>
> And I've yet to see a piece of software which broke in xterm, so if
> yours did that would look odd.

I'm also a regular use of xterm.

The whole point of terminfo is that you don't need specific support for
different kinds of terminal emulators, just the terminfo database and a
correct setting for the $TERM environment variable.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#126463

Keith Thompson <kst-u@mib.org> writes:
>Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
>> On Thu, 2018-02-08, shinobi wrote:
>> ...
>>> Thanks so much. This is really good to know. That trouble detecting F1 was
>>> is quite a complex one. Aside from that it's different in almost every
>>> single terminal.
>>
>> Unless you let terminfo deal with the differences, if I understand correctly.
>>
>>> I mean I would like to handle possible as much as possible
>>> of it (PuTTY, xterm, gnome-terminal). Well xterm is possible obsolete. But
>>> there could be some users.
>>
>> Here's one -- I've been a happy xterm user for about 25 years.
>>
>> And I've yet to see a piece of software which broke in xterm, so if
>> yours did that would look odd.
>
>I'm also a regular use of xterm.
>

Make that three.   xterm + twm.

[toc] | [prev] | [next] | [standalone]

#126452

Egor <egor@ruby.local> writes:
> shinobi <shinobi@f122.n1.z21.fsxnet> wrote:
>> I wonder. What's the correct way to detect F1 in Linux Console?
>
> Various terminals produce different sequences for F-keys. The terminal 
> I use (PuTTY) produces the following sequences under different
> configurations:
>
>  \33[[A
>  \33OP
>  \33[11~
>  \33[M
>
> (\33 is ESC)
>
> Linux console produces \33[[A, but it is a bad practice to hardcode
> terminal escape sequences. If you want your code to work on variety of
> terminals, you need to use terminfo library.
>
> Here's an example of how to get escape sequence for F1 using terminfo:
>
>  #include <term.h>
>  #include <stdio.h>
>  ...
>  setupterm(NULL, fileno(stdio), NULL);
>  char* kf1 = tigetstr("kf1");

I think you mean
    setupterm(NULL, fileno(stdin), NULL);
And I'd use `const char *const kf1 = ...` (you don't want to modify
either the pointer or what it points to).

That gives you the appropriate string.  Is there support for recognizing
that string on input?  (In particular, you want to be able to
distinguish between an escape character that's part of a sequence and
one that's the result of the user hitting the escape key; that requires
timing.)

> "kf1" is a terminal capability. There are many different ones, but this
> particular one is responsible for input of the F1 key.
> Manpage terminfo(5) has a full list of capabilities.
>
> A very important thing to note is that tigetstr returns -1 on error,
> and not NULL as one might expect.

It returns (char*)-1 if capname is not a string capability, or 0 (NULL)
if it is canceled or absent from the terminal description.

> To get proper input you need to enable raw mode using termios, as been
> shown by another poster in this thread.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#126477

Keith Thompson <kst-u@mib.org> wrote:
> I think you mean
>     setupterm(NULL, fileno(stdin), NULL);
Actually it should be stdout. 

> And I'd use `const char *const kf1 = ...` (you don't want to modify
> either the pointer or what it points to).
I'd use `const char*`. There's no need to make pointer itself const, as
it is returned by value from the function.

I used `char*` in my original post for simplicity, and also because
that's what the function returns.

> That gives you the appropriate string.  Is there support for recognizing
> that string on input?  (In particular, you want to be able to
> distinguish between an escape character that's part of a sequence and
> one that's the result of the user hitting the escape key; that requires
> timing.)
terminfo doesn't have that. curses, however does. You need to turn on
keypad() mode (documented in curs_inopts(3X) for ncurses,) and then you
can use wgetch() (manpage curs_getch(3X)) to get input, which is either
normal characters, or KEY_ constants, e.g. KEY_F1.
Full list of those constants is also in curs_getch(3X).

> It returns (char*)-1 if capname is not a string capability, or 0 (NULL)
> if it is canceled or absent from the terminal description.
You are correct.
On my system it also returns -1 if setupterm isn't called beforehand.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c

csiph-web