Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

gotoxy(x,y) in Linux?

1,602 views
Skip to first unread message

William Lane

unread,
Dec 16, 1999, 3:00:00 AM12/16/99
to

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

unread,
Dec 16, 1999, 3:00:00 AM12/16/99
to
wl...@csulb.edu (William Lane) writes:


> 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

unread,
Dec 16, 1999, 3:00:00 AM12/16/99
to
In article <839enf$d0a$2...@hatathli.csulb.edu>,
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

--
http://www.fnet.net/~ellis/photo/linux.html

Greg Fruth

unread,
Dec 16, 1999, 3:00:00 AM12/16/99
to
In article <839enf$d0a$2...@hatathli.csulb.edu>, wl...@csulb.edu (William Lane) writes:
>
> 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

unread,
Dec 16, 1999, 3:00:00 AM12/16/99
to
William Lane 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?

> 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

unread,
Dec 17, 1999, 3:00:00 AM12/17/99
to
William hello,
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

unread,
Dec 17, 1999, 3:00:00 AM12/17/99
to
Dexter Hobbs <d...@landho.com> wrote:
: 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

unread,
Dec 18, 1999, 3:00:00 AM12/18/99
to
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


Victor Wagner

unread,
Dec 18, 1999, 3:00:00 AM12/18/99
to
Dexter Hobbs <d...@landho.com> wrote:

: 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

unread,
Dec 19, 1999, 3:00:00 AM12/19/99
to
: 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 :-).


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

unread,
Dec 19, 1999, 3:00:00 AM12/19/99
to
William Lane wrote:
> 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

unread,
Dec 19, 1999, 3:00:00 AM12/19/99
to

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

unread,
Dec 20, 1999, 3:00:00 AM12/20/99
to
On 18 Dec 1999 11:33:27 +0300, Victor Wagner <vi...@wagner.rinet.ru>
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

unread,
Dec 20, 1999, 3:00:00 AM12/20/99
to
In article <385d9b70$0$2...@nntp1.ba.best.com>, dex wrote:

>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

unread,
Dec 20, 1999, 3:00:00 AM12/20/99
to
Hi dex;

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

unread,
Dec 21, 1999, 3:00:00 AM12/21/99
to

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

unread,
Dec 21, 1999, 3:00:00 AM12/21/99
to
David Frantz <wiz...@eznet.net> writes:

> 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

unread,
Dec 21, 1999, 3:00:00 AM12/21/99
to
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.

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

unread,
Dec 22, 1999, 3:00:00 AM12/22/99
to
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.

> 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

unread,
Dec 22, 1999, 3:00:00 AM12/22/99
to
Robert Krawitz wrote:

> 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

unread,
Dec 22, 1999, 3:00:00 AM12/22/99
to
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.

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

unread,
Dec 23, 1999, 3:00:00 AM12/23/99
to
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).

Robert Krawitz

unread,
Dec 23, 1999, 3:00:00 AM12/23/99
to
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.



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

unread,
Dec 23, 1999, 3:00:00 AM12/23/99
to
"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.


Dave

Robert Krawitz

unread,
Dec 23, 1999, 3:00:00 AM12/23/99
to
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?

David Frantz

unread,
Dec 23, 1999, 3:00:00 AM12/23/99
to
Robert Krawitz wrote:

> 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

unread,
Dec 24, 1999, 3:00:00 AM12/24/99
to
David Frantz <wiz...@eznet.net> wrote:
: 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

unread,
Dec 24, 1999, 3:00:00 AM12/24/99
to
Victor Wagner wrote:

> 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

unread,
Dec 24, 1999, 3:00:00 AM12/24/99
to
Robert Krawitz wrote:

> 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.

David Frantz

unread,
Dec 24, 1999, 3:00:00 AM12/24/99
to
Victor Wagner wrote:

> David Frantz <wiz...@eznet.net> wrote:
> : 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.
>

