Is there a library function for placing cursor position in the cosole?

J

JeffS

Honest, I scoured the comp.lang.c.faq for this but found nothing. :)

Is there a library function for placing the cursor position in the
console? Or is it something that can only be done with a platform API
call?

I was able to do this in Windows with a Windows.h function, but I want
to also do it on Linux/Unix as well.

I won't ask for a Linux API call that positions the cursor, as that is
beyond the scope of the comp.lang.c group. But if someone knew it off
the top of their head, I won't stop you from writing it in a post! ;)
;)

Anyway, it would be really ideal if there were a standard C library
function that postitions the cursor in the console. This way, I can
keep my code more portable.
 
M

Mike Wahler

JeffS said:
Honest, I scoured the comp.lang.c.faq for this but found nothing. :)

That's because standard C does not support direct device
access. All i/o is abstracted as 'streams of characters'.
C does not require the existence of a video display at all.
Is there a library function for placing the cursor position in the
console?

There are many, but all all platform-dependent. Also many implementations
provide library 'extensions' for this sort of thing, when applicable.
You might want to check your documentation for that.
Or is it something that can only be done with a platform API
call?

Essentially yes. But there are some third-party 'portable'
libraries available too.
I was able to do this in Windows with a Windows.h function, but I want
to also do it on Linux/Unix as well.

Sounds like you want some (relatively) 'portable' method. 'curses'
is one possiblity.

I won't ask for a Linux API call that positions the cursor, as that is
beyond the scope of the comp.lang.c group. But if someone knew it off
the top of their head, I won't stop you from writing it in a post! ;)
;)

Anyway, it would be really ideal if there were a standard C library
function that postitions the cursor in the console.

There is not.
This way, I can
keep my code more portable.

Well, I hope you find my comments helpful anyway.

-Mike
 
G

Gordon Burditt

Is there a library function for placing the cursor position in the

Which console? What cursor? An ASR33 teletype doesn't have a
cursor. (I suspect C was originally developed on this kind of
terminal, although maybe something older than the ASR33.)

Remember also that many operating systems provide ways to direct
stdin and stdout to something else, like files or pipes.
Or is it something that can only be done with a platform API
call?

Some hardware doesn't HAVE a cursor (printing terminals, for
example). Some hardware doesn't HAVE a coin return slot, either.
I was able to do this in Windows with a Windows.h function, but I want
to also do it on Linux/Unix as well.

If you know what the type of CRT terminal is (or what it emulates)
such as VT100, there is a specific character sequence you can send
it to position the cursor (generally, independent of the OS, but
dependent on the character set.). But you don't know that. It may
not even be the same terminal type on two different terminals
connected to the same Linux machine. And thanks to dialup ports
and network connections, there may not be a way to figure this out
by looking at the hardware of the machine itself.
I won't ask for a Linux API call that positions the cursor, as that is
beyond the scope of the comp.lang.c group. But if someone knew it off
the top of their head, I won't stop you from writing it in a post! ;)
;)

Anyway, it would be really ideal if there were a standard C library
function that postitions the cursor in the console. This way, I can
keep my code more portable.

Your code is not very portable if it expects to be connected to
a console.

Gordon L. Burditt
 
E

E. Robert Tisdale

JeffS said:
Honest, I scoured the comp.lang.c.faq for this but found nothing. :)

Is there a library function for placing the cursor position in the
console? Or is it something that can only be done with a platform API
call?

I was able to do this in Windows with a Windows.h function, but I want
to also do it on Linux/Unix as well.

I won't ask for a Linux API call that positions the cursor, as that is
beyond the scope of the comp.lang.c group. But if someone knew it off
the top of their head, I won't stop you from writing it in a post! ;)
;)

Anyway, it would be really ideal if there were a standard C library
function that postitions the cursor in the console.
This way, I can keep my code more portable.
> man ncurses

ncurses(3X) ncurses(3X)

NAME
ncurses - CRT screen handling and optimization package

SYNOPSIS
#include <curses.h>

DESCRIPTION
The ncurses library routines give the user a
terminal-independent method of updating character screens
with reasonable optimization.
This implementation is ‘‘new curses’’ (ncurses) and is
the approved replacement for 4.4BSD classic curses,
which has been discontinued.
 
D

dandelion

I won't ask for a Linux API call that positions the cursor, as that is
beyond the scope of the comp.lang.c group.

<OT>
Good. Linux does not have one.
</OT>
 
R

