Command line arguments

[BartC]

I suspect that you are talking about your won private software, so it's
no matter to me, but I don't want either the problem you describe or
the solution you propose.

No, this is a widespread problem; I've mentioned that I see it frequently
(when a display can't keep up with keyboard entry). There's even a
RosettaCode page devoted to this task**! I'm surprised you haven't come
across it. (And if you have or do, I'd be interested in what solution you
use.)

(** 'Flush the keyboard buffer'. Some languages make it very easy. The C
entry makes use of tcflush(), which I'll look at, maybe.. Interestingly it
does the same manipulations of attributes for it's get-char function as in
my link.)

I would have thought the first line of manual page would have cleared
that up, but maybe you mean Xterm in some other sense.

man lxterminal? It just says it's a terminal emulator. A 'lightweight' one.

And if you use the keypad function, it will read and return key codes.
The ncurses way to do kbhit() is to turn off blocking reads (the nodelay
function) but it's not exactly the same because it works by trying to
get a character rather than telling of there is one to get.

I've done all that (eg. my code to flush the keyboard is below). But there
were some small issues with ncurses (the proliferation of versions, the need
to install it (at least, for the headers), which ran into apt-get problems,
various things that didn't work (such as its keyboard flush routine, hence
the need use the one below), different key codes between pdcurses and
ncurses...). I just thought it simpler if I could do most of what I wanted
via stdin and stdout. But I haven't ruled it out completely because the
alternative doesn't work yet!

void $con_kbdflush(void){
nodelay(stdscr,1);
while (wgetch(stdscr)!=ERR) {
}
nodelay(stdscr,0);
}

 

[Alan Curry]

Yes. For normal typing of text, it's unlikely the display will not keep up
with the rate of typing. But imagine that someone holds down the PageDown
key on a long document: the key repeats at 20cps, but the display might only
update at 10 screens per second. When the user releases the key, there might
be dozens of keystrokes pending, but the screen will keep on scrolling down
well past the desired position.

The easy way to solve that is to not lean on the keyboard. Use short
controlled bursts.