I agree totally with your statements about conio being ugly. However if
your porting a dos application it can very well make sense to emulate such an
environment. As such your not reinventing the wheel just bolting it to
another car. Once your up on the highway and everything is running
smoothly you can consider upgrading to those fancy all weather radial.

Robert Krawitz

unread,
Dec 25, 1999, 3:00:00 AM12/25/99
to
David Frantz <wiz...@eznet.net> writes:

> Victor Wagner wrote:

> 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.

I am an experienced system programmer myself. There is absolutely no
question that I would start out a new programmer with an appropriate
interface library, and would not even allow him or her reference to
the terminal (or other hardware) programming manual.

Why? There are quite a few reasons, actually:

1) One of the most important concepts to learn in programming is
abstraction. If the project will involve controlling a terminal,
it is important that the new programmer learn an organized method
for doing so that focuses on the abstract operations required, not
one that focuses on the particular bits that have to be set. Only
later, when this person has developed the judgement required to
know when it is necessary to drop below the abstract terminal layer
(for performance, or because someone really needs to do something
obscure that isn't handled in the library), would I allow him or
her to consider such a course of action.

2) Except for the absolute bare bones bit twiddling (which basically
means header file writing), system programming is not about
memorizing sequences of bits. Unix and Linux kernels are still
overwhelmingly written in C, with only a tiny part of the
machine-specific code written in assembler. And what's more, most
of the code (even in something as deep down as the VM system) is
fairly abstract. It has to be, or nobody could ever maintain it.

3) Every significant system programming project I have ever seen
follows these principles. I worked on microcode for the Connection
Machine (CM-2). The microassembler that we used was written in
Lisp, and there was heavy use of Lisp macros (which are nothing
like C macros -- Lisp macros use the full power of the language and
allow extension and even redefinition of it) to build up higher
level abstract operations. When that wasn't enough, somebody else
wrote a higher level assembler for floating point microcode that
allowed hiding even more detail.

> 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".

Well, maybe because actually driving hardware is such a pain in the
rear, but it still seems awfully strange to me to insist that somebody
start at the bit level. Mistakes here are really hard to debug.



Would you
> consider teaching such a newbie advance database techniques before he learned
> simple file I/O?

Probably (notice that I didn't say "definitely", at least insofar as
basic SQL is considered "advanced") not, but I'd certainly teach stdio
before introducing the read() or write() system calls.

> > 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.

Even SPARC/Linux? I'm quite certain that Sun consoles don't emulate
ANSI terminals, although it's possible that the SPARC/Linux console
driver does.

> 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.

Put those functions in -- that's fine -- but write them in terms of
curses rather than raw escape sequences!

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.

Now wait a minute here. The goal here is to port the DOS program, so
by definition portability is important. We can argue about how much
portability is required, but the entire idea here is to port
something. There's nothing wrong with implementing a compatibility
library like that, and I agree that it's a good idea at least at first
because it avoids having to deal with what might be fairly messy but
not particularly important logic. However, I see no harm in
suggesting that it be implemented in terms of a more general library
such as curses.

David Frantz

unread,
Dec 25, 1999, 3:00:00 AM12/25/99
to
Robert Krawitz wrote:

While I can see your points from one perspective, wouldn't be easier to understand
the concepts of abstraction form the bottom up? I'm not saying that libraries
such as curses and concept of abstraction are not important, but it would be much
easier to understand the value of abstraction if one is exposed to the messy
details of whats being abstracted. Form the stand point of educating
programmers currently this is one issue that is sorely missed in the current
education system. Obviously I'm biased by what I'm exposed to in the world of
industrial control which can be a bit differrent than writing software for a
corporate system. It is frustrating to see a programmer go glassy eyed when he
has to create that abstraction layer.

I noticed in comment three that you have worked on some leading edge stuff, but
even there you indicate that low level prrogramming has to be done before an
abstraction mechanism is in place. Would someone who was taught to program
with system libraries and the abstraction they provide be able to build this lower
level code to support the abstraction layer that is not there?