Richard Bos

JeffS said:
Honest, I scoured the comp.lang.c.faq for this but found nothing. :)

Is there a library function for placing the cursor position in the
console?

You can't have scoured very hard. Next time, use a steel brush.
Anyway, it would be really ideal if there were a standard C library
function that postitions the cursor in the console.

There are very good reasons why there isn't such a function in the
Standard, one of which is that it would be hard to come up with an
interface which is both useful and portably implementable. Consider, for
example, that you have no way (and there may _be_ no way) to tell
whether stdout is connected to a local console, or to a line printer on
the other end of a long serial connection.

Richard
 
C

Chris Croughton

Honest, I scoured the comp.lang.c.faq for this but found nothing. :)

Is there a library function for placing the cursor position in the
console? Or is it something that can only be done with a platform API
call?

The concepts 'console' and 'cursor' are inherently platform-specific
(try positioning a cursor on a Teletype(R) Model 33!). It is therefore
OT for c.l.c (but see below for suggestions).
I was able to do this in Windows with a Windows.h function, but I want
to also do it on Linux/Unix as well.

If you are dealing with a text-mode console, look for curses. It is
available on all Unices I know and under Cygwin for MSWin32 systems.
I won't ask for a Linux API call that positions the cursor, as that is
beyond the scope of the comp.lang.c group. But if someone knew it off
the top of their head, I won't stop you from writing it in a post! ;)
;)

