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 2 of 2 — ← Prev page 1 [2]

#126484

On Fri, 2018-02-09, Egor wrote:
> 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.

It's not /needed/, but it increases readability slightly, by telling
the reader that 'kf1' is initialized once and then never modified.

That's the reason C has that construct anyway. Not everyone feels it's
important to use it, but I find it very helpful.

/Jorgen

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

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

#126490

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

Thanks for the correction.

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

I prefer to define things as "const" unless they specifically need to be
modified.  I'm not going to change the value of the pointer kf1, so I'd
document that fact.  I understand that some people consider that to be
clutter.

[...]

-- 
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]

#126467

On Thursday, February 8, 2018 at 6:25:52 AM UTC-6, Egor wrote:
> 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.

I posted a link to this earlier in the thread, but in the interest of
making a nice, relatively complete, savable message, I append a copy here.
This is the "timing trick" needed to distinguish bare escape from an
escape sequence.

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

Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!usenet.ins.cwru.edu!ncoast!allbery
From: all...@NCoast.ORG (Brandon S. Allbery KB8JRR)
Newsgroups: comp.unix.programmer
Subject: Re: How do you read the arrow keys?
Message-ID: <1991Jan1.035656.27394@NCoast.ORG>
Date: 1 Jan 91 03:56:56 GMT
References: <3080@dali> <1990Dec28.195518.26577@ivy.uucp> <4927:Dec2920:17:4790@kramden.acf.nyu.edu>
Reply-To: all...@ncoast.ORG (Brandon S. Allbery KB8JRR)
Followup-To: comp.unix.programmer
Organization: North Coast Computer Resources (ncoast)
Lines: 68

As quoted from <4927:Dec29...@kramden.acf.nyu.edu> by brn...@kramden.acf.nyu.edu (Dan Bernstein):
+---------------
| It's really the terminal's fault, not the programmer's fault. Codes
| coming from the terminal should be uniquely decodable as untimed byte
| streams. In the best situation, no code is a prefix of another.
+---------------
</pre>

>AT&T has a very nice solution to this problem; unfortunately, it depends on
AT&T termio (or POSIX termios), so implementing it under a BSD variant is
difficult.  Although one could conceivably come up with a hack using select,
it would not be quite as reliable.  At least one commercial product I know of
uses this method (termio, not select), but it was documented in at least one
programmer's manual I've read as well.

>Termio(s) doesn't really have a "raw" mode; it has a "packet" mode.  The most
common use is with a packet size of 1 and a timeout of 1 (which is treated as
"no timeout").  However, one can set it for other combinations.  The most
useful in this case is to set the packet size to the size of the longest
function key sequence and the timeout to the longest time needed for it to be
sent *as a function key*.  The assumption (usually correct) being that if the
user types it, it will take longer.

>Once this is done, you attempt to read() that longest number of characters at
the same time.  read() returns the actual number of characters read before the
timeout, which starts after the first character of the packet is received.
Thus, single keystrokes like ESC are read as such, but given something like a
VT100, PF1 would return 3 characters --- ESC O P (ESC [ P if, like me, you
detest the applications cursor and keypad modes).

	struct termio tbuf; /* POSIX: struct termios */
	int maxlen = 3, len;
	char buf[3];

	ioctl(0, TCGETA, &tbuf); /* POSIX: tcgetattr(0, &tbuf); */
	tbuf.c_lflags &= ~(ICANON|ECHO);
	tbuf.c_cc[VMIN] = maxlen;
	tbuf.c_cc[VTIME] = 2; /* 2/10 sec, good at 9600 baud and up */
	ioctl(0, TCSETAW, &tbuf); /* POSIX: tcsetattr(0, X???WAIT, &tbuf); */
				  /* I forget the exact flag */

	len = read(0, buf, maxlen);
	if (len == 1)
	{
	    /* single character */
	}
	else
	{
	    /* function key sequence */
	}

>Getting VTIME correct for various baud rates can be tricky; but it's also a
one-time task.  And I've used this trick in my own programs; it works well.
I believe the function key support in SVR3 curses can be coerced into doing
this if halfdelay() is enabled and works in your port.

>For BSD, the most I can say is check to see if your version (e.g. Ultrix 3.x
or SunOS 4.x, etc.) supports a termio interface, or wait for BSD4.4 which
supposedly will have POSIX termios.  (Since BSD4.4 is either out or will be
very soon --- I've been out of touch with it --- no doubt someone will chime in
and tell us.)  Be warned that earlier Ultrix versions claimed to have termio
support, but it didn't work.

-- 
names of people

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web