>
> Would you
> > consider teaching such a newbie advance database techniques before he learned
> > simple file I/O?
>
> Probably (notice that I didn't say "definitely", at least insofar as
> basic SQL is considered "advanced") not, but I'd certainly teach stdio
> before introducing the read() or write() system calls.
>
> > > 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.
>
> Even SPARC/Linux? I'm quite certain that Sun consoles don't emulate
> ANSI terminals, although it's possible that the SPARC/Linux console
> driver does.

My biggest failing is my bias towards X. Having little esposure to SPARC/Linux
I can't say what they are capable of. Also does LinuxPPC even have a console
mode. Having read about Linux on apple machines booting into X because of the
lack of support software on the video cards, I'm suddenly wondering how they do
virtual consoles and what they support. I would imagine though that under X
even LinuxPPC supports a ANSI emulator.

>
>
> > 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.
>
> Put those functions in -- that's fine -- but write them in terms of
> curses rather than raw escape sequences!
>
> 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.
>
> Now wait a minute here. The goal here is to port the DOS program, so
> by definition portability is important. We can argue about how much
> portability is required, but the entire idea here is to port
> something. There's nothing wrong with implementing a compatibility
> library like that, and I agree that it's a good idea at least at first
> because it avoids having to deal with what might be fairly messy but
> not particularly important logic. However, I see no harm in
> suggesting that it be implemented in terms of a more general library
> such as curses.

Mayby I went a bit over board. But I believe that it would be most helpful to
people porting software that they be aware of the many possible solutions a
problem. Niether one of us has even mentioned the possiblities pointed out by
others such as slang. Not mentioning all the possibilities when it comes to
porting software his something I should try to avoid in the future.

In the context of the original posters question about porting a DOS based program,
using apparently "conio", it would seem to me that the first choice would be a
compatiablility package. I willing to change my mind if someone can
demonstrate a drop in replacement for conio that does not require a rewrite of a
port. Overall though; it is the program being ported and the time available
to do the port that will dictate what fits best.


dave

Robert Krawitz

unread,
Dec 25, 1999, 3:00:00 AM12/25/99
to
David Frantz <wiz...@eznet.net> writes:

> Robert Krawitz wrote:
>
> While I can see your points from one perspective, wouldn't be easier
> to understand the concepts of abstraction form the bottom up? I'm
> not saying that libraries such as curses and concept of abstraction
> are not important, but it would be much easier to understand the
> value of abstraction if one is exposed to the messy details of whats
> being abstracted. Form the stand point of educating programmers
> currently this is one issue that is sorely missed in the current
> education system. Obviously I'm biased by what I'm exposed to in
> the world of industrial control which can be a bit differrent than
> writing software for a corporate system. It is frustrating to see a
> programmer go glassy eyed when he has to create that abstraction
> layer.

I understand your point from the standpoint of industrial control, but
I still believe that one is better off learning an abstract terminal
model than the details of an ANSI terminal for starters.

An abstract terminal provides certain operations that apply for any
given type of terminal. In fact, the gotoxy() function that the
original poster was interested in is an example of an abstract
terminal manipulator (put the cursor in such-and-such position).
Application programmers are normally more interested in positioning
the cursor, writing text, drawing graphics, and so forth than in the
details of specific sequences of bytes required to achieve these ends.

Furthermore, knowing how to program a VT100 doesn't really help one
program a Tektronix graphical terminal. It also doesn't always work
quite correctly on a VT220 or even on an xterm.

There is a standard for such terminal manipulation under Unix,
curses. It is almost always better for an application writer to use
this standard than to roll one's own based on knowledge of a
particular terminal type. This hides the detailed information about
specific terminal types, allowing the application writer to consider
what needs to be done from an engineering perspective.

> I noticed in comment three that you have worked on some leading edge
> stuff, but even there you indicate that low level prrogramming has
> to be done before an abstraction mechanism is in place. Would
> someone who was taught to program with system libraries and the
> abstraction they provide be able to build this lower level code to
> support the abstraction layer that is not there?

Yes. In fact, it's the familiarity with abstraction that helps one
design the lower level code in the first place that supports the
higher level abstraction -- somebody has to know what's going to work!