<ESC>[a;bH

a and b are the row and column number in decimal ASCII (1,1 is the top
LH corner). That's the VT100/ANSI cursor control sequence, which works
with xterms, but of course is not guaranteed to work on anything else.
Anyway, it would be really ideal if there were a standard C library
function that postitions the cursor in the console. This way, I can
keep my code more portable.

The curses library (implemented by ncurses and others) has its own
standard from XSI.

HTH

Chris C
 
L

Lawrence Kirby

The concepts 'console' and 'cursor' are inherently platform-specific

To a degree but libraries like Curses have shown you have create a pretty
portable programming model for them.
(try positioning a cursor on a Teletype(R) Model 33!).

The fact that you can find environments that don't support this doesn't
invalidate the creation of a portable API for those that do. Such an
interface could simply say "Sorry can't do that" where that is
appropriate. Some programs (well any program) just can't run usefully on
platforms with inadequate functionality, that's true of standard C as it
is.
It is therefore OT for c.l.c (but see below for suggestions).

It is OT because the C language designers chose not to provide such
support in standard C, not because they couldn't have done. Curses exists
despite things like the Model 33.

Lawrence
 
C

Chris Croughton

To a degree but libraries like Curses have shown you have create a pretty
portable programming model for them.

For a limited set of terminals (I don't know of any versions for GUI,
for example, and there are a number of functions of some terminals which
can't be manipulated using curses). It also has to know about what the
terminal type is, if the one actually connected is different frm what it
expects it won't work.
The fact that you can find environments that don't support this doesn't
invalidate the creation of a portable API for those that do. Such an
interface could simply say "Sorry can't do that" where that is
appropriate. Some programs (well any program) just can't run usefully on
platforms with inadequate functionality, that's true of standard C as it
is.

The point is that the C library is mostly designed around things which
any C implementation can do. A program written to the C standard should
work on most platforms, if it needs to do something else then it becomes
less portable. Adding curses, which is inherently system-specific not
only in its implementation but also in its functionality, would bloat
the spec. with hundreds of functions which a lot of systems can't use
but which still take up space in the namespace.

As it is, I can have a perfectly portable program which has functions
called erase(), flash() etc. with no problem, only if I include the
(non-standard) curses.h do I encounter naming clashes. The C standard
mandates that standard functions must not be redefined.
It is OT because the C language designers chose not to provide such
support in standard C, not because they couldn't have done. Curses exists
despite things like the Model 33.

Well, no, it's orthogonal to the language. The curses library can
theoretically be used from any language on a system it supports (as long
as the calling conventions are compatible), it's a system feature not a
C one. It can also easily have multiple implementations (on my system I
have both curses and ncurses, and just link the appropriate one), and
can be extended without affecting the language standard.

Also, the standard for it is not dependent on the C standards
committees, which would take even more time arguing over it every time
new hardware comes along which needs an additional function.

There is something to be said for decoupling most of the existing C
library from the language, to make the language standard not dependent
on its environment at all...

Chris C
 
M

Malcolm

Chris Croughton said:
The point is that the C library is mostly designed around things which
any C implementation can do. A program written to the C standard should
work on most platforms, if it needs to do something else then it becomes
less portable. Adding curses, which is inherently system-specific not
only in its implementation but also in its functionality, would bloat
the spec. with hundreds of functions which a lot of systems can't use
but which still take up space in the namespace.
Actually this is already the case. Try printing a message to stderr in an MS
Windows GUI program, for example. There might be a way to catch the output,
but I haven't found it.
Most games consoles also have a very limited subset of the standard library,
and often that is useless, for instance because double precision arithmetic
is emulated in software.
My own view is that many programs need to be able to address a text raster
on a console, and many more need to be able to access a graphical window and
mouse. It would only take half a dozen functions to support these things

Win * TextWindow(int width, int height, int *wgot, int *hgot)
void printat(Win *win, int x, int y, char ch)
Win *GraphicsWindow(int width, int height, int *wgot, int *hgot, COLORMAP
*col)
void setpixel(Win *win, int x, int y, long rgb)
/* this one for efficiency */
void drawimage(Win *win, int x, int y, int width, int height, long *image)
/* if delay is non-zero, this could double as the synch function to flush
output to
the screen */
int querymouse(Win *win, int *x, int *y, int delay)
int kbhit(void)
void closeWindow(Win *win)

This would release third parties to produce systems for buttons and drivers
and so on. Text could default to 16 pixels by 20, or whatever is convenient.
Anyone really worried out appearance in graphics mode would build a font
library on top of the access functions anyway.
 
M

Mark McIntyre

Actually this is already the case. Try printing a message to stderr in an MS
Windows GUI program, for example. There might be a way to catch the output,
but I haven't found it.

MS's debugger from the resource kit, and also I think Sysinternals'
DBGVIEW.
 
C

CBFalconer

Malcolm said:
Actually this is already the case. Try printing a message to
stderr in an MS Windows GUI program, for example. There might be
a way to catch the output, but I haven't found it.

This is not a criticism of the standard, but of MS perversion of
existing standards. There is no reason for this failure. All gui
systems have at least a title area, which can be used for the
purpose.
 
R

Richard Bos

Malcolm said:
Actually this is already the case. Try printing a message to stderr in an MS
Windows GUI program, for example. There might be a way to catch the output,
but I haven't found it.

Neither have I, but then again, have you ever found a conforming hosted
implementation that creates MS Windows GUI programs? If you want a
conforming hosted implementation that creates MS Windows programs, try,
for example, Dev-C++'s C compiler. The non-GUI console programs it
creates have no problems with stdin/out/err.

Richard
 
C

Chris Croughton

Actually this is already the case. Try printing a message to stderr in an MS
Windows GUI program, for example. There might be a way to catch the output,
but I haven't found it.

That's a Windoze problem (in other words, it isn't meeting the standard
in that respect). It could easily pop up a message box, for instance,
or a text window. Complain to M$...
Most games consoles also have a very limited subset of the standard library,
and often that is useless, for instance because double precision arithmetic
is emulated in software.

They are catered for as freestanding implementations, which only need to
support the functions in <float.h>, <limits.h>, <stdarg.h> and
<stddef.h> (in C90; C99 adds a few more). There is, of course, no
guarantee that any aspect of the implementation is suitable for any
specific purpose (speed, size of object code, etc.) only that it works
according to the standard and produces the correct result.
My own view is that many programs need to be able to address a text raster
on a console, and many more need to be able to access a graphical window and
mouse. It would only take half a dozen functions to support these things

And many more don't. Almost all of the programs I've written in the
last 25 years (about 20 of them using C or C++ full-time) are quite
happy with a text stream as user input and output.
Win * TextWindow(int width, int height, int *wgot, int *hgot)
void printat(Win *win, int x, int y, char ch)
Win *GraphicsWindow(int width, int height, int *wgot, int *hgot, COLORMAP
*col)
void setpixel(Win *win, int x, int y, long rgb)
/* this one for efficiency */
void drawimage(Win *win, int x, int y, int width, int height, long *image)
/* if delay is non-zero, this could double as the synch function to flush
output to
the screen */
int querymouse(Win *win, int *x, int *y, int delay)
int kbhit(void)
void closeWindow(Win *win)

Well, you've now extended it to graphics terminals, thus limiting it
even more to certain hardware and operating systems.
This would release third parties to produce systems for buttons and drivers
and so on. Text could default to 16 pixels by 20, or whatever is convenient.

What is 'convenient' is a text mode terminal which can display at least
80 characters width in sequential order, and an input device which
generates characters. That is all that is needed for a conforming
hosted C implementation. Your suggestion would make it necessary to
provide even more hardware and functions to interrogate it (there is no
point in having a portable window without means to find out how big it
can be, how many colours it supports, how big the text is, etc.).
Anyone really worried out appearance in graphics mode would build a font
library on top of the access functions anyway.

No, they would (and do) go directly to the system API (or to the
hardware) to do it efficiently (try telling a games programmer that he
has to use functions which set one pixel at a line to draw a line, when
the hardware implements it as a single operation!). And no one would
ever agree about which functions are basic and which can be built
sensibly on top, because all of the hardware is different. Look at how
many graphics libraries there are, all with different interfaces because
they are designed for different things.

The point of the C library is that it is supposed to support the minimum
necessary to write workable programs, and allow extra libraries and
headers to do anything else.

Note that the curses library can be implemented using only the standard
C functions -- of course, it has to know which escape sequences to
issue to do things like cursor addressing, switching echo off, etc., but
for many terminals those can be done without any direct OS access at
all. The same could be true for a graphics system (the Tektronics
terminals, which are still emulated in some xterms, used an serial
character stream for graphics) and for pointing devices. But it's up to
the implementer and the user to determine the hardware characteristics
for those, not for the C standard to specify minimum hardware levels.

(I'm not too happy with some of the C99 specifications, they seem to be
going in the direction of too much hardware knowledge. It started with
specification of a particular floating point format, and supporting
complex arithmetic and the horrible type-generic macros...)

Chris C
 
M

Mark McIntyre

This is not a criticism of the standard, but of MS perversion of
existing standards.

Hang on. In point of fact, there's no perversion taking place here.
fprintf(stderr, is working, you just can't trivially see stderr.

There is no reason for this failure.

There /is/ no failure.
 
M

Michael Wojcik

Hang on. In point of fact, there's no perversion taking place here.
fprintf(stderr, is working, you just can't trivially see stderr.

It doesn't matter whether fprintf(stderr, ...) works for an MS Windows
GUI program. It's a freestanding environment.
There /is/ no failure.

Indeed.
 
M

Michael Wojcik

This is not a criticism of the standard, but of MS perversion of
existing standards. There is no reason for this failure.

There is no failure. MS Windows GUI programs are C programs running
under a freestanding implementation. There's no need for such an
implementation to support stdio at all, or if it does to do anything
useful with stdin, stdout, and stderr.

For that matter, there's no requirement for a hosted implementation to
successfully produce visible output when the program writes to stderr,
though obviously in that case it's a QoI issue.
All gui systems have at least a title area,

Not true. For years I used X Windows with various window managers
that did not waste screen real estate on pointless decorations like
window titles. (I still prefer that, but for work reasons I have to
run Windows, so I just use an X implementation on Windows that uses
the standard Windows look. Fortunately screen real estate is cheaper
these days.)
which can be used for the purpose.

Though how often that would be useful is dubious.

Certainly Windows could have done something useful by default with
stderr, such as writing it to a non-modal scrolling popup that could
be closed, moved, or minimized by the user. However, considering how
many gross usability errors there are in Windows even today (I don't
know how many times a week I encounter a window with text that can't
be selected and copied, for example), this wouldn't be high on my
list.

--
Michael Wojcik (e-mail address removed)

She felt increasingly (vision or nightmare?) that, though people are
important, the relations between them are not, and that in particular
too much fuss has been made over marriage; centuries of carnal
embracement, yet man is no nearer to understanding man. -- E M Forster
 
L

Lawrence Kirby

I guess the question is whether program output is output if it can't be
observed.
It doesn't matter whether fprintf(stderr, ...) works for an MS Windows
GUI program. It's a freestanding environment.

That depends on whether MS C compilers claim to provide a hosted
environment for console apps. Probably not but not impossible.

Lawrence
 
M

Mark McIntyre

I guess the question is whether program output is output if it can't be
observed.

And if a tree falls when there's no-one to hear it?
That depends on whether MS C compilers claim to provide a hosted
environment for console apps. Probably not but not impossible.

They do, but for console apps fprintf(stderr, works perfectly. Its for GUI
apps that there's an issue.
 

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,483
Members
44,901
Latest member
Noble71S45

Latest Threads

Top