POSIX and getch(), clrscr()

[Michele 'xjp']

Hi there,
I am using a POSIX-compliant system, Cygwin on Windows.

I need the features of conio.h's getch() and clrscr(), but I can't
compile programs with #include <conio.h> (since conio.h is NOT POSIX).

I tried to implement myself clrscr() with system("cls"), but the program
compiles ok, but during the running it will show:

sh: cls: command not found

(on filecompiled.exe runned on Windows).

Is there away to implement clrscr() and getch() ?

Thank you

PS: a C++ program POSIX-compliant with advantages have? "Only" portability?
Any drawbacks?

 

[Michael DOUBEZ]

Michele 'xjp' a écrit :

Hi there,
I am using a POSIX-compliant system, Cygwin on Windows.

I need the features of conio.h's getch() and clrscr(), but I can't
compile programs with #include <conio.h> (since conio.h is NOT POSIX).

I tried to implement myself clrscr() with system("cls"), but the program
compiles ok, but during the running it will show:

sh: cls: command not found

(on filecompiled.exe runned on Windows).

Is there away to implement clrscr() and getch() ?

getch() you cannot. This is due to the way terms are handled.
The same is true for clrscr().
A long time ago, printf( "\e[2J\e[H" ) did that but I don't expect it to
be portable.

PS: a C++ program POSIX-compliant with advantages have? "Only" portability?
Any drawbacks?

Portability on POSIX system only.

Michael

 

[Robert Bauck Hamar]

Michele 'xjp' a écrit :

This should suggest to you that some POSIX or UNIX-group should be more
relevant for your question.

No. Perhaps you want some curses library. I believe Cygwin comes with a
ncurses port.

getch() you cannot. This is due to the way terms are handled.

You would have to change the way terminals are handled. It is possible and
not very hard, but way off topic for this news group. The command 'man
termios' will give some info. Questions should be asked in a POSIX or UNIX
forum.

The same is true for clrscr().
A long time ago, printf( "\e[2J\e[H" ) did that but I don't expect it to
be portable.

The output codes _are_ standardised, but not in the C++ standard.

 

[Default User]

Hi there,
I am using a POSIX-compliant system, Cygwin on Windows.

I need the features of conio.h's getch() and clrscr(), but I can't
compile programs with #include <conio.h> (since conio.h is NOT POSIX).

Everything here is off-topic. Try either the Cygwin mailing list, or
comp.unix.programmer.




Brian

 

[James Kanze]

I am using a POSIX-compliant system, Cygwin on Windows.

This is the first I've heard that Cygwin is Posix compliant.

I need the features of conio.h's getch() and clrscr(), but I
can't compile programs with #include <conio.h> (since conio.h
is NOT POSIX).

Is there away to implement clrscr() and getch() ?

Traditionally, under Unix, they are part of the curses library.
(I don't think this is Posix, but rather an Open Systems
extension to Posix.) Versions are available for Windows (under
the name ncurses, I think), so you can use it more or less
portably.

PS: a C++ program POSIX-compliant with advantages have? "Only"
portability? Any drawbacks?

The Windows Posix-compliant layer is only there for the show;
from what I hear, it's not really usable. The CygWin toolset
runs significantly slower than anything else under Windows
(including UWin or MSys), and I suspect (although I've not
verified) that this is due to some Unix-like intermediate layer.

In general, you can suppose that native Windows will run better
(faster, more reliably) under Windows than any Unix-like
emulation, and that native Unix will run better under Unix than
any Windows like emulation. The basic functionalities of the
two systems are, however, very, very similar (except maybe for
some of the threading primitives---although recent versions of
Windows also have Posix-like conditional variables), so it is
relatively simple to define a neutral interface, implement it
for both systems, and use it. In no case would I try to do
Posix under Windows (or vice versa).

 

[James Kanze]

Michael DOUBEZ wrote:

[...]

A long time ago, printf( "\e[2J\e[H" ) did that but I don't
expect it to be portable.

The output codes _are_ standardised, but not in the C++ standard.

The backslash escape codes are standardized in the C++ standard,
and "\e" is not one of them. He probably meant "\033" or
"\x1b". The meaning of such escape sequences is defined by
ISO/IEC 6429---an ISO standard, but not the C++ standard, as you
say. The correct escape sequence to clear the screen would be
"\033[2J"; whether this will actually do anything, of course,
depends on whether the target device is conform to the
appropriate standard, and not on whether the compiler is conform
to the C++ standard (or is even C++).

 

[Michele 'xjp']

James Kanze ha scritto:

This is the first I've heard that Cygwin is Posix compliant.



Traditionally, under Unix, they are part of the curses library.
(I don't think this is Posix, but rather an Open Systems
extension to Posix.) Versions are available for Windows (under
the name ncurses, I think), so you can use it more or less
portably.

However, I've implemented clrscr() with:
printf("\e[2J")

and getch-like with:
char tmp;
cout << "Press ENTER to continue" << endl;
cin >> tmp;

 

[James Kanze]

James Kanze ha scritto:

However, I've implemented clrscr() with:
printf("\e[2J")

It works on my system, too. Because my terminal windows are
always xterm's, and X (yet another standard) requires that xterm
implement ANSI escape sequences.

The curses library will ensure that it will work on any terminal
that the system supports.

and getch-like with:
char tmp;
cout << "Press ENTER to continue" << endl;
cin >> tmp;

That doesn't do anything near the same thing. getch reads a
single character, immediately (without waiting for a new line),
and returns it without echoing.

 

[Thomas Dickey]

It works on my system, too. Because my terminal windows are
always xterm's, and X (yet another standard) requires that xterm
implement ANSI escape sequences.

X doesn't require that.

xterm implemented a vt102 ~20 years ago just because it was the most
common type (but even then it implemented some other terminal's features).

most of vt102 is ANSI (say 80%).