Certainly some very low-level code had to be written by people
well-versed in the hardware, but that was kept to a minimum to
preserve everyone's sanity. You'll note that one of the most crucial
low-level tools (a micro-assembler) was designed to permit a fairly
high level programming model.

> In the context of the original posters question about porting a DOS
> based program, using apparently "conio", it would seem to me that
> the first choice would be a compatiablility package. I willing to
> change my mind if someone can demonstrate a drop in replacement for
> conio that does not require a rewrite of a port. Overall though; it
> is the program being ported and the time available to do the port
> that will dictate what fits best.

I agree with the use of a compatibility library (at least initially);
I'm just arguing that the compatibility library should be written in a
fairly general fashion.

T.E.Dickey

unread,
Dec 26, 1999, 3:00:00 AM12/26/99
to
David Frantz <wiz...@eznet.net> wrote:
> While I can see your points from one perspective, wouldn't be easier to understand
> the concepts of abstraction form the bottom up? I'm not saying that libraries
> such as curses and concept of abstraction are not important, but it would be much

back off a little & try to understand what you are saying, in a different
context: I would consider anyone who prefers to put together a collection
of transistors and other discreter components to using a set of IC's to
be unemployable (however enjoyable the "learning" experience is, no one's
going to use his result except for him).

-- it's better to learn the lessons that other people have already learned,
but by spending less time (start with high-level abstractions and work
into specialization).

David Frantz

unread,
Dec 26, 1999, 3:00:00 AM12/26/99
to
"T.E.Dickey" wrote:

> David Frantz <wiz...@eznet.net> wrote:
> > While I can see your points from one perspective, wouldn't be easier to understand
> > the concepts of abstraction form the bottom up? I'm not saying that libraries
> > such as curses and concept of abstraction are not important, but it would be much
>

> back off a little & try to understand what you are saying, in a different
> context: I would consider anyone who prefers to put together a collection
> of transistors and other discreter components to using a set of IC's to
> be unemployable (however enjoyable the "learning" experience is, no one's
> going to use his result except for him).
>
> -- it's better to learn the lessons that other people have already learned,
> but by spending less time (start with high-level abstractions and work
> into specialization).
>
> --
> Thomas E. Dickey
> dic...@clark.net
> http://www.clark.net/pub/dickey

I would agree that such a person was unemployable if they did not understand current
microprocessor hardware. However I do believe, mind you its been some time, that at
some point in is education a student on a track for an EE in computer systems will at
some point in time learn about logic gates. He may even have to implement a circuit
or two. Sure he will quickly progress to larger concepts but that initial fumbling
with transistors and gate can provide a strong foundation for building a large scale
system on a cad system.

In reference to your comment, if you needed an ASIC designer for a project and two
individuals came to an interview, which of the following would your employ? Both
individuals understood and had experience with the development system your team is
using. However; one was able to recognize the resistors and transistors on your
prototype the other could not.

Software technology could be taught in much the same manner as EE programs, but in many
instances the emphasis on the building blocks is missing in CS programs. This is a
shame as it often generates graduates that are well versed in MS Windows API and almost
nothing else. I would imagine that there is a market for people with such focused
education, however they are not a solution to everyones need. If some one is to
make use of an abstraction library, curses or something other, he should at least
understand what is being abstracted.

Thanks
Dave

T.E.Dickey

unread,
Dec 26, 1999, 3:00:00 AM12/26/99
to
David Frantz <wiz...@eznet.net> wrote:

> I would agree that such a person was unemployable if they did not understand current
> microprocessor hardware. However I do believe, mind you its been some time, that at

likewise software: I can recall the general disdain for an engineer I worked
with in the early 80's who insisted on hardcoding escape sequences for tvi920
rather than using termcap. (the consensus then, as now: he was wasting his
time, and probably did not understand software that well ;-)

Dexter Hobbs

