how to quit

  • Thread starter mynameisthomasanderson
  • Start date
U

user923005

">
He said he would the last time I pointed out an error.
He didn't correct it.


hmm - no. It's incorrect, and (even given the old information that he
used), was never correct since the FAQ was written.

From:
http://www.delorie.com/gnu/docs/termcap/termcap_37.html
We have this:
The Termcap Library

[ < ] [ > ] [ << ] [ Up ] [ >> ] [Top] [Contents]
[Index] [ ? ]
3.14 Keypad and Function Keys

Many terminals have arrow and function keys that transmit specific
character sequences to the computer. Since the precise sequences used
depend on the terminal, termcap defines capabilities used to say what
the sequences are. Unlike most termcap string-valued capabilities,
these are not strings of commands to be sent to the terminal, rather
strings that are received from the terminal.

Note the sentence: "Many terminals have arrow and function keys that
transmit specific character sequences to the computer." indicating
that {at least potentially} some do not.

The GNU entry reads the same:
http://www.gnu.org/software/termutils/manual/termcap-1.3/html_chapter/termcap_4.html#SEC37

Same from University of Utah:
http://www.cs.utah.edu/dept/old/texinfo/termcap/termcap.html#SEC35

The BSD docummentation:
http://www.freebsd.org/cgi/man.cgi?query=termcap&sektion=5
says:
"Keypad
If the terminal has a keypad that transmits codes when the keys
are
pressed, this information can be given. Note that it is not
possible to
handle terminals where the keypad only works in local mode (this
applies,
for example, to the unshifted Hewlett-Packard 2621 keys). If the
keypad
can be set to transmit or not transmit, give these codes as ks
and ke.
Otherwise the keypad is assumed to always transmit. The codes
sent by
the left-arrow, right-arrow, up-arrow, down-arrow, and home keys
can be
given as kl, kr, ku, kd, and kh, respectively. If there are
function
keys such as f0, f1, ..., f9, the codes they send can be given as
k0, k1,
..., k9. If these keys have labels other than the default f0
through f9,
the labels can be given as l0, l1, ..., l9."

I think we can infer that all credible sources of documentation agree
with Steve's interpretation.

IMO-YMMV.
 
T

Thomas Dickey

user923005 said:
Many terminals have arrow and function keys that transmit specific

terminals are a different type of entity than termcap entries.

(If you have this much time to waste,
you should use some of it to learn the terminology).
 
U

user923005

terminals are a different type of entity than termcap entries.

(If you have this much time to waste,
you should use some of it to learn the terminology).

If the terminals do not have function keys, then termcap can hardly
map them, n'est ce pas?
 
T

Thomas Dickey

If the terminals do not have function keys, then termcap can hardly
map them, n'est ce pas?

hmm. In your first response, you did the equivalent of stating that
gray is a shade of black.

Then you followed up with two secondary references (claiming they were
three primary ones ;-), confusing the terminal's capabilities with the
programmatic interface for controlling it.

Now you're moving on to confuse a program (which is the point of the FAQ's
comment - otherwise it's only saying something completely absurd) with its
data.
 
K

Kenneth Brody

Thomas said:
You didn't have to (the time would have been better spent by checking).

BSD 4.2 (I see the file's date July 1, 1983 - more than 20 years)
distributed a termcap with k1, k2, etc., in its entries. A quick check
shows 35 entries with _that_ much use of function keys.

That convention is still in use. You may not have used or even been
aware of it (there were manpages...), but other people used it, and
assumed it.

I wasn't using BSD. The system in question was Xenix, and its
termcap did not have k1, k2, and so on. As I recall, it also did
not have any entries defined for "page up", "page down", and so on.

Just because BSD's termcap defined them, doesn't mean that all
implementations used them.

Of course, the manuals are long gone.

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>
 
K

Kenneth Brody

Thomas said:
I'm afraid not:
discussing inaccuracies in a newsgroup's faq is always on topic.

True. I forgot that the "real" discussion here was whether or not
the FAQ had an error saying "some termcap" implementations, implying
that not all, had this in it.

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>
 
K

Kenneth Brody

Thomas said:
hmm. In your first response, you did the equivalent of stating that
gray is a shade of black.

Hmm... I have seen documentation on some computers which have a
video attribute of "bright black", to correspond to the others
along the line of "bright red" or "bright yellow". (Others call
the same value "dark gray".)

:)

[...]

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>
 
U

user923005

hmm. In your first response, you did the equivalent of stating that
gray is a shade of black.

That's because grey is a shade of black. Or, perhaps, black is a
shade of grey. The only thing in the universe that is truly black is
a black hole (and even those emit something, according to prevailing
theory).
Then you followed up with two secondary references (claiming they were
three primary ones ;-), confusing the terminal's capabilities with the
programmatic interface for controlling it.

I understand what termcap does.
Now you're moving on to confuse a program (which is the point of the FAQ's
comment - otherwise it's only saying something completely absurd) with its
data.

The point is that termcap may or may not re-map function keys.

The FAQ was saying that termcap may or may not remap your function
keys. It is possible that to make it work correctly, you will simply
need to add some entries into the termcap database, but it is also
possible that the terminals do not support function keys, in which
case the entries will be useless.

The upshot is that you may or may not be able to define function keys
with termcap (which is pretty much obsolete anyway).

Here is an entry from a vi release notes file:

