gotoxy(x,y) in Linux?
William Lane
I'm looking for a way to code a gotoxy(x,y)
routine in Linux. Borland C/C++ for DOS used to have
a function gotoxy(x,y) that would allow you to output
text (in 80 column text mode) anywhere on the screen.
Is anything like this available in Linux? One
of the requirements of the code would be the ability
to output a text string anywhere on the screen at any
time.
Also, does anyone know of a clrscr() function
call in Linux?
I realize both of these functions probably involve
BIOS calls and aren't ANSI C but if someone could kindly
give me some ideas I'd appreciate it.
please post and email if at all possible,
thanks in advance,
-Bill Lane
Daniel Robert Franklin
> I'm looking for a way to code a gotoxy(x,y)
>routine in Linux. Borland C/C++ for DOS used to have
>a function gotoxy(x,y) that would allow you to output
>text (in 80 column text mode) anywhere on the screen.
> Is anything like this available in Linux? One
>of the requirements of the code would be the ability
>to output a text string anywhere on the screen at any
>time.
> Also, does anyone know of a clrscr() function
>call in Linux?
> I realize both of these functions probably involve
>BIOS calls and aren't ANSI C but if someone could kindly
>give me some ideas I'd appreciate it.
All this sort of thing is done with the ncurses library under Linux. It
won't be a direct translation of the Borland code but it won't be totally
different either.
- Daniel
--
******************************************************************************
* Daniel Franklin - Postgraduate student in Electrical Engineering
* d.fra...@computer.org
******************************************************************************
Rick Ellis
William Lane <wl...@csulb.edu> wrote:
> I'm looking for a way to code a gotoxy(x,y)
>routine in Linux. Borland C/C++ for DOS used to have
>a function gotoxy(x,y) that would allow you to output
>text (in 80 column text mode) anywhere on the screen.
> Is anything like this available in Linux? One
>of the requirements of the code would be the ability
>to output a text string anywhere on the screen at any
>time.
> Also, does anyone know of a clrscr() function
>call in Linux?
For a start:
man ncurses
man termcap
Greg Fruth
>
> I'm looking for a way to code a gotoxy(x,y)
> routine in Linux. Borland C/C++ for DOS used to have
> a function gotoxy(x,y) that would allow you to output
> text (in 80 column text mode) anywhere on the screen.
> Also, does anyone know of a clrscr() function
> call in Linux?
In a terminal window (or on the console), you probably want to
use curses. You could also use terminfo/termcap directly.
In a C program, try this short curses example:
#include <stdio.h>
#include <curses.h>
/* compile with "cc foo.c -lcurses" or somesuch */
int main() {
initscr();
clear();
move(10,10);
addstr("Hello world\n");
refresh();
}
In a Bourne-ish shell script, try this terminfo stuff:
CLEAR=`tput clear`
MOVE=`tput cup 10 10`
echo ${CLEAR}${MOVE}Hello world
Note: I tested these on HP-UX, not Linux. They may need some adjustment.
--
Gregory Fruth (gregor...@aero.org)
The Aerospace Corporation
Los Angeles, CA
Dexter Hobbs
> I'm looking for a way to code a gotoxy(x,y)
> routine in Linux. Borland C/C++ for DOS used to have
> a function gotoxy(x,y) that would allow you to output
> text (in 80 column text mode) anywhere on the screen.
> Is anything like this available in Linux? One
> of the requirements of the code would be the ability
> to output a text string anywhere on the screen at any
> time.
> Also, does anyone know of a clrscr() function
> call in Linux?
> I realize both of these functions probably involve
> BIOS calls and aren't ANSI C but if someone could kindly
> give me some ideas I'd appreciate it.
> please post and email if at all possible,
> thanks in advance,
> -Bill Lane
here ya go bill.
starting on page 391 of "Linux Application Development"
by Johnson and Troan
there is verrrry brief introduction to escape sequences
the following program
demonstrates how to make a gotoxy(x,y) function.
however let me complain first!!!!!
this stuff should be readily available on the web and in books.
its not.
problee bekuz of UNIXs "my top secret" ethic in the past.
that is changing with GNU and Linux.
these escape sequences are similiar to DOS escape sequences.
however steering a UNIX terminal is much more complicated
maybe bekuz of the age of UNIX
or maybe bekuz of the multplicity of UNIXes.
anyway the code is documented.
hope this helps.
to emulate a decent DOS program with
menus, etc
you got a lot of work to do.
but yull learn a lot along the way.
//compile with gcc -o goxy goxy.c
#include <stdio.h>
#include <string.h>
int gotoxy(int x, int y); //function prototype
int main()
{
system("exec clear"); //clear the screen
gotoxy(34, 12);
printf("%s", "hello congo"); //print hello congo in the middle of
the screen
gotoxy(1, 25); //move the cursor to the last line of the screen
return 0;
}
int gotoxy(int x, int y)
{
char es[100]; //string to hold the escape sequence
char xstr[100]; //need to convert the integers to strings
char ystr[100];
//convert the screen coordinates to strings
sprintf(xstr, "%d", x);
sprintf(ystr, "%d", y);
//build the escape sequence
es[0]='\0'; //truncate es to zero length
strcat(es, "\033["); //\033 is Esc in octal, 3*8 + 3 = 27
strcat(es, ystr); //concatenate the y move
strcat(es, "d"); // d is the code to move the cursor vertically
strcat(es, "\033[");
strcat(es, xstr);
strcat(es, "G"); //G is the code to move the cursor horizontally
//execute the escape sequence
printf("%s", es);
return 0;
}
Amir Hardon
What you are searching for, are cursor functions.
By default, Linux compilers aren't coming with built in cursor
libraries.
There is a library called ncurses, Which will do all what you need.
You can find it almost in any Linux programing related site.
Regards,
-Amir.
Peter T. Breuer
: William Lane wrote:
: these escape sequences are similiar to DOS escape sequences.
: however steering a UNIX terminal is much more complicated
Err, have you ever heard of using the statndard curses library? It looks
like you're trying to output in ansi! Don't.
move(y,x);
addstr(s)
refresh();
should set you to rights. Or use "mvaddstr" to do it in one?
: maybe bekuz of the age of UNIX or maybe bekuz of the multplicity of UNIXes.
: to emulate a decent DOS program with menus, etc you got a lot of work to do.
No you don't.
: but yull learn a lot along the way.
Looks like you missed out on something important. I hope you know about
java too :-).
Peter
: //compile with gcc -o goxy goxy.c
: #include <stdio.h>
: #include <string.h>
: return 0;
: }
: return 0;
: }
David M. Cook
> I'm looking for a way to code a gotoxy(x,y)
Others have recommended curses. An alternative I like is the S-Lang screen
handling library: http://www.s-lang.org
Dave Cook
Victor Wagner
: here ya go bill.
: starting on page 391 of "Linux Application Development"
: by Johnson and Troan
: there is verrrry brief introduction to escape sequences
: the following program
: demonstrates how to make a gotoxy(x,y) function.
: however let me complain first!!!!!
: this stuff should be readily available on the web and in books.
: its not.
: problee bekuz of UNIXs "my top secret" ethic in the past.
: that is changing with GNU and Linux.
No, there never was such an ethic in Unix world. You just cannot see
now entire iceberg. People told you to use curses, and they have
reasons.
Problem is that newbies coming from DOS world think that if they writing
program, they are writing program for Linux, and have to support only
Linux console. It is wrong.
They write program for multitasking distributed environment, which may
run on Linux console, may run in Xterm, and nothing prevent me from
telnetting from my UltraSparc (if I got one) to my Linux box and run
program on Solaris console. Also nothing prevent me from digging out my
dusty VT52 and attaching it to serial port of my Linux box. It is
assuming that you program is written so badly, that it cannot be ported
to Solaris or Compaq True Unix.
Look into /usr/share/terminfo - you'll find description of hundreds of
terminals there and each of them has somewhat different escape
sequences and flow control concepts.
curses would take care of it. It would look into terminfo database and
see: "Eh, our TERM is vt100 now. How do we clear screen in vt100?"
Even slang, second popular console toolkit is not universal. Its authors
think "Hey, nobody use hardware terminals now. Why would we bother with
XON/XOFF flow control". And they effectively cut lot of people from
their user base.
So, never never use escape sequences directly. Better to learn how to
program using curses, or at least slang.
--
<doogie> netgod: 8:42pm is not late.
<netgod> doogie: its 2:42am in Joeyland
-- #Debian
dex
: these escape sequences are similiar to DOS escape sequences.
: however steering a UNIX terminal is much more complicated
Err, have you ever heard of using the statndard curses library? It looks
like you're trying to output in ansi! Don't.
move(y,x);
addstr(s)
refresh();
should set you to rights. Or use "mvaddstr" to do it in one?
: maybe bekuz of the age of UNIX or maybe bekuz of the multplicity of
UNIXes.
: to emulate a decent DOS program with menus, etc you got a lot of work to
do.
No you don't.
: but yull learn a lot along the way.
Looks like you missed out on something important. I hope you know about
java too :-).
sorry, but i'm not emberust to wash my laundry in public.
yur koment about java is tottally off the wall.
and any way java aint that great.
i've seen some java applets run with enuf jerkies
to feed the whole sioux nation...
try bathing in C water.
i don't think youd know a good line of code if it bitchu.
didnt you like my comments?
was the code laid out badly?
it took me 2 hours t get it t run...
and when it ran i heard a little "eureka".
you ever hear that, kid?
and may i ask what important thing i missed out on, friend peter?
dexter hobbs
PS: i think some of the argument is falling thru the cracks
but dont despair
i think its operator err.
John Hasler
> to emulate a decent DOS program with menus, etc you got a lot of work to
> do.
Look at the text UI library 'newt'..
--
John Hasler
jo...@dhh.gt.org
Dancing Horse Hill
Elmwood, Wisconsin
dex
David M. Cook wrote in message ...
i think its a good idea to write some good ole ANSI escape sequences
to your terminal.
you will a lot and have greater respect for the "other" TV in the house.
i'm not advocating use escape sequences for commercial software.
but in a production environment where i can guarantee that
every box is running the same terminal i see no reason not to
write escape sequences to the terminal.
besides curses doesnt always work the way its supposed to.
okay maybe the bugs are mine, but they might be curses too.
quite frankly, curses is wierd...
the UNIX terminal is wierd if yur comin from the DOS world.
1000 terminals and 1000 ways to set 'm up.
great that makes 1 million terminals.
one for each programmer in the world.
i long ago gave up the quest of writing universal software.
1. i get the program to run on my LAN at home
2. i get it to run at work
3. i dont care if i runs half way around the world
on somebody minicomputer running HP unix
if somebody paid me to care, that would be different
but i dont hafta support every terminal and system
in the world.
and aren't there even binary incompatabilites
between all the versions of UNIX.
lots of my MS brand programs will only run on one windows platform.
3.11 or w95 or NT.
and they sure as hell dont run on apple either.
(altho lately watching a G4 video demo, i wish they did)
what i'm tryin t say is that anything is valid
as long as it works.
and BTW the curses documentation is miserable.
you couldnt write a program starting there.
man terminfo
man curses
hah!
talk about obfuskaashun
dex
John E. Davis
wrote:
>Even slang, second popular console toolkit is not universal. Its authors
>think "Hey, nobody use hardware terminals now. Why would we bother with
>XON/XOFF flow control". And they effectively cut lot of people from
>their user base.
I am not sure what you are referring to. S-Lang's SLang_init_tty
functions allows the control of XON/XOFF flow control. In fact slrn,
which uses slang has a `use_flow_control' variable that the user may
set to control this aspect.
--John
Grant Edwards
>i'm not advocating use escape sequences for commercial software.
>but in a production environment where i can guarantee that
>every box is running the same terminal i see no reason not to
>write escape sequences to the terminal.
Yea, right. That's what somebody once thought at my last
employer. He could gaurantee that everybody had a Wyse-60, so
why not hard-code all of the screen twiddling?
Well, guess what. Nobody has Wyse-60's any more, and all of
the terminal emulators have various compatibility problems.
Somebody should track that guy down and slap him up side the
head with an RS-232 cable. With DB-25 connectors.
>besides curses doesnt always work the way its supposed to.
>okay maybe the bugs are mine, but they might be curses too.
>quite frankly, curses is wierd...
Computers are wierd. Better not use them either...
>the UNIX terminal is wierd if yur comin from the DOS world.
>1000 terminals and 1000 ways to set 'm up. great that makes 1
>million terminals. one for each programmer in the world.
>
>i long ago gave up the quest of writing universal software.
Some of us are still tilting at windmills after 15+ years, and
I wouldn't have it any other way.
--
Grant Edwards grante Yow! Ask me the DIFFERENCE
at between PHIL SILVERS and
visi.com ALEXANDER HAIG!!
David Frantz
Just to offer a little moral support; I also see nothing wrong with directly
using ANSI or VT100 escape sequences. Sure it may mean that all the fancy
features that curses offer will never be used but for the types of programs
that are written for terminals these day who would care. The other
consideration is that every version of X has a VT100 emulator, so why not use
it, and save alot of work.
One other comment for those that work in this field; is that having a solid
understanding of how to drive a terminal via escape sequences can come in very
handy when working on industrial equipment. This happended to me reccently,
a little Linux VT100 experience made the project a snap. I would have
preferred to get rid of the old equipment but the mentality of manufacturing
does premit that.
Thanks
Dave
dex wrote:
> David M. Cook wrote in message ...
> >On 16 Dec 1999 01:19:43 GMT, William Lane <wl...@csulb.edu> wrote:
> >
> >> I'm looking for a way to code a gotoxy(x,y)
> >
> >Others have recommended curses. An alternative I like is the S-Lang screen
> >handling library: http://www.s-lang.org
> >
> >Dave Cook
>
> i think its a good idea to write some good ole ANSI escape sequences
> to your terminal.
> you will a lot and have greater respect for the "other" TV in the house.
>
> i'm not advocating use escape sequences for commercial software.
> but in a production environment where i can guarantee that
> every box is running the same terminal i see no reason not to
> write escape sequences to the terminal.
> besides curses doesnt always work the way its supposed to.
> okay maybe the bugs are mine, but they might be curses too.
> quite frankly, curses is wierd...
> the UNIX terminal is wierd if yur comin from the DOS world.
> 1000 terminals and 1000 ways to set 'm up.
> great that makes 1 million terminals.
> one for each programmer in the world.
>
> i long ago gave up the quest of writing universal software.
T.E.Dickey
I assumed he was confused about terminology: XON/XOFF versus interfaces
that require padding (like the machines we have down the hall at work with
a serial terminal plugged in to eliminate a graphics monitor ;-)
--
Thomas E. Dickey
dic...@clark.net
http://www.clark.net/pub/dickey
Robert Krawitz
> Just to offer a little moral support; I also see nothing wrong with
> directly using ANSI or VT100 escape sequences. Sure it may mean
> that all the fancy features that curses offer will never be used but
> for the types of programs that are written for terminals these day
> who would care. The other consideration is that every version of X
> has a VT100 emulator, so why not use it, and save alot of work.
What happens if someone is using a terminal emulator that is *not*
ANSI-compatible, or they don't have xterm handy?
--
Robert Krawitz <r...@alum.mit.edu> http://www.tiac.net/users/rlk/
Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail l...@uunet.uu.net
"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
David Frantz
Obviously it behoves one to make sure the design of a project suits the
intended hardware. The high level approach offered by curses is one
way to meet the requirements of a project. But targetting ANSI or
VT100 is also valid. By the way there are very few other terminal
standards you can say that about.
What I was trying to point out is that the skill required to understand
terminal handling is at times very very usefull. One should not get
hung up on stuff like this, so a little practice goes a long way.
Believe me I've seen fresh programmers that could handle comunnicating
with a dos screen much less a terminal.
With the advent of XFree and Linux, a program writen to ANSI standards
will be able to run on a huge number of machines. Sure some will not
be able to use that program, but if targeting ANSI / VT100 makes the
program smaller and easier to maintain then why not. By virtue of
Linux huge acceptance you will have hit the majority of the 'UNIX' users
out there.
Obviously this is not the answer for every project. It is however a
good choice for one off projects, or projects for a specific site. The
skills maintained by being able to drive a terminal can pay off when the
opportunity comes around to maintain an old piece of hardware. It is
even usefull if you are doing something new such as communicating with
the odd bar code printer, cnc machine or cell controller.
Best of luck
Dave
Robert Krawitz
> What I was trying to point out is that the skill required to understand
> terminal handling is at times very very usefull. One should not get
> hung up on stuff like this, so a little practice goes a long way.
> Believe me I've seen fresh programmers that could handle comunnicating
> with a dos screen much less a terminal.
That's all well and good, if you're writing a program that's
specifically targeted at an ANSI terminal because the device that the
program is specifically targeted for has an ANSI terminal. However,
desire to practice certain skills isn't a good reason in my book to
write a program that's inappropriately constrained to a certain
device. If the program's targeted at a general Linux audience, it
should work appropriately for such. If it's intended as a text mode
terminal application, it should work with (substantially) all text
mode terminals, including, for example, remote logins from a dtterm.
> With the advent of XFree and Linux, a program writen to ANSI standards
> will be able to run on a huge number of machines. Sure some will not
> be able to use that program, but if targeting ANSI / VT100 makes the
> program smaller and easier to maintain then why not. By virtue of
> Linux huge acceptance you will have hit the majority of the 'UNIX' users
> out there.
Why is it easier to maintain a program that uses explicit escape
sequences than one that uses ncurses, which is the real standard for
terminal handling? With a little more work it's easy to target (and
just as easy to maintain) support for all terminals that have a
terminfo description written.
> Obviously this is not the answer for every project. It is however a
> good choice for one off projects, or projects for a specific site. The
> skills maintained by being able to drive a terminal can pay off when the
> opportunity comes around to maintain an old piece of hardware. It is
> even usefull if you are doing something new such as communicating with
> the odd bar code printer, cnc machine or cell controller.
The original poster asked about how to write a particular function in
Linux. I think it's best to give the most general answer first absent
any more information on what the individual is doing.
David Frantz
> David Frantz <wiz...@eznet.net> writes:
>
> > What I was trying to point out is that the skill required to understand
> > terminal handling is at times very very usefull. One should not get
> > hung up on stuff like this, so a little practice goes a long way.
> > Believe me I've seen fresh programmers that could handle comunnicating
> > with a dos screen much less a terminal.
>
> That's all well and good, if you're writing a program that's
> specifically targeted at an ANSI terminal because the device that the
> program is specifically targeted for has an ANSI terminal. However,
> desire to practice certain skills isn't a good reason in my book to
> write a program that's inappropriately constrained to a certain
> device. If the program's targeted at a general Linux audience, it
> should work appropriately for such. If it's intended as a text mode
> terminal application, it should work with (substantially) all text
> mode terminals, including, for example, remote logins from a dtterm.
Some of the biggest failures I've seen software wise are due to a lack of
constraint.
As far as the general Linux audience, yes an applicaiton should work correctly
- but that does not mean that it has to work with every possible Linux
configuration. All software has dependancies mayby a graphics package,
gnome, xlib or what ever. You wouldn't expect somebody to have to support
KDE, gnome and a text interface from the same program. Some code, such as
VIM/GVIM, stand out as positive examples of multiple interface support.
That is great for those of us that use VIM, however it is stretch to say a
text mode program has to work on all terminals or access methods. It is
just as valid to code for other reasons, for example to eliminate library
depandancies, control generated code size or simplicity.
>
>
> > With the advent of XFree and Linux, a program writen to ANSI standards
> > will be able to run on a huge number of machines. Sure some will not
> > be able to use that program, but if targeting ANSI / VT100 makes the
> > program smaller and easier to maintain then why not. By virtue of
> > Linux huge acceptance you will have hit the majority of the 'UNIX' users
> > out there.
>
> Why is it easier to maintain a program that uses explicit escape
> sequences than one that uses ncurses, which is the real standard for
> terminal handling? With a little more work it's easy to target (and
> just as easy to maintain) support for all terminals that have a
> terminfo description written.
A function such as "goto(x,y)" shouldn't be that hard to maintain, if an
application needs only a couple of such functions the effort will be easier to
maintain than a curses solution. The problem with curses is this: how can
you verify program quality on hardware you may not have? I always work in
X, with terminal emulators available when need so programs can at least be
tested against the emulator. Anything beyound a simple program should be
connected to a library like curses in some manner. The problem is that a
whole host of programs are better off without curses.
>
>
> > Obviously this is not the answer for every project. It is however a
> > good choice for one off projects, or projects for a specific site. The
> > skills maintained by being able to drive a terminal can pay off when the
> > opportunity comes around to maintain an old piece of hardware. It is
> > even usefull if you are doing something new such as communicating with
> > the odd bar code printer, cnc machine or cell controller.
>
> The original poster asked about how to write a particular function in
> Linux. I think it's best to give the most general answer first absent
> any more information on what the individual is doing.
Yep general solutions are the way to go if the fit the requirements. I
don't really consider curses to be a general solution though, in many cases it
represents over kill.
Victor Wagner
: Robert Krawitz wrote:
: Obviously it behoves one to make sure the design of a project suits the
: intended hardware. The high level approach offered by curses is one
: way to meet the requirements of a project. But targetting ANSI or
: VT100 is also valid. By the way there are very few other terminal
: standards you can say that about.
But I suppose, that there is some order of things.
If we are talking for beginner, who doesn't even realize value of
portability, then he should first learn how to program, then - how to
program user interfaces, and only then might start to cope with
hardware.
Curses, as well as any other high-level library, tries to enforce some
interface concepts. And these concepts is what makes program usable. May
be if there was other concept, world would be better, but now each and
every computer user is used to these concepts.
: What I was trying to point out is that the skill required to understand
: terminal handling is at times very very usefull. One should not get
Of course, but it is very annoying to use program written by arrogant
guy, who is very proud of his ability to control hardware, but really
never have seen any hardware but PC. If he uses curses or slang, I might
try to fix his program, if not, I probably would have not enough time
for it and go for other solution.
So, if the honest newbie writes here and asks, best thing what we can
say him is - do not try to do something with direct driving of any
hardware, including terminal, before you have good understanding of
standards and customs in this area. So, start with standard libraries
such as ncurses, and when you'll learn them from beginning to end, you
can seek ways to go without them.
: With the advent of XFree and Linux, a program writen to ANSI standards
There no such things like XFree and Linux except in system
administration area. Anybody, who writes application program should write
for X11 (may be R6, but better to support R4 as well) and Unix.
There can be XFree on BSDI, Accelerated X on linux, user telnetting from
linux console to solaris host and vice versa.
And there are a lot of architectures and Linux run on many of them.
Differences between Alpha and PowerPC may be bigger than differences
between DUnix and Linux/Alpha or AIX and Linux/PPC.
And there are people who wish to connect old VT52 to their Linux
machines.
: will be able to run on a huge number of machines. Sure some will not
: be able to use that program, but if targeting ANSI / VT100 makes the
: program smaller and easier to maintain then why not. By virtue of
It, as well as choosing low-level apporach rather than high-level in any
other area would make program bigger, harder to maintain, and, most
important of all - harder to read by other people.
: Linux huge acceptance you will have hit the majority of the 'UNIX' users
: out there.
: Obviously this is not the answer for every project. It is however a
It is not an answer for person who is thinking "I'm programming for
Linux". Only person who knows that he is programming for Unix in general
and understand consequences of giving up portability, can do it.
--
T.E.Dickey
> Yep general solutions are the way to go if the fit the requirements. I
> don't really consider curses to be a general solution though, in many cases it
> represents over kill.
if it's not a "general" solution, that contradicts your followup clause
about "over kill" (make a choice: be consistent).
Robert Krawitz
> As far as the general Linux audience, yes an applicaiton should work
> correctly - but that does not mean that it has to work with every
> possible Linux configuration. All software has dependancies mayby a
> graphics package, gnome, xlib or what ever. You wouldn't expect
> somebody to have to support KDE, gnome and a text interface from the
> same program.
Certainly not, although given that there is a general solution for
text-based terminal interfaces, I do believe that it's reasonable that
any such application work correctly with any terminal possessing the
necessary capabilities for the program (and saying that "necessary
capabilities" includes "supports such and such escape sequences" is
weaselin). There is a standard for programs working with text-mode
terminals, and I think it's reasonable that that standard be used.
Some code, such as VIM/GVIM, stand out as positive
> examples of multiple interface support. That is great for those of
> us that use VIM, however it is stretch to say a text mode program
> has to work on all terminals or access methods. It is just as valid
> to code for other reasons, for example to eliminate library
> depandancies, control generated code size or simplicity.
Eliminating library dependencies is sometimes necessary, although most
if not all POSIX-compliant operating systems support curses to the
best of my knowledge. As for simplicity, curses is a reasonably
well-settled interface. And generated code size is normally much less
of an issue than it used to be.
If the intended target is really an embedded system, of course,
different constraints apply, but it sounded more like the original
poster was trying to translate a DOS program into UNIX/Linux, and
hence portability is fairly important. gotoxy() already sounds like a
fairly high level routine (at the level of curses).
> A function such as "goto(x,y)" shouldn't be that hard to maintain,
> if an application needs only a couple of such functions the effort
> will be easier to maintain than a curses solution. The problem with
> curses is this: how can you verify program quality on hardware you
> may not have?
You can't, but you have at least some assurance that if the terminal
description was written correctly your program will work correctly.
> > The original poster asked about how to write a particular function in
> > Linux. I think it's best to give the most general answer first absent
> > any more information on what the individual is doing.
>
> Yep general solutions are the way to go if the fit the requirements.
> I don't really consider curses to be a general solution though, in
> many cases it represents over kill.
Then what do you consider a general solution?
David Frantz
> David Frantz <wiz...@eznet.net> wrote:
>
> > Yep general solutions are the way to go if the fit the requirements. I
> > don't really consider curses to be a general solution though, in many cases it
> > represents over kill.
>
> if it's not a "general" solution, that contradicts your followup clause
> about "over kill" (make a choice: be consistent).
>
I think that is exactly what I meant. Curses is to large and complex to represent
a general solution, thus the competing libraries or writing directly to the
terminal. You can't call curses a general solution if it is more over head than
benefit.
Dave
Robert Krawitz
> "T.E.Dickey" wrote:
>
> > David Frantz <wiz...@eznet.net> wrote:
> >
> > > Yep general solutions are the way to go if the fit the requirements. I
> > > don't really consider curses to be a general solution though, in many cases it
> > > represents over kill.
> >
> > if it's not a "general" solution, that contradicts your followup clause
> > about "over kill" (make a choice: be consistent).
> >
>
> I think that is exactly what I meant. Curses is to large and
> complex to represent a general solution, thus the competing
> libraries or writing directly to the terminal. You can't call
> curses a general solution if it is more over head than benefit.
Then what do you propose as a general (i. e. works in the greatest
number of cases from the end user point of view, not what's most
convenient for the developer) solution?
David Frantz
> David Frantz <wiz...@eznet.net> writes:
>
> > As far as the general Linux audience, yes an applicaiton should work
> > correctly - but that does not mean that it has to work with every
> > possible Linux configuration. All software has dependancies mayby a
> > graphics package, gnome, xlib or what ever. You wouldn't expect
> > somebody to have to support KDE, gnome and a text interface from the
> > same program.
>
> Certainly not, although given that there is a general solution for
> text-based terminal interfaces, I do believe that it's reasonable that
> any such application work correctly with any terminal possessing the
> necessary capabilities for the program (and saying that "necessary
> capabilities" includes "supports such and such escape sequences" is
> weaselin). There is a standard for programs working with text-mode
> terminals, and I think it's reasonable that that standard be used.
I agree that curses is one library to use with text mode programs, and for
some applications a very good one. However its not the only standard,
other libraries are out there; also the option of talking directly to the
terminal should not be forgotten.
I also strongly believe that the option of what to support interface wise and
how to support it should be left up to the developer. If someone is only
interested in the Linux market and decides to support only an ANSI or VT100
interface, then that should be his option. To say that some one should
use Curses because it is the standard is a problem depending on perspective.
It may very well be required to have standards on a large project built by
many hands. However the original poster did not indicate that that was the
case, so his options are wide open. Working in a facility were windows
is the "standard", has really left me with a negative impression of people
who demand standards at the expense of innovation or efficiency. Curses
may be the most efficient library to use on some projects but it can never be
the only choice.
>
>
> Some code, such as VIM/GVIM, stand out as positive
> > examples of multiple interface support. That is great for those of
> > us that use VIM, however it is stretch to say a text mode program
> > has to work on all terminals or access methods. It is just as valid
> > to code for other reasons, for example to eliminate library
> > depandancies, control generated code size or simplicity.
>
> Eliminating library dependencies is sometimes necessary, although most
> if not all POSIX-compliant operating systems support curses to the
> best of my knowledge. As for simplicity, curses is a reasonably
> well-settled interface. And generated code size is normally much less
> of an issue than it used to be.
This could very well be the case, even if it isn't compilers and linkers are
getting better every day.
>
>
> If the intended target is really an embedded system, of course,
> different constraints apply, but it sounded more like the original
> poster was trying to translate a DOS program into UNIX/Linux, and
> hence portability is fairly important. gotoxy() already sounds like a
> fairly high level routine (at the level of curses).
I think here if the target is linux and you are porting a program there are
many issues to consider. One of those issues is the replacement of screen
handling routines, it may be in the programmers best interest to target a
ANSI screen with either a library or a few routines of his own. Curses
could be the answer but I would imagine the original coder has many
constraints he is working with, not the least of which is time. Once he
has seen whats available on linux he can then select the best choice.
>
>
> > A function such as "goto(x,y)" shouldn't be that hard to maintain,
> > if an application needs only a couple of such functions the effort
> > will be easier to maintain than a curses solution. The problem with
> > curses is this: how can you verify program quality on hardware you
> > may not have?
>
> You can't, but you have at least some assurance that if the terminal
> description was written correctly your program will work correctly.
>
> > > The original poster asked about how to write a particular function in
> > > Linux. I think it's best to give the most general answer first absent
> > > any more information on what the individual is doing.
> >
> > Yep general solutions are the way to go if the fit the requirements.
> > I don't really consider curses to be a general solution though, in
> > many cases it represents over kill.
>
> Then what do you consider a general solution?
On linux, I consider the general solution for text based applications to be
the VT100 emulation on a number of differrent terminal emulators. It
happens to be the text mode solution that is available on the widest range of
linuix implementations. When curses is brought up along with portability
that could imply a general solution.
However general or portable solutions across the large number of UNIX/POSIX
implementations is not always as easy as it first seems. Indeed it can be
difficult on linux considering all of the different hardware & CPUs
available. It may be my mistake to constrain the concept of a 'general
solution' to one platform such as Linux, but in practice that is often the
result of a coding effort. Sometimes that is the result even when not
intended. The fact that any ditribution of linux can have a VT100 window
is a general solution from my standpoint, that terminal can be accessed in a
number of different ways.
Have a MERRY CHRISTMAS and a HAPPY NEW YEAR
Dave
Victor Wagner
: Robert Krawitz wrote:
:> device. If the program's targeted at a general Linux audience, it
:> should work appropriately for such. If it's intended as a text mode
:> terminal application, it should work with (substantially) all text
:> mode terminals, including, for example, remote logins from a dtterm.
: Some of the biggest failures I've seen software wise are due to a lack of
: constraint.
And I've seen some biggest failures due to attempt to reinvent the
wheel.
And I've never seen good user interfaces written with Borland-like conio
alone.
If you need good full-screen interface, you need some high-level
library, such as curses, or, under DOS cxl, Turbo Vision or Turbo
Professional.
If you don't want to use them and want something simplier, you should
stick with plain stdio and target your program as command-line
utility. Hybrids beteween these two classes never done good.
--
Wow, I'm being shot at from both sides. That means I *must* be right. :-)
-- Larry Wall in <1997102119...@wall.org>
David Frantz
> David Frantz <wiz...@eznet.net> wrote:
> : Robert Krawitz wrote:
>
> : Obviously it behoves one to make sure the design of a project suits the
> : intended hardware. The high level approach offered by curses is one
> : way to meet the requirements of a project. But targetting ANSI or
> : VT100 is also valid. By the way there are very few other terminal
> : standards you can say that about.
>
> But I suppose, that there is some order of things.
> If we are talking for beginner, who doesn't even realize value of
> portability, then he should first learn how to program, then - how to
> program user interfaces, and only then might start to cope with
> hardware.
>
> Curses, as well as any other high-level library, tries to enforce some
> interface concepts. And these concepts is what makes program usable. May
> be if there was other concept, world would be better, but now each and
> every computer user is used to these concepts.
>
> : What I was trying to point out is that the skill required to understand
> : terminal handling is at times very very usefull. One should not get
>
> Of course, but it is very annoying to use program written by arrogant
> guy, who is very proud of his ability to control hardware, but really
> never have seen any hardware but PC. If he uses curses or slang, I might
> try to fix his program, if not, I probably would have not enough time
> for it and go for other solution.
If you do have a person new to programming would you tend to start him out
learning how to control a device like a terminal with a library like slang or
teach him how to handle a few terminals directly? Personnally if I needed
a systems programmer I would hope that he learn his craft from the bottom
up. While he was developing his skills I'd would hope that the talent to
select the right software would allow him to select the right tool from his
systems pool of libraries.
>
>
> So, if the honest newbie writes here and asks, best thing what we can
> say him is - do not try to do something with direct driving of any
> hardware, including terminal, before you have good understanding of
> standards and customs in this area. So, start with standard libraries
> such as ncurses, and when you'll learn them from beginning to end, you
> can seek ways to go without them.
This is a rather inverted way to teach someone. Once a little effort has
been expended on driving some hardware the value of curses or whatever will
be easier to grasp in any situation presented to the "newbie". Would you
consider teaching such a newbie advance database techniques before he learned
simple file I/O?
>
>
> : With the advent of XFree and Linux, a program writen to ANSI standards
>
> There no such things like XFree and Linux except in system
> administration area. Anybody, who writes application program should write
> for X11 (may be R6, but better to support R4 as well) and Unix.
>
> There can be XFree on BSDI, Accelerated X on linux, user telnetting from
> linux console to solaris host and vice versa.
>
> And there are a lot of architectures and Linux run on many of them.
> Differences between Alpha and PowerPC may be bigger than differences
> between DUnix and Linux/Alpha or AIX and Linux/PPC.
This is one of the reasons I consider an ANSI or VT100 terminal a common
thread amongst the possible linux implementations.
>
>
> And there are people who wish to connect old VT52 to their Linux
> machines.
>
> : will be able to run on a huge number of machines. Sure some will not
> : be able to use that program, but if targeting ANSI / VT100 makes the
> : program smaller and easier to maintain then why not. By virtue of
>
> It, as well as choosing low-level apporach rather than high-level in any
> other area would make program bigger, harder to maintain, and, most
> important of all - harder to read by other people.
>
So someone puts a clear screen function, a goto function in a compilation
unit and includes those funtions in his program he has made his program
bigger, harder to maintain and harder to read. I think we both know the
answer to this one is not a chance! I really believe that curses has a
place but for doing a port of a dos based program one simply has think hard
about how much effort they want to put into the port and the quickest way to
do that, amongst other things. Portability is nice but its rather selfish
to think that everyone can expend the time to be portable.
thanks
dave
David Frantz
> David Frantz <wiz...@eznet.net> writes:
>
> > "T.E.Dickey" wrote:
> >
> > > David Frantz <wiz...@eznet.net> wrote:
> > >
> > > > Yep general solutions are the way to go if the fit the requirements. I
> > > > don't really consider curses to be a general solution though, in many cases it
> > > > represents over kill.
> > >
> > > if it's not a "general" solution, that contradicts your followup clause
> > > about "over kill" (make a choice: be consistent).
> > >
> >
> > I think that is exactly what I meant. Curses is to large and
> > complex to represent a general solution, thus the competing
> > libraries or writing directly to the terminal. You can't call
> > curses a general solution if it is more over head than benefit.
>
> Then what do you propose as a general (i. e. works in the greatest
> number of cases from the end user point of view, not what's most
> convenient for the developer) solution?
>
My point is that it is really the developer that needs to decide how much effort he
will put into his port. At this time we don't even know who the end users might be,
we do know hoever that he wanted to know how to do a goto() on screen. Since he is
porting a dos application one of his possible solutions is to write a goto rutine that
works just like its dos counter part. If he only needs a couple of functions the he
is all set.
I think it would be foolish to demand that he port his program in such a way that its
portable to all known UNIX machines on the planet. For all we know his screen
handling problem may be the easiest part of the port or the one he feels he can spend
the least amount of time on. It is better too have code that runs on a small subset
of machines than to have no code at all.