unread,
Jan 6, 2000, 3:00:00 AM1/6/00
to
i guess i better throw my 2 cents in the well here.
i wrote the little gotoxy(x,y) function
that generated all the flack.

i agree with david frantz (if i understand him correctly)
its better to start with the specific
and proceed to the general.

would you teach your child gramur
before you teach it to read and write.
the abstract always comes later.
and quite often, i would like to add,
ends up nowhere...
until somebody picks up from the bottom again...8^)

and so we dont get lost in faleral
here is a little screen saver application using
the gotoxy(x,y) function.
hey, i'm a windows programmer.
i had t' bust my head all nite t get this one to run.
lucky i have tomorrow off.............

it seems to run just fine.
and probably would on any linux box in the world.
correct me if i'm wrong.

and BTW where the f... is my linux terminfo source code
(problee buried on the slackware 4.0 CD ROM)

also note that i have made friends with "man terminfo".
and after i get out of the asylum i should be
ready to write to any terminal in the world. ROTFL.

william, the guy who started this nitemare is to blame.
not me...
william, are you there?
can you hear me?
i'm singing in the wires...

//compile with gcc -o abc abc.c

/*comments
1. need to improve program termination, Ctrl C is pretty crude
2. would be nice to add color escape sequences for each letter
*/

#include <stdio.h>
#include <string.h>
#include <stdlib.h>

int gotoxy(int x, int y);

int main(int argc, char *argv[])
{
int x; //the horizontal position of the cursor
int y; //the vertical position of the cursor

int askee; //the ASCII number of the random letter to print

//make sure there is a command line argument
if (argc != 2)
{
printf("Usage: abc 99999 (random number seed)\n");
printf("99999 denotes any integer, positive or negative\n");
printf("Quit this program with Ctrl C\n");
exit(1);
}

//seed the random number generator random()
srand(atoi(argv[1]));

//***** here begins the screen saver ******
system("exec clear");

//infinte loop (quit with control C, lousy exit 8^)
//need to poll a read statement (later project)
while(1)
{
//generate a random letter (upper case or lower case)
GetAnotherLetter:
askee = 64 + 1 + (int)(58.0*rand()/(RAND_MAX+1.0));
if (askee >=91 && askee <= 96)
goto GetAnotherLetter; //just to bug the purists...

x = 1 + (int)(79.0*rand()/(RAND_MAX+1.0));
y = 1 + (int)(25.0*rand()/(RAND_MAX+1.0));

gotoxy(x,y);
printf("%c", askee); //display the random letter at the x,y position
sleep(1); //1 second pause between letters
fflush(stdout); //force immediate display of the letter
}

return 0;
}

int gotoxy(int x, int y)
{
char es[100]; //string variable to hold the escape sequence
char xstr[100]; //strings to hold the x and y coordinates
char ystr[100]; //escape sequences must be built with characters

//convert the screen coordinates to strings
sprintf(xstr, "%d", x);
sprintf(ystr, "%d", y);

//build the escape sequence (vertical move)
es[0]='\0'; //set the string to zero length
strcat(es, "\033[");
strcat(es, ystr);
strcat(es, "d"); //described in man terminfo as vpa=\E[%p1%dd
//vertical position absolute
//horizontal move
strcat(es, "\033[");
strcat(es, xstr);
strcat(es, "G"); //described in man terminfo as hpa=\E[%p1%dG
//horizontal position absolute

//execute the escape sequence
printf("%s", es); //this will move the cursor to x,y

return 0;

}


Grant Edwards

unread,
Jan 6, 2000, 3:00:00 AM1/6/00
to
In article <3874A965...@landho.com>, Dexter Hobbs wrote:

>would you teach your child gramur before you teach it to read
>and write.

Uh, Yes. All of the children with whose lingual development I
am familiar learned grammar before they learned to read and
write. I do not see how you could learn to read/write before
learning the language, since reading and writing is predicated
without understanding the language being notated.

I suppose in theory you could teach somebody enough phonetics
and vocabulary to allow them to transcribe spoken words and
pronounce written words without their understanding the
language, but that's not how it's normally done...