(Actually I spent quite some time the other day trying to establish whether
Lxterminal, which I use, is the same thing as Xterm; I'm still not sure!)

xterm is to terminal emulators as C is to languages: old but not dead;
updated occasionally but never radically redesigned; imitated to some extent
by all those who intend to replace it.

 

[James Kuyper]

No, this is a widespread problem; I've mentioned that I see it frequently
(when a display can't keep up with keyboard entry). There's even a
RosettaCode page devoted to this task**! I'm surprised you haven't come
across it. (And if you have or do, I'd be interested in what solution you
use.)

The most common one, and one I'm quite used to, and in fact, frequently
rely upon - is that the keystrokes are stored somewhere and used
normally when the display finally catches up with them. When I've had to
work over particularly slow connections, I've often typed one or two
paragraphs ahead of the display. I've even occasionally realized that
I'd made an error, backed up to the error, and corrected it, before the
error was ever displayed. I know in my head where the cursor should be
when the program finally catches up with my typing, even though it's
currently being displayed in an entirely different location. Dropping
keystrokes would force me to synchronize my typing speed with the speed
of the connection, which would be rather annoying, given how variable
that can be.

....

man lxterminal? It just says it's a terminal emulator. A 'lightweight' one.

Now, compare with 'man exterm". It shouldn't take you too long to
identify inconsistencies. I don't know what they are, lxterminal is not
installed on my system - but I'll be surprised if there aren't any
differences - otherwise, what's "lightweight" about it?

Different behavior is not sufficient to rule out the possibility that
lxterminal and xterm are really the same program with different names -
but if changing the name of the program does change it's behavior (which
is not uncommon in the Unix world), then they really are different
programs, for most purposes.

I've seen systems where the C, C++, and Fortran compilers were all the
same program, with different names, and correspondingly different
behavior when invoked with the different names.

 

[Ben Bacarisse]

No, this is a widespread problem; I've mentioned that I see it
frequently (when a display can't keep up with keyboard entry).

Another misunderstanding. I don't mean the problem is only in your
software, I means that because it is your private software how you deal
with the problem is not a matter for me -- I'll never be using it.

There's
even a RosettaCode page devoted to this task**! I'm surprised you
haven't come across it. (And if you have or do, I'd be interested in
what solution you use.)

I've never had to solve it. In general, I don't like software deciding
whether the user really meant what was typed. I'd rather the software
had a clever way to deal with it asynchronously. Take your PageDown
example. The software can process PageDown very quickly indeed
(top_line += page_length so what you need is a screen re-draw
mechanism that can be restared part-way through. That way, the net
effect will simply to be display the last page after a bit of starting
to redraw the top line a few time.

man lxterminal? It just says it's a terminal emulator. A 'lightweight'
one.

My mistake. I though you meant lxterm. I have no idea what lxterminal
is and, as you say, the man page just describes it in general terms.

I've done all that (eg. my code to flush the keyboard is below). But
there were some small issues with ncurses (the proliferation of
versions, the need to install it (at least, for the headers), which
ran into apt-get problems, various things that didn't work (such as
its keyboard flush routine,

Consider filing a bug reports. That's how software like ncurses gets
better.

<snip>

 

[James Kuyper]

My mistake. I though you meant lxterm. I have no idea what lxterminal
is and, as you say, the man page just describes it in general terms.

Google led me to <http://wiki.lxde.org/en/LXTerminal>, which identifies
lxterminal as part of LXDE, "Lightweight X-11 Desktop Environment". It's
plausible that in such an environment, 'xterm' might be set up as a link
to lxterminal, which would make Bart's question a reasonable one to ask
- and one he should be able to answer by looking at 'man xterm'.

 

[BartC]

I've never had to solve it. In general, I don't like software deciding
whether the user really meant what was typed. I'd rather the software
had a clever way to deal with it asynchronously. Take your PageDown
example. The software can process PageDown very quickly indeed
(top_line += page_length so what you need is a screen re-draw
mechanism that can be restared part-way through. That way, the net
effect will simply to be display the last page after a bit of starting
to redraw the top line a few time.

That would require even more sophisticated keyboard handling! As well as
complications in the application: being able to peek at input events during
a display handler or allow interruptions. (And in my case the display code
will be in interpreted code which likes things simple.)

This is all very well for a full-blown graphical application; we're talking
about a simple, crude, console application, but which might well be running
inside a slow-to-update graphic window.

In any case, although I've seen the technique you describe in action, I'm
not sure it's always effective (perhaps you're looking for something which
is not near the top of the display). Perhaps if the display is really that
slow, then it could be an option.

(I've just tested the editor I use on my little linux computer. It only runs
in graphics mode. If I hold down page-down until I get to line 500, and then
release the key, it keeps going until it gets to line 1800! A simple
'flush-keyboard-buffer' op would have solved most such problems.)

 

[BartC]

news:0.fef62be05e9ad938206b.20130116042800GMT.8738y1bvlb.fsf@bsb.me.uk...

[About the need to have a function such as kbhit()]

I'd rather the software

That would require even more sophisticated keyboard handling!

BTW here's a little game (if you're easily amused) that I created yesterday:

#include <stdio.h>

int main(void) {
int i=0;

while (1) {
printf("%d\n",++i);
if (kbhit()) break;
}

printf("You chose %d\n",i);
}

The game is to choose a number, start the program, and aim to stop it as
close as possible to your number. A variation is to stop it at as low a
number as possible (on my hardware - console running in a window - I managed
about 100).

However the point is, can such a program be written without using a function
like kbhit()? And as simply?

 

[Ben Bacarisse]

BTW here's a little game (if you're easily amused) that I created yesterday:

#include <stdio.h>

int main(void) {
int i=0;

while (1) {
printf("%d\n",++i);
if (kbhit()) break;
}

Yeah! I can be topical:

do printf("%d\n", ++i);
while (!kbhit());

printf("You chose %d\n",i);
}

The game is to choose a number, start the program, and aim to stop it as
close as possible to your number. A variation is to stop it at as low a
number as possible (on my hardware - console running in a window - I managed
about 100).

However the point is, can such a program be written without using a function
like kbhit()? And as simply?

That, to me, is an almost meaningless question. Almost any program can
be simpler if we assume the existence of a "more useful" function. I
think a better question asks what the pros and cons are of some
particular API for writing programs of some type or other.

 

[Ken Brody]

On 01/10/2013 03:49 PM, Lew Pitcher wrote: [...] [...]
Lew beat me to it. From a terminal (in Linux), type 'echo *', and it echos
a list of the files in that directory. Enclose in quotes (as suggested
elsethread), and type 'echo "*"', and get a single asterix. If, as Greg
suggested, I type 'set -o noglog', then type 'echo *', I get the single
asterix. The globbing is being done by the OS, before your program gets
run. Bart, I don't know if noglob works in all shells, but that sounds like
your best bet for the Linux side, as you say using enclosing quotes isn't
practical.

Just note that that will affect *everything* for that shell. What happens
when the user complains that he can no longer do things like "ls -l *.txt"?

 

[Ken Brody]

No longer a C question, per se, but bash's behavior (at least on
my slackware 14.0 box) is a bit more complicated than suggested above.
echo * echoes a list of all files as stated
echo t*.c echoes test.c because that's the only such file in my /home
echo a*.c echoes a*.c apparently because there are no a*.c files at all
So if there are no matches, it reverts to echoing the string rather
than emitting an error like ls would. Is there a more general rule
behind that behavior? I ask because I also have a C program,
in this case evaluating command-line expressions which can be,
say, a*b, and I've never (so far) had any problem. Is that just
lucky because there never happened to be any filename matches?

"ls" gives an error, because it gets passed the argument "a*.c", and there
is no such file by that name. Why should "echo" give an error when passed
the argument "a*.c"?

The shell is being consistent -- if no file matches the wildcard, then that
raw wildcard is passed. What the program chooses to do with that argument
is up to that program.