If the lhs of a macro is "#0" through "#9", this maps the particular
function key instead of the 2 char # sequence, if the terminal has
function keys. This only works if termcap has function key entries
for the particular terminal. For terminals without function keys,
the sequence #x means function key x, as typed. As a special case,
on terminals without function keys, the #x sequence need not be
typed within one second. The character # can be changed by using
a macro in the usual way:
map ^V^I #
to use tab, for example. (This won't affect the map command, which
still uses #, but just the invocation from visual mode.)
The undo command will undo an entire macro call as a unit.

Perhaps the FAQ entry should say something like:
"If you are using termcap, and your terminal supports function keys,
then you might be able to use termcap to collect function key
information."
How would you word it?
 
T

Thomas Dickey

Kenneth Brody said:
I wasn't using BSD. The system in question was Xenix, and its
termcap did not have k1, k2, and so on. As I recall, it also did
not have any entries defined for "page up", "page down", and so on.
Just because BSD's termcap defined them, doesn't mean that all
implementations used them.
Of course, the manuals are long gone.

It's easier to discuss things when they're documented.

The only references I can see offhand to Xenix (which I also used around
the same time - including porting my termcap applications) remind one
that some function-key combinations were intercepted by the keyboard
driver to switch virtual screens. But the same references state that
k0-k9 were available for application use (and vendor's suggested
termcaps, e.g., from Wyse) agree with that.

Xenix (like a few others which linger on - Ingres for example) had
extensions to termcap to provide support for line-drawing characters
which do not agree with the usual termcap convention.
 
T

Thomas Dickey

user923005 said:
Perhaps the FAQ entry should say something like:
"If you are using termcap, and your terminal supports function keys,
then you might be able to use termcap to collect function key
information."
How would you word it?

By making it clearer how the pieces are related.

The paragraph quoted does not make it apparent that these are programmatic
interfaces, with varying capabilities (except for "some versions of curses")
and that they rely upon knowing the terminal's capabilities (or lack):

A: Terminfo, some versions of termcap, and some versions of curses
have support for these non-ASCII keys. Typically, a special key
sends a multicharacter sequence (usually beginning with ESC,
'\033'); parsing these can be tricky. (curses will do the
parsing for you, if you call keypad() first.)

It's the first sentence which is the problem. Start by providing a clue
to the answer:

This addresses only the most common case, where the keys send
characters to your application, running in a terminal.

Arrow keys and function keys (special keys) are not ASCII
values. Typically, a special key sends a multicharacter
sequence (usually beginning with ESC, '\033'). Parsing these
can be tricky.

The multicharacter sequences sent may differ from one terminal
type to another. Different terminals have different numbers of
special keys - even none in rare instances. There are system
dependent programmatic interfaces which provide the ability to
retrieve this information for different terminal types. These
interfaces include the low-level terminfo and termcap (named for
their respective databases) as well as curses (alluding to the
higher level optimization of cursor movement).

Most implementations of curses are built on either terminfo or
termcap, and as part of their interface include these
lower-level interfaces. Most versions of curses also provide
functions which can parse the multicharacter sequences to return
a code denoting which special key was sent. You must call the
keypad() function to use this feature, as well as use the curses
getch() function for reading the keys from the terminal.

btw - I chose to ignore the reference to MS-DOS, since (a) it's
tecnically obsolete, and (b) more than a mention of the more commonly
used interfaces with Windows would require greater detail than is in the
FAQ for any entry. Note however, that far more people are looking for
analogous information about Windows than MS-DOS (the FAQ is long out
of date as well).
 
O

osmium

mynameisthomasanderson said:
I'm pretty new to programming and i need a bit help from you, the
experienced programmers.
Well the thing is I'm making a small program on C. I want that
whenever user presses the key combination of ctrl+F3, he exits from
the program. how could I code this thing?

I'm afraid I can't contribute anything about termcap, copyright law, the
quality of the FAQ, or what constitutes on topicness.

But if the OP is still around, perhaps here is something he could adapt.
This uses ^c as an attention interrupt. Note that the process in control
continues, and that the user response waits for an Enter key stroke. No
error handling for scanf is provided, I expect it would be removed in the
adaptation the OP makes, I used it for testing. This is only intended to
work once per program execution, which as I understand it, is sufficient.

#include <stdio.h>
#include <signal.h>

void piddle();
int stop = 0;

// f is the user supplied interrupt hander for the SIGINT interrupt
// modify per your needs
void f(int n/* argument not used */)
{
printf("f called\n");
printf("Quit? y n\n");
char ch;
scanf("%c", &ch);
printf("\n%c\n", ch);
if(ch == 'y')
exit(0); // success
else
{
printf("Still alive\n");
fflush(NULL);
stop = 1;
}
}
//--------------
void set_up_interrupt()
{
// SIGINT (interactive attention) produced by ^c
signal(SIGINT, f);
}
//---------------
// prints a message once a second
void piddle()
{
time_t t = time(NULL);
while(!stop)
if(t != time(NULL) )
{
t = time(NULL);
printf("Tick\n");
}
}
//==============
int main()
{
// function used for clarity
set_up_interrupt();
piddle();


// next only to retain sanity while debugging with MingW
while(1)
getchar();
}
 
T

Thomas Dickey

osmium said:
But if the OP is still around, perhaps here is something he could adapt.
This uses ^c as an attention interrupt. Note that the process in control
continues, and that the user response waits for an Enter key stroke. No
error handling for scanf is provided, I expect it would be removed in the
adaptation the OP makes, I used it for testing. This is only intended to
work once per program execution, which as I understand it, is sufficient.

hmm - if this were almost any other newsgroup, e.g., comp.unix.programmer,
I'd point out that the signal handler may dump core. But this is comp.lang.c
which is unconstrained by that sort of consideration.

OP may find it useful though.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top