--
Grant Edwards grante Yow! Why was I BORN?
at
visi.com

David T. Blake

unread,
Jan 6, 2000, 3:00:00 AM1/6/00
to
Dexter Hobbs <d...@landho.com> wrote:
> and so we dont get lost in faleral
> here is a little screen saver application using
> the gotoxy(x,y) function.
> hey, i'm a windows programmer.
> i had t' bust my head all nite t get this one to run.
> lucky i have tomorrow off.............


You might could have gotten it working in 10 minutes if
you used termcap or ncurses libraries for cursor control.


--
Dave Blake
dbl...@phy.ucsf.edu

"Those who do not understand Unix are condemned
to reinvent it, poorly."
Spencer

Dexter Hobbs

unread,
Jan 6, 2000, 3:00:00 AM1/6/00
to
"David T. Blake" wrote:

> Dexter Hobbs <d...@landho.com> wrote:
> > and so we dont get lost in faleral
> > here is a little screen saver application using
> > the gotoxy(x,y) function.
> > hey, i'm a windows programmer.
> > i had t' bust my head all nite t get this one to run.
> > lucky i have tomorrow off.............
>
> You might could have gotten it working in 10 minutes if
> you used termcap or ncurses libraries for cursor control.
>

but that wasnt the point, dave.
i wanted to see how the linux terminal works with escape sequences.

i could also have written an internet chat program
in VB last nite but i thot it would be fun to tackle the UNIX terminal.

besides ncurses is nuthin but a huuuuggge workaround
for incompatable terminals.
problee 99% of those terminals should be dropped.
what an overhead just to move the cursor around the screen...
dex

Dexter Hobbs

unread,
Jan 6, 2000, 3:00:00 AM1/6/00
to
Grant Edwards wrote:

right, grant, my error, i was tired.
my comparison was week.
another analogy.
there are 50 different types of kids blocks in the world
lego blocks, etc.

are you gunna teach the kid the theory of how to use
any set of blocks before you teach him to use 1 set of blocks.

learn one thing
learn another thing
then generalize

besides curses throws a big blanket over all the UNIX terminal
monstrosities.
i just wanted to see how bad it is.
and its *bad*.
but not enuf t kill UNIX, i dont think....8^)

would you teach somebody the general theory of relativity
before you taught him to calculate a falling ball with newtonian mechanics?

i don't think so.

i cant think of a perfect analogy but i willllllll......

just drive one ole terminal till y know it good.
then you can graduate to curses AND
yul no igzaktlee whats goin on under the hood.

and then when somebody asks you if there is anything
like a goto(x,y) function in linux
like in borland C for DOS
you can say yes and give him the function.

okay, i dont know curses well.
but i may just skip the "half way house" and go fur the gooey.

but i still maintain that *any* self-respecting programmer
should be able to drive his monitor directly with escape
sequences.

dex


David T. Blake

unread,
Jan 7, 2000, 3:00:00 AM1/7/00
to
Dexter Hobbs <d...@landho.com> wrote:
> > You might could have gotten it working in 10 minutes if
> > you used termcap or ncurses libraries for cursor control.
> >
>
> but that wasnt the point, dave.
> i wanted to see how the linux terminal works with escape sequences.

> besides ncurses is nuthin but a huuuuggge workaround
> for incompatable terminals.

Ncurses is a good solution to a LARGE problem.

Not only do lots of terminals exist, but their escape
sequences contain LOTS of little inconsistencies.

Even the same terminal type on different Unices are
incompatible with anything less than ncurses. Termcap
is nice and compact, but fails with that proviso - different
escape sequences for the same terminal type under different
Unices.

There are other ways around it too - you just didn't find one,
or seem to bother trying to figure out why ESR would bother with
such a monstrosity. Virtually all cross-platform serious terminal
programs are using slang or ncurses/curses.

--
Dave Blake
dbl...@phy.ucsf.edu

Dexter Hobbs

unread,
Jan 7, 2000, 3:00:00 AM1/7/00