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.
David Frantz
> 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
> 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
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
> 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
> 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
> 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
> 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
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
>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
> 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
> 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
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
> > 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
it seems to me, dave, that curses (and ncurses)
are just a graveyard for a bunch of dead monitors.
25 years worth?
how many of those monitor types are living today?
and MS only has to support *one* type of terminal.
time to clear the decks man and let the dead care for the dead.
it reminds me of a dog with a string of tin cans
tied to his tail.
i have also seen first hand what a mess the
UNIX terminal situation is.
i don't wanna hurt anybodys feelings here.
but its the truth.
what is preventing the unix camp from dropping
VT52 and all the other defunct terminals anyway?
they are dead weight, man....8^(
what i'm trying to do is port my expertise with the terminal
from DOS (and windows) to unix.
i wrote this little screen saver years ago in DOS
using ANSI escape sequences.
and i have learned a hell of a lot at about the unix
terminal in the past week.
writing these low level escape sequences.
i think i could write an editor using what i know now.
i tempted. there are so many bad ones out there....
anyway, i hope you like the tornados.
//compile with gcc -o tornados tornados.c
/*comments
1. need to improve program termination, Ctrl C is pretty crude
easy to do with fcntl (#include <fcntl.h>)
*/
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
int gotoxy(int x, int y); //the notorious escape sequence artist
int main(int argc, char *argv[])
{
int x1,x2,x3; //the horizontal position of each tornado
int askee; //the ASCII number of the random letter to print
int delay;
int MyDelay; //the delay from the command line argument
int i,j,k; //used for calculating the new position of the tornado
char es[100]; //string to hold the escape sequences for color
x1=19; //start the 3 tornados
x2=39;
x3=59;
//make sure there is a command line argument
if (argc != 2)
{
system("exec clear");
printf("\nUsage: tornados 99999\n");
printf("99999 denotes any integer, positive or negative\n");
printf("this integer is used in delay loops\n");
printf("tornados 1500000 looks good on my 400mh PII\n");
printf("you can pause the program with Ctrl S\n");
printf("and resume with Ctrl Q\n\n");
printf("Quit this program with Ctrl C\n\n");
exit(1);
}
//convert the delay to an integer
MyDelay = 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 move for the first tornado
i = 1 + (int)(7.0*rand()/(RAND_MAX+1.0));
i=i-4; // i will be from -3 to 3
if (x1+i>=1 && x1+i<=79)
x1=x1+i;
//generate a move for the second tornado
j = 1 + (int)(7.0*rand()/(RAND_MAX+1.0));
j=j-4;
if (x2+j>=1 && x2+j<=79)
x2=x2+j;
//generate a move for the third tornado
k = 1 + (int)(7.0*rand()/(RAND_MAX+1.0));
k=k-4;
if (x3+k>=1 && x3+k<=79)
x3=x3+k;
//add a new R to the bottom of the red tornado
gotoxy(x1,25);
es[0]='\0';
strcat(es, "\033[1;31;40m");
strcat(es,"R");
printf("%s",es);
//add a new W to the bottom of the white tornado
gotoxy(x2,25);
es[0]='\0';
strcat(es,"\033[1;37;40m");
strcat(es, "W");
printf("%s", es);
//add a new B to the bottom of the blue tornado
gotoxy(x3,25);
es[0]='\0';
strcat(es,"\033[1;34;40m");
strcat(es, "B");
printf("%s", es);
//turn the cursor dark grey so it doesnt show up
//should turn it black (don't know how yet)
es[0]='\0';
strcat(es,"\033[1;30;40m");
printf("%s", es);
//scroll the screen 1 line
gotoxy(1,25);
printf("%s","\n");
//force the monitor to display the new letters immediately
fflush(stdout);
for(delay=0; delay<MyDelay; delay++);
T.E.Dickey
> 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.
which incidentally proves the point that other people are making
(your code won't work for a vt100).
> strcat(es, "d"); //described in man terminfo as vpa=\E[%p1%dd
> //vertical position absolute
(vpa and hpa, though described in ISO 6429, are not implemented for vt100,
nor iirc, for vt220)
David T. Blake
> it seems to me, dave, that curses (and ncurses)
> are just a graveyard for a bunch of dead monitors.
> 25 years worth?
> how many of those monitor types are living today?
For example, Sun xterm != OSF xterm != linux xterm.
You'd need REWRITTEN source code for each one, or
you could write a program once using [n]curses.
--
Dave Blake
dbl...@phy.ucsf.edu
Robert Krawitz
> it seems to me, dave, that curses (and ncurses)
> are just a graveyard for a bunch of dead monitors.
> 25 years worth?
> how many of those monitor types are living today?
Significantly greater than one. Beyond that point, who cares? Write
it once with ncurses and then let someone write the terminal
description, and your program will just work.
> and MS only has to support *one* type of terminal.
For DOS? Well sure, Microsoft tied itself to the *GA graphics adapter
on the PC. How many different platforms does DOS run on? How much
effort does each graphics card manufacturer have to go through to
ensure that their card supports VGA? UNIX isn't DOS.
How many different video cards are there? Does Microsoft rewrite Word
for each different video card, or does Windows just use the GDI which
interfaces to a manufacturer-supplied driver specific to the
appropriate card?
If you learn to use ncurses, you'll also only need to support one type
of terminal. The others will come for free.
> i have also seen first hand what a mess the
> UNIX terminal situation is.
> i don't wanna hurt anybodys feelings here.
> but its the truth.
What's such a mess? That there's a diversity? Is it any worse than
the whole mess of sound cards and graphics cards on the PC? Or are
there good reasons for the diversity? Or do you have something else
in mind?
> what is preventing the unix camp from dropping
> VT52 and all the other defunct terminals anyway?
> they are dead weight, man....8^(
1) There are still a few of them around, and there's no good reason to
force their users to throw them away. Unlike MS, Unix folks don't
believe in obsoleting old hardware for some minor conveniences.
> what i'm trying to do is port my expertise with the terminal
> from DOS (and windows) to unix.
Fine, so learn how to do things the Unix way *before* bashing it
rather than calling it a "mess" because you're too lazy to learn how
to do it in a way that actually will work on most of the terminals
that are out there.
> i think i could write an editor using what i know now.
> i tempted. there are so many bad ones out there....
Go right ahead, and then see what happens when someone actually has to
use it on a different kind of terminal.
> anyway, i hope you like the tornados.
>
> //compile with gcc -o tornados tornados.c
>
> /*comments
> 1. need to improve program termination, Ctrl C is pretty crude
> easy to do with fcntl (#include <fcntl.h>)
> */
I think that that about says it as far as your interest in actually
dealing with Unix.
> #include <stdio.h>
> #include <string.h>
> #include <stdlib.h>
>
> int gotoxy(int x, int y); //the notorious escape sequence artist
>
> int main(int argc, char *argv[])
> {
> int x1,x2,x3; //the horizontal position of each tornado
>
> int askee; //the ASCII number of the random letter to print
> int delay;
> int MyDelay; //the delay from the command line argument
> int i,j,k; //used for calculating the new position of the tornado
>
> char es[100]; //string to hold the escape sequences for color
>
> x1=19; //start the 3 tornados
> x2=39;
> x3=59;
>
> //make sure there is a command line argument
> if (argc != 2)
> {
> system("exec clear");
Oh, really? Why didn't you use the escape sequences? And why is that
"exec" in there?
Likewise, that about says something.
> es[0]='\0';
> strcat(es,"\033[1;30;40m");
> printf("%s", es);
>
> //scroll the screen 1 line
> gotoxy(1,25);
> printf("%s","\n");
>
> //force the monitor to display the new letters immediately
> fflush(stdout);
> for(delay=0; delay<MyDelay; delay++);
Uh, and what happens (both to this, and to the processes running in
the background) if the system is heavily loaded? Why didn't you read
the man page on select(2)? That would solve both your problem with a
more graceful exit and this silly delay loop (which, mind you, a smart
enough compiler would probably entirely optimize out).
David Frantz
> 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...
Most children are started out with a little vocabulary and phonetics - and
now that I think about it a lot of baby talk. Sure grammer is part of
that learning process but it is impossible to speak with good grammer if
you do not have a vocabulary to start with. After all why do we teach
children thier ABC's and 123's if not to provide a base to learn about
language. But; even before that a child is tught nothing but words,
usually that first one being daddy. Once a vocabulary is developed the
child will begin to develop the skills to put the words into useful
sentences, assuming he is raised around people with the ability to do that
him self.
Even in schools the emphasis in the first years are put on the development
of basic skills before much effort is placed on the specifics of
grammer. So one learns to count to ten before one counts to a hundred,
and A - Z are learn before things like verb and noun relationships.
Remember the GREEN ham!
Thanks
dave
David Frantz
> In <3875C045...@landho.com> Dexter Hobbs <d...@landho.com> writes:
> >what is preventing the unix camp from dropping
> >VT52 and all the other defunct terminals anyway?
> >they are dead weight, man....8^(
>
> Once you've got a terminal-independent library driven by a terminal
> database, adding extra terminals to the database is an insignificant
> overhead. Outputing escape codes directly may be acceptable if you
> only ever use one terminal type and don't mind that people on different
> terminal types won't be able to use your program. I regularly use
> the Linux console, Sun's console, xterm, cmdtool, kvt and Windoze
> telnet - are you seriously suggesting separate copies of the editor
> etc. for each of these?
>
> Michael
> --
> Quidquid latine dictum sit, altum viditur.
Mike
I wouldn't suggest seperate copies of your editor at all. I would
suggest that you explain to your vendors that they either support the ANSI
standard or find someone else to sell thier machines to. There is no
reason to have a database of xxx number of terminals on a machine
especially when the vast majority of terminals used today are
emulations. This also does not mean that the console can not have
extended functions, just that it support the ANSI ones correctly.
If a terminal or emulation can't support ANSI correctly then get rid of it
and explain to the supplier why it is not around any more. Yes there
will be cases of bugs but if your supplier can't commit to supporting ANSI
correctly then whats the point of dealling with them. I'm sure at this
point even SUN may take seriously the threat of standards based
devices. By the way I think this is a technically possible goal, and
a valid one to pursue. It truely appears that the UNIX community is a
little weaked kneed when it comes time to demand a basic standard such as
console I/O. There is absolutely no reason why a terminal or console
can not be supplied with correct ANSI emulation. I say this in the
context of present day, when we have compatability libararies for Windows
and a host of other GUI's all of them much more complicated than a
terminal or console.
Sure there may be instance were the use of ncurses like libraries make
sense, but that doesn;t mean we should suggest to an author that ncurses
is the way to go so everybody and thier dog can use his program. It
would be better to say look at ANSI sequences or a library supporting them
(something UNIX needs) for reduced complexity, or slang or ncurses if he
really thinks he needs to support every type of terminal it is possible to
run into. If you want universal acceptance go with a graphical X
application.
Just think how easy life would be if you could write the simple programs
and utilities everyone make use of to run on one basic terminal.
Imagine never having to resolves glitches on a new terminal from XYZ
corporation due to the ncurses translation not being quite right.
Imagine a small library of a few kbytes that is well debugged and written
to implement a standard not a collection. Imagine being able to compete
with MS because we do have a standard for the most basic of system
services, a terminal, and that software written for this console works
across a broad spectrum of hardware. While UNIX/Linux will never
achieve binary compatablity source compatability shouldn't be a problem.
Thanks
Dave
David Frantz
> Dexter Hobbs <d...@landho.com> wrote:
> > it seems to me, dave, that curses (and ncurses)
> > are just a graveyard for a bunch of dead monitors.
> > 25 years worth?
> > how many of those monitor types are living today?
>
> For example, Sun xterm != OSF xterm != linux xterm.
>
> You'd need REWRITTEN source code for each one, or
> you could write a program once using [n]curses.
>
> --
> Dave Blake
> dbl...@phy.ucsf.edu
You could also write your program once, linked with an ANSI
library, find out which emulations don't work correctly and
then send bug reports back to the suppliers. If there is
an unwillingness to support the standard then mayby the
supplier has some problems it needs to resolve
internally. In any event one should not continue to
support broken software.
One could only imagine what the computer world would be like
if the hardware engineers took the same attitude to
designing hardware to spec that software engineers do.
Could things like PCI, USB, SDRAM and SVGA video have been
possible. I think not. Maybe what is need is UL
program for software, a little sticker that gets slaped on
your software that says yes you did it correctly your
package is compliant with xyz standard. At least C
compiler writers try to write to a standard, why can't we
expect the same for terminal emulations?
dave
David Frantz
> Dexter Hobbs <d...@landho.com> writes:
>
> > it seems to me, dave, that curses (and ncurses)
> > are just a graveyard for a bunch of dead monitors.
> > 25 years worth?
> > how many of those monitor types are living today?
>
> Significantly greater than one. Beyond that point, who cares? Write
> it once with ncurses and then let someone write the terminal
> description, and your program will just work.
Why bother to write a terminal description when it would be just as easy
to make sure the hardware and software is compliant with a recognized
standard. Software engineering has to be the only engineering field
were fixing up problems after the fact is looked upon in a positive
light. Your program will work just as well if the terminal is
compliant with ANSI standards.
>
>
> > and MS only has to support *one* type of terminal.
>
> For DOS? Well sure, Microsoft tied itself to the *GA graphics adapter
> on the PC. How many different platforms does DOS run on? How much
> effort does each graphics card manufacturer have to go through to
> ensure that their card supports VGA? UNIX isn't DOS.
>
> How many different video cards are there? Does Microsoft rewrite Word
> for each different video card, or does Windows just use the GDI which
> interfaces to a manufacturer-supplied driver specific to the
> appropriate card?
A terminal emulation and a library to communicate with that are the same
as GDI and hardware driver mentioned above. The question is why
support more hardware than you need. You certainly would not try to
load several video drivers on your machine at the same time, why mess
around with ncurses which amounts to the same thing.
>
>
> If you learn to use ncurses, you'll also only need to support one type
> of terminal. The others will come for free.
But you just mentioned above that all these new terminals require a
terminal description file. So which is it free or a major development
headache. This whole issue of terminals and thier incompatabilites
is another in a long list of "problems" that people use as arguments to
prevent the adoption of UNIX in business. I'm not saying that it is a
good reason but it is correct.
>
>
> > i have also seen first hand what a mess the
> > UNIX terminal situation is.
> > i don't wanna hurt anybodys feelings here.
> > but its the truth.
>
> What's such a mess? That there's a diversity? Is it any worse than
> the whole mess of sound cards and graphics cards on the PC? Or are
> there good reasons for the diversity? Or do you have something else
> in mind?
I well may be biased here prefering graphical environments, but why would
you not want a common basic standard for console communications. ANSI
may not be perfect but I would prefer to see code written for that
standard then to worry about supporting hundreds of terminal types to do
something as basic as providing a console. Really; diversity is for
girl friends. not for such a low level piece of a system such as a
console.
>
>
> > what is preventing the unix camp from dropping
> > VT52 and all the other defunct terminals anyway?
> > they are dead weight, man....8^(
>
> 1) There are still a few of them around, and there's no good reason to
> force their users to throw them away. Unlike MS, Unix folks don't
> believe in obsoleting old hardware for some minor conveniences.
They may be around but I would be surprised to find that they are being
supported with tax payer dollars. The reason they are around
probally has more to do with the difficulty in replacing them then
anything else. You could drive across a good portion of this country
an not find a VT52 in a business situation. Unless of course that
terminal is tied to a UNIX system, at which point the effort to fix up
the terminal I/O makes replacement to expensive to consider.
>
>
> > what i'm trying to do is port my expertise with the terminal
> > from DOS (and windows) to unix.
>
> Fine, so learn how to do things the Unix way *before* bashing it
> rather than calling it a "mess" because you're too lazy to learn how
> to do it in a way that actually will work on most of the terminals
> that are out there.
Why! Why! Why would any one in there right mind try to support every
terminal out there. I have never understood this concept. It
makes about as much sense as building a house with a different type of
electrical power outlet in every room, just so everyone out there is
considered. No one in thier right mind would do this with a house,
they would use a standard product. ANSI escape sequences are a
standard, if terminal doesn't support it then keep it out of the house.
>
>
> > i think i could write an editor using what i know now.
> > i tempted. there are so many bad ones out there....
>
> Go right ahead, and then see what happens when someone actually has to
> use it on a different kind of terminal.
If he was wise he would suggest to the user to go out an get a compliant
terminal!
What does it say? That we don't have a useful library. That he
doesn't know how. Or that the terminal doesn't work correctly.
All of these are possible, along with others, which says something
also. Each of these has a solution that can be solved with compliant
hardware and software without the need to resort to ncurses or anything
else.
>
>
> > es[0]='\0';
> > strcat(es,"\033[1;30;40m");
> > printf("%s", es);
> >
> > //scroll the screen 1 line
> > gotoxy(1,25);
> > printf("%s","\n");
> >
> > //force the monitor to display the new letters immediately
> > fflush(stdout);
> > for(delay=0; delay<MyDelay; delay++);
>
> Uh, and what happens (both to this, and to the processes running in
> the background) if the system is heavily loaded? Why didn't you read
> the man page on select(2)? That would solve both your problem with a
> more graceful exit and this silly delay loop (which, mind you, a smart
> enough compiler would probably entirely optimize out).
>
> --
> 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
Thanks
dave
Dexter Hobbs
dickey, the vt users will just hafta forego
the beauty of the tornados.
at least until i know more about the beastly termios.
and *compiled* at that.
with tic.
i cant even find the termios source code for the linux terminal.
what, me worry?
i have never liked #ifdef's
i write custom software.
i don't hafta make the program run on every box in the world.
i know my hardware.
i write the program to run on it.
not to run on your machine.
i don't know your machine.
however, if yur running linux "tornados" is problee gunna run...
i'm sorry for the vt users.
look, why dont we all just switch to ANSI, ASAP.
BTW: david frantz is my hero...
PS: are even the old teletypes included in curses?
i saw one in the museum the other day.
somebody might wanna put it online...
we better support it, dickey.
Dexter Hobbs
> Uh, and what happens (both to this, and to the processes running in
> the background) if the system is heavily loaded? Why didn't you read
> the man page on select(2)? That would solve both your problem with a
> more graceful exit and this silly delay loop (which, mind you, a smart
> enough compiler would probably entirely optimize out).
>
> --
> 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
krawitz.
i chopped off the top of the letter as it was getting too long.
i have attempted to answer your complaints.
your comments, as always, are fully appreciated.
1a. system("exec clear");
i read that including "exec" in a system call
would insure that the shell process created
would die on its own and not be left layin around.
no, i cant remember igzaktlee where i read it.
1b. why didn't i use escape sequences to clear the screen?
bekuz the system call is much easier.
too bad there is no system call for goto(x,y)
then this exchange of broadsides would not have been necessary.
2. "(should turn it black, dont know how yet)"
"Likewise, that about says something."
kool, man, what does it say?
i tell the truth and you poke me in the eye.
what kinda teacher are you?
i'm just glad i didnt go to MIT after all.
tell me krawitz: what does it say?
huh?
i just wanna know.
kuz i dont have a clue whatchur talkin about...
3. i have added a graceful exit to the program
using fcntl.
i hope it suits you.
if not, please say why.
4. sorry about tying up the processor.
but i would never run this monstosity
on a machine with a work load.
just as i never run a screen saver on the servers at work.
dum de dum dum, dummmmmm!
but i would be eternally grateful for 2 minutes of your time.
tell me more about select(2).
(yes, i promise to look it up on my own, too)
5. your implication that i am not really serious about unix
is unfounded.
unix appears to be the sole survior of the the early OS wars.
sure some of the mainframe OSs survive.
but nobodys gunna port 'm anywhere...
i say "may the best software and hardware win"
i am a NOR (no organized religion)
so i cannot be "converted to unix"
what works, works.\
and just running netscape on my PII/400
i notice that the text scrolls more slowly than under NT4.
all i'm tryin t say is that this is a horse race.
NT or UNIX?
i dont know.
if the truth bugs you, then go to church...
the new tornados.c follows (with graceful exit using fcntl.h)
all comments, complaints and applause are freely accepted
with no strings attached 8^)
//compile with gcc -o tornados tornados.c
/* program comments
this is a port of an DOS program i wrote years ago
i wrote it to explore the UNIX terminal
(and man was i appalled at the complexity)
UNIX awake.
it is time to drop all the excess baggage
you are luggin too many dead terminals
*/
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <termio.h>
#include <fcntl.h>
int gotoxy(int x, int y);
int main(int argc, char *argv[])
{
int x1,x2,x3; //the horizontal position of each tornado
int askee; //the ASCII number of the random letter to print
int delay;
int MyDelay; //the converted delay from the command line argument
int i,j,k; //for calc_ing the movements of the tornados
char es[100]; //string to hold the escape sequences for color
//variables for fcntl
//resetting fnctl allows polling the read statement
//so it wont stop the program and wait for input
struct termio save, term;
char in; //to hold a character from stdin (the keyboard!!!)
int nchar; //number of characters read
int savefcntl;
//make sure there is a command line argument
if (argc != 2)
{
system("exec clear");
printf("\nUsage: tornados 99999\n");
printf("99999 denotes any integer, positive or negative.\n\n");
printf("This integer is used for delay loops.\n");
printf("tornados 1500000\n");
printf("looks good on my 400mh PII.\n\n");
printf("You can pause the program with Ctrl S\n");
printf("and resume with Ctrl Q.\n\n");
printf("Press any key to quit.\n\n");
exit(1);
}
//convert the command line argument (delay) to an integer
MyDelay = atoi(argv[1]);
//NOW SET UP THE TERMINAL WITH NEW SETTINGS FOR POLLING
//turn on O_NDELAY to allow polling
savefcntl = fcntl(0,F_GETFL, 0);
fcntl(0,F_SETFL, savefcntl | O_NDELAY);
if (ioctl(0,TCGETA, &term) == -1 )
{
fprintf(stderr, "standard input not a tty\n");
exit(1);
}
//save old tty state
save = term;
//turn off canonical processing (ie: turn on raw mode)
term.c_lflag = term.c_lflag & ~ICANON;
//set MIN to 1 and TIME to 0
term.c_cc[VMIN]=1;
term.c_cc[VTIME]=0;
//set new terminal state
ioctl(0, TCSETA, &term);
//***** here begins the screen saver ******
system("exec clear");
x1=19; //start positions for the tornados
x2=39;
x3=59;
//infinite loop to drive the tornados
while(1)
{
//poll a read statement to see if the user wants to quit
in = '\0';
nchar = read(0,&in,1); //read will now return with no wait
//bekuz the O_NDELAY (no delay)
//is set in the termio
if (in != '\0') //get out if the user presses a key
{
//reset the old terminal
ioctl(0,TCSETA, &save);
fcntl(0,F_SETFL, savefcntl);
//make sure the cursor is white on exit
es[0]='\0';
strcat(es,"\033[0;37;40m"); //0=normal intensity
printf("%s", es);
printf("\b%c\n", ' ');
return 0;
}
//calc a move for the red tornado
i = 1 + (int)(7.0*rand()/(RAND_MAX+1.0));
i=i-4; // i will be from -3 to 3
if (x1+i>=1 && x1+i<=79)
x1=x1+i;
//calc a move for the white tornado
j = 1 + (int)(7.0*rand()/(RAND_MAX+1.0));
j=j-4;
if (x2+j>=1 && x2+j<=79)
x2=x2+j;
//calc a move for the blue tornado
k = 1 + (int)(7.0*rand()/(RAND_MAX+1.0));
k=k-4;
if (x3+k>=1 && x3+k<=79)
x3=x3+k;
//add an R to the bottom of the red tornado
gotoxy(x1,25);
es[0]='\0';
strcat(es, "\033[1;31;40m");
strcat(es,"R");
printf("%s",es);
//add a W to the bottom of the white tornado
gotoxy(x2,25);
es[0]='\0';
strcat(es,"\033[1;37;40m");
strcat(es, "W");
printf("%s", es);
//add a B to the bottom of the blue tornado
gotoxy(x3,25);
es[0]='\0';
strcat(es,"\033[1;34;40m");
strcat(es, "B");
printf("%s", es);
//turn the cursor dark grey
//should be black but dont know how to do it yet
//i'm workin on it, krawitz 8^)
es[0]='\0';
strcat(es,"\033[1;30;40m");
printf("%s", es);
//scroll the screen 1 line
gotoxy(1,25);
printf("%s","\n");
//force the monitor to display the letters immediately
fflush(stdout);
for(delay=0; delay<MyDelay; delay++); //okay krawitz, yur on,
//how do i use select(2)
//to avoid the tight loop?
}
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]; // kuz escape sequences must be built with chars
T.E.Dickey
> If a terminal or emulation can't support ANSI correctly then get rid of it
There are a number of terminals which implement ANSI correctly, but are
incompatible with each other.
(btw, ANSI doesn't cover the area of function keys, either ;-)
David T. Blake
> I wouldn't suggest seperate copies of your editor at all. I
> would suggest that you explain to your vendors that they either
> support the ANSI standard or find someone else to sell thier
> machines to. There is no reason to have a database of xxx number
> of terminals on a machine especially when the vast majority of
> terminals used today are emulations. This also does not mean that
> the console can not have extended functions, just that it support
> the ANSI ones correctly.
Right.
Instead of just writing a program that works across platforms,
you should go and whine to Compaq like a Windoze user that
their xterm doesn't support ANSI color sequences. And they are
REALLY likely to listen to you. They have enough problems trying
to make libc5 work.
You are in NO position to make demands of hardware manufacturers.
There are many flavors of Unix, many terminals, and many
terminal emulations. If you write an editor that doesn't work
for people, they will complain to YOU, not to their hardware/OS
vendor/supplier.
A good software engineer writes programs that work, plain and
simple. A bad one works in Redmond.
--
Dave Blake
dbl...@phy.ucsf.edu
Robert Krawitz
> 1a. system("exec clear");
> i read that including "exec" in a system call
> would insure that the shell process created
> would die on its own and not be left layin around.
> no, i cant remember igzaktlee where i read it.
That's true (you answered the question correctly).
> 1b. why didn't i use escape sequences to clear the screen?
> bekuz the system call is much easier.
> too bad there is no system call for goto(x,y)
> then this exchange of broadsides would not have been necessary.
Ncurses *does* provide facilities like this?
> 4. sorry about tying up the processor.
> but i would never run this monstosity
> on a machine with a work load.
> just as i never run a screen saver on the servers at work.
> dum de dum dum, dummmmmm!
If it's a Unix machine, you don't know if there's a background
workload taking place. For that matter, even Windows supports
background processing.
> but i would be eternally grateful for 2 minutes of your time.
> tell me more about select(2).
> (yes, i promise to look it up on my own, too)
Select lets you poll file descriptors for I/O with a timeout. Beyond
that, I'll let you do the legwork.
> 5. your implication that i am not really serious about unix
> is unfounded.
If you really are serious about Unix, I suggest that you learn how
things are best done in the Unix world. Your original question was
reasonable, but I think you should have listened to the large number
of people who suggested that you study ncurses, which is the standard
way of accomplishing what you're trying to do.
Robert Krawitz
> Robert Krawitz wrote:
> Why bother to write a terminal description when it would be just as easy
> to make sure the hardware and software is compliant with a recognized
> standard. Software engineering has to be the only engineering field
> were fixing up problems after the fact is looked upon in a positive
> light. Your program will work just as well if the terminal is
> compliant with ANSI standards.
Fine, you want your software compliant with a recognized standard?
Write it to ncurses. THAT is a recognized standard. Suppose the
terminal isn't ANSI-compliant? It's OK for your program not to work?
> A terminal emulation and a library to communicate with that are the same
> as GDI and hardware driver mentioned above. The question is why
> support more hardware than you need. You certainly would not try to
> load several video drivers on your machine at the same time, why mess
> around with ncurses which amounts to the same thing.
Sure I would, if I had multiple graphics cards connected
simultaneously. And a program has to be prepared to work with many
different video cards anyway, since it doesn't know what will be
loaded on a given machine.
> But you just mentioned above that all these new terminals require a
> terminal description file. So which is it free or a major development
> headache. This whole issue of terminals and thier incompatabilites
> is another in a long list of "problems" that people use as arguments to
> prevent the adoption of UNIX in business. I'm not saying that it is a
> good reason but it is correct.
But it's a lot easier to write the terminal description file than to
rewrite the application, and someone's probably written it already.
In any case, unless you come up with a non-standard terminal type of
your own, writing the terminal description isn't your responsibility.
> I well may be biased here prefering graphical environments, but why would
> you not want a common basic standard for console communications.
Personally I preferred the good old days of having a printer hooked up
to the console, but that's another story.
> They may be around but I would be surprised to find that they are being
> supported with tax payer dollars. The reason they are around
> probally has more to do with the difficulty in replacing them then
> anything else. You could drive across a good portion of this country
> an not find a VT52 in a business situation. Unless of course that
> terminal is tied to a UNIX system, at which point the effort to fix up
> the terminal I/O makes replacement to expensive to consider.
And we're talking about Linux/UNIX systems? Right!
> Why! Why! Why would any one in there right mind try to support every
> terminal out there. I have never understood this concept. It
> makes about as much sense as building a house with a different type of
> electrical power outlet in every room, just so everyone out there is
> considered. No one in thier right mind would do this with a house,
> they would use a standard product. ANSI escape sequences are a
> standard, if terminal doesn't support it then keep it out of the house.
Ncurses is standard too. We're not talking about DOS, we're talking
about Unix, and ncurses *IS* a Unix standard! Why is an ANSI terminal
preferable to ncurses here?
> > Go right ahead, and then see what happens when someone actually has to
> > use it on a different kind of terminal.
>
> If he was wise he would suggest to the user to go out an get a compliant
> terminal!
So it's the user's job to spend money on the new terminal, not the
programmer's job to make the right thing happen? What happened to the
customer's always right?
Robert Krawitz
> I wouldn't suggest seperate copies of your editor at all. I would
> suggest that you explain to your vendors that they either support the ANSI
> standard or find someone else to sell thier machines to. There is no
> reason to have a database of xxx number of terminals on a machine
> especially when the vast majority of terminals used today are
> emulations. This also does not mean that the console can not have
> extended functions, just that it support the ANSI ones correctly.
If I have a terminal description for an ANSI terminal, and my program
uses the proper system interface, then my terminal's ANSI compliant.
> If a terminal or emulation can't support ANSI correctly then get rid of it
> and explain to the supplier why it is not around any more. Yes there
> will be cases of bugs but if your supplier can't commit to supporting ANSI
> correctly then whats the point of dealling with them. I'm sure at this
> point even SUN may take seriously the threat of standards based
> devices. By the way I think this is a technically possible goal, and
> a valid one to pursue. It truely appears that the UNIX community is a
> little weaked kneed when it comes time to demand a basic standard such as
> console I/O.
The "basic standard" for console I/O is a simple line-oriented dumb
terminal or printer. We're not talking about basic console I/O here;
we're talking about enhanced capabilities such as inverse video/color,
cursor positioning, and so forth.
As for a basic standard for that, there IS one: it's called ncurses.
The fact that it's a high level API rather than a sequence of
characters is irrelevant.
Imagine being able to compete
> with MS because we do have a standard for the most basic of system
> services, a terminal, and that software written for this console works
> across a broad spectrum of hardware. While UNIX/Linux will never
> achieve binary compatablity source compatability shouldn't be a problem.
But we do have such a standard already! How much more clear do we
have to be about this?
T.E.Dickey
> dickey, the vt users will just hafta forego
you can't have it both ways: in a previous posting you're equating vt100
and ANSI, and in this one you prove that you don't know the difference.
John E. Davis
wrote:
[...]
>int gotoxy(int x, int y); //the notorious escape sequence artist
This was implemented using 26 lines of code involving: 6 uses of
strcat, 2 uses of sprintf, 1 call to printf, and 3 local variables
_instead_ of the single line:
fprintf (stdout, "\033[%dd\033[%dG", y, x);
> system("exec clear");
[...]
> for(delay=0; delay<MyDelay; delay++);
Ouch!
>i think i could write an editor using what i know now.
>i tempted. there are so many bad ones out there....
Yeah, one more will not hurt.
David T. Blake
> krawitz.
> i chopped off the top of the letter as it was getting too long.
> the new tornados.c follows (with graceful exit using fcntl.h)
> all comments, complaints and applause are freely accepted with no
> strings attached 8^)
Suggestion.
Download the source to an ncurses based editor and look at
how they move the cursor. On a linux system see /usr/bin/vim
Or, download the source to a termcap based editor and look at
it. For example, /bin/vi. Or one that I like to hack, MicroEmacs
http://www.keck.ucsf.edu/~dblake/programs/em-4.0.15db.tar.gz
(Warning - it ain't pretty, and it ain't for production use. But
it does tend to get the job done for which it was designed)
Your attempts are getting uglier without addressing the largest
problems. ie: Using ioctls to control the terminal state and
escape sequences to alter the cursor position/color. On windows
one attempts to drive programs to lower and lower levels to avoid
problems. On Unix, do the opposite. Start thinking Unix.
--
Dave Blake
dbl...@phy.ucsf.edu
David Frantz
> David Frantz <wiz...@eznet.net> wrote:
>
> > I wouldn't suggest seperate copies of your editor at all. I
> > would suggest that you explain to your vendors that they either
> > support the ANSI standard or find someone else to sell thier
> > machines to. There is no reason to have a database of xxx number
> > of terminals on a machine especially when the vast majority of
> > terminals used today are emulations. This also does not mean that
> > the console can not have extended functions, just that it support
> > the ANSI ones correctly.
>
> Right.
>
> Instead of just writing a program that works across platforms,
> you should go and whine to Compaq like a Windoze user that
> their xterm doesn't support ANSI color sequences. And they are
> REALLY likely to listen to you. They have enough problems trying
> to make libc5 work.
If they can't get thier software to work that thier problem. If
it doesn't work then it is up to the user to point out the issue.
>
>
> You are in NO position to make demands of hardware manufacturers.
> There are many flavors of Unix, many terminals, and many
> terminal emulations. If you write an editor that doesn't work
> for people, they will complain to YOU, not to their hardware/OS
> vendor/supplier.
Lets see if you by a car and it doesn't work as advertised, most
likely you would make demands of the manufacture or in
representative. If you couldn't make head way on your own, you
might even get legal support. Likewise there is no reason not to
expect that software work as advertised. The reality is every
customer is in the position to make demand of a hardware manufacture,
if they can't get it right then they should suffer. Funny that you
should mention Compag, as they are suffering right now for many screw
ups.
With all of the magic of ncurses and the other laibraies out there how
many editors support more than a handful of terminals correctly?
"No position to make demands of a hardware manufacture" I am the
customer; I will make demands and I will search for products that best
meets those demands. I sure as hell will not play dead, nor mess
around with a vendor that has a mainframe mentality from the 60's.
We are entering the age of generic PC hardware which are pervassive,
we have no need for vendors that deliberately make the products
uncompatiable or can not support simple standards.
>
>
> A good software engineer writes programs that work, plain and
> simple. A bad one works in Redmond.
Bad programmers roll over a play dead when thier suppliers try to hand
off junk software to them. Sooner or later the software industry
is going to be subject to a big back lash over the performance of the
people in the industry. It is not unreasonable to expect that
software work correctly, just as one expects a bridge to stay up or a
train to stay on the tracks.
Dave
>
>
> --
> Dave Blake
> dbl...@phy.ucsf.edu
David Frantz
> David Frantz <wiz...@eznet.net> writes:
>
> > I wouldn't suggest seperate copies of your editor at all. I would
> > suggest that you explain to your vendors that they either support the ANSI
> > standard or find someone else to sell thier machines to. There is no
> > reason to have a database of xxx number of terminals on a machine
> > especially when the vast majority of terminals used today are
> > emulations. This also does not mean that the console can not have
> > extended functions, just that it support the ANSI ones correctly.
>
I don't consider a library that tries to interface to dozens and dozens of
terminals to be a standard of any sort. It is a library that will allow some
success with terminal access across a wide range of terminals. It is not a
standard for character based terminal I/O, that can be a defacto standard such
as VT100 or something like ANSI. Ncurses, slang and whatever else, are not
standards at all they are attempts to interface to a large number different
terminal devices. While there may have been a reason for this sort of
kludge in the past, it is misguided to continue to support these packages and
not consider the alternatives.
The alternative is to code to a standard. There is no reason not to expect
the hardware and software suppliers to converge on ANSI or for that matter
whatever the industry can dream up for a replacement.
Dave
David Frantz
> David Frantz <wiz...@eznet.net> writes:
>
> > Robert Krawitz wrote:
>
> > Why bother to write a terminal description when it would be just as easy
> > to make sure the hardware and software is compliant with a recognized
> > standard. Software engineering has to be the only engineering field
> > were fixing up problems after the fact is looked upon in a positive
> > light. Your program will work just as well if the terminal is
> > compliant with ANSI standards.
>
> Fine, you want your software compliant with a recognized standard?
> Write it to ncurses. THAT is a recognized standard. Suppose the
> terminal isn't ANSI-compliant? It's OK for your program not to work?
>
> > A terminal emulation and a library to communicate with that are the same
> > as GDI and hardware driver mentioned above. The question is why
> > support more hardware than you need. You certainly would not try to
> > load several video drivers on your machine at the same time, why mess
> > around with ncurses which amounts to the same thing.
>
> Sure I would, if I had multiple graphics cards connected
> simultaneously. And a program has to be prepared to work with many
> different video cards anyway, since it doesn't know what will be
> loaded on a given machine.
>
> > But you just mentioned above that all these new terminals require a
> > terminal description file. So which is it free or a major development
> > headache. This whole issue of terminals and thier incompatabilites
> > is another in a long list of "problems" that people use as arguments to
> > prevent the adoption of UNIX in business. I'm not saying that it is a
> > good reason but it is correct.
>
> But it's a lot easier to write the terminal description file than to
> rewrite the application, and someone's probably written it already.
> In any case, unless you come up with a non-standard terminal type of
> your own, writing the terminal description isn't your responsibility.
>
> > I well may be biased here prefering graphical environments, but why would
> > you not want a common basic standard for console communications.
>
> Personally I preferred the good old days of having a printer hooked up
> to the console, but that's another story.
>
> > They may be around but I would be surprised to find that they are being
> > supported with tax payer dollars. The reason they are around
> > probally has more to do with the difficulty in replacing them then
> > anything else. You could drive across a good portion of this country
> > an not find a VT52 in a business situation. Unless of course that
> > terminal is tied to a UNIX system, at which point the effort to fix up
> > the terminal I/O makes replacement to expensive to consider.
>
> And we're talking about Linux/UNIX systems? Right!
>
> > Why! Why! Why would any one in there right mind try to support every
> > terminal out there. I have never understood this concept. It
> > makes about as much sense as building a house with a different type of
> > electrical power outlet in every room, just so everyone out there is
> > considered. No one in thier right mind would do this with a house,
> > they would use a standard product. ANSI escape sequences are a
> > standard, if terminal doesn't support it then keep it out of the house.
>
> Ncurses is standard too. We're not talking about DOS, we're talking
> about Unix, and ncurses *IS* a Unix standard! Why is an ANSI terminal
> preferable to ncurses here?
Why would anyone want to write code that has to be validated across possibly
hundreds of devices. In practice its not done. The preference for ANSI
is simple; you have one standard to validate your code against, also any
library supporting such a standard is likely to be well tested and not likely
to consume a large amount of resources. It is a mistake to think that the
usage of ncurses is going to allow you code to run on any terminal out there
without exception. At least when working with a standard such as ANSI,
the device is or isn't compatable. I still can not accept that ncurses is
any sort of standard terminal, it is at best a piece of translation software
that isn't even needed.
>
>
> > > Go right ahead, and then see what happens when someone actually has to
> > > use it on a different kind of terminal.
> >
> > If he was wise he would suggest to the user to go out an get a compliant
> > terminal!
>
> So it's the user's job to spend money on the new terminal, not the
> programmer's job to make the right thing happen? What happened to the
> customer's always right?
What I'm concerned about as a customer is that my hardware and software
packages worked as defined in some sort of standard. If a device is
advertised to communicate RS232 and during an install I find that the I/O is
-+5VDC I'm not going to be happy. By the same token I would expect that a
terminal would support the ANSI if it is advertised to do so. If a piece
of software is advertised to support only ANSI, that is all that I would
expect of it.
You can go to all the trouble of write a program with Ncurses or whatever and
still have compatiability problems. You will have a much higher chance of
success if your code is corectly written to support an industry standard.
Consider this digression: Even though I hate to admit it, there are some
well written software packages that run under windows. Some of these
package run quite well on Linux via wine emulation. Sure wine is not done
yet and may never be done for that matter, but it does allow Windows programs
to run on Linux. However incomplete it is programs written to the standard
have a resonable chance of working do to the replication of the API. For
character based I/O, there is no reason why one standard can not be replicated
across all systems. Wine has to accurately implement the Windows
environment to work correctly otherwise there would be very little acceptance
of wine. It is not to much to ask of hardware and software vendors, that
console I/O implement a standard such as ANSI for basic funtionality.
There are really no reasonable explainations for settling for anything
less. If we can have a emulator such as wine work well with the complex
environment that Windows presents, then we ought to be able to expect a
character terminal to work correctly.
Dave
T.E.Dickey
>>i think i could write an editor using what i know now.
>>i tempted. there are so many bad ones out there....
> Yeah, one more will not hurt.
whatever did become of Sam-the-fellow-who-wanted-to-change-the-console-driver ?
T.E.Dickey
> Download the source to an ncurses based editor and look at
> how they move the cursor. On a linux system see /usr/bin/vim
vim uses the termcap/terminfo interface.
nvi uses curses.
David T. Blake
> David T. Blake <dbl...@popper.ucsf.edu> wrote:
>
> > Download the source to an ncurses based editor and look at
> > how they move the cursor. On a linux system see /usr/bin/vim
>
> vim uses the termcap/terminfo interface.
> nvi uses curses.
On a relatively recent RH linux system.
vim-5.3
ldd /usr/bin/vim
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x4001c000)
libncurses.so.4 => /usr/lib/libncurses.so.4 (0x400c0000)
libdb.so.3 => /lib/libdb.so.3 (0x400fd000)
libgdbm.so.2 => /usr/lib/libgdbm.so.2 (0x40137000)
libdl.so.2 => /lib/libdl.so.2 (0x4013e000)
libm.so.6 => /lib/libm.so.6 (0x40141000)
libc.so.6 => /lib/libc.so.6 (0x4015d000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x4024b000)
libpthread.so.0 => /lib/libpthread.so.0 (0x40278000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
ldd /bin/vi
libtermcap.so.2 => /lib/libtermcap.so.2 (0x4001c000)
libc.so.6 => /lib/libc.so.6 (0x4001f000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
--
Dave Blake
dbl...@phy.ucsf.edu
David T. Blake
> > Instead of just writing a program that works across platforms,
> > you should go and whine to Compaq like a Windoze user that
> > their xterm doesn't support ANSI color sequences. And they are
> > REALLY likely to listen to you. They have enough problems trying
> > to make libc5 work.
>
> If they can't get thier software to work that thier problem. If
> it doesn't work then it is up to the user to point out the issue.
As a programmer, it is up to YOU to make certain your
programs work. Complaining to hardware/OS manufacturers
is of limited effectiveness. And it amounts, in my book, to
passing the buck. Just write something that works instead.
> > You are in NO position to make demands of hardware manufacturers.
> > There are many flavors of Unix, many terminals, and many
> > terminal emulations. If you write an editor that doesn't work
> > for people, they will complain to YOU, not to their hardware/OS
> > vendor/supplier.
>
> Lets see if you by a car and it doesn't work as advertised, most
> likely you would make demands of the manufacture or in
> representative. If you couldn't make head way on your own, you
> might even get legal support. Likewise there is no reason not to
> expect that software work as advertised.
There is no false advertising here. No one at Compaq is going to
tell you that OSF 4.0 was SUPPOSED to come with an xterm with
ANSI color support. They will tell you to use their superior
DXterm instead. They will tell you they didn't even write their
X support - that they contracted it out.
The car analogy is fatally flawed. A better analogy would be if
you designed a car tracking program that interfaced with the
odometer and steering. Life sure would be nice if all auto
manufacturers had ANSI steering, so that your job would be
easier. But asking them to make their steering ANSI is unlikely
to change a thing. They likely have very good reasons for their
deviations from standard. They will defend it. Heck, they might
not even care about the standard. You can make car tracking
software that will work anyway, of you can make one that only
works for ANSI cars. Which one do YOU think is a better product ??
> With all of the magic of ncurses and the other laibraies out
> there how many editors support more than a handful of terminals
> correctly?
I can name quite a few off the top of my head. Vim, nvi,
emacs-nox, MicroEmacs, jed, joe, vi, pico. They all use
termcap/terminfo, [n]curses, or slang libraries for their
terminal interface.
> ...we have no need for vendors that deliberately
> make the products uncompatible or can not support simple
> standards.
You may not need them, but they exist. And they will exist whether
you write software for them or not. If you do not, they will use
someone else's software.
> ...It is not unreasonable to expect that software work
> correctly, just as one expects a bridge to stay up or
> a train to stay on the tracks.
Standards compliance is only written in stone for open source
programs. All others deviate, either out of convenience, neglect,
or intention. LOTS of people will still use their software, so
there is a market there. LOTS of hackers work from those systems,
out of need or want. Simply hoping they will go away is neither
useful nor realistic. They will write or find or buy software to
use. It is rather simple to write software that WORKS in terminal
mode across all terminals. In the world of Windows it is easy to
do that without using curses/slang/terminfo. In Unix it is
impossible.
--
Dave Blake
dbl...@phy.ucsf.edu
David T. Blake
> ... I still can not accept that ncurses is any sort of
> standard terminal, it is at best a piece of translation
> software that isn't even needed.
The terminfo database is accepted as the ONLY reliable way of
interfacing with a terminal. Termcap is the old way. There is no
need to use ncurses - it just makes life easy. The same result
can be gotten by parsing the terminfo (or the older termcap)
database by your program. Then you'd only be guilty of
re-inventing the wheel, but at least you'd have good terminal
support.
There is, on the other hand, NO ACCEPTED CONSENSUS on what
terminal capabilities should and should not be present. What
will pageup/pagedown do ?? How about home and end ? How
about <prev> and <next> ? The function keys ? DEC keyboards
without an <esc> key ?
Terminfo is by far the best way to write portable code. Ncurses
makes it fairly easy to write portable terminal code. Most people
would even find it easier than writing their own escape sequence
drivers that will only work in a linux xterm. Every modern Unix
system will have curses or ncurses in /usr/lib or /lib.
You can choose to write your code however you like. But you
will find strong disagreement if you argue that you ought to
code to ANSI terminal standards (or some subset of them),
and that you ought to be entitled to whine about the
terminals that do not conform. Because the world is not
changing to meet your ANSI escape sequences.
--
Dave Blake
dbl...@phy.ucsf.edu
John E. Davis
wrote:
>the device is or isn't compatable. I still can not accept that ncurses is
>any sort of standard terminal, it is at best a piece of translation software
>that isn't even needed.
The point that you and others are missing is that both slang and
curses are screen management libraries that are designed to
*efficiently* manage the display by outputting as *few* characters as
possible. Any idiot can write software that ``translates'' actions
into escape sequences. The trick is to do it in the most optimal way
and the bulk of the code deals with this problem.
Dexter Hobbs
> Dexter Hobbs <d...@landho.com> wrote:
>
> > dickey, the vt users will just hafta forego
>
> you can't have it both ways: in a previous posting you're equating vt100
> and ANSI, and in this one you prove that you don't know the difference.
>
> --
> Thomas E. Dickey
> dic...@clark.net
> http://www.clark.net/pub/dickey
okay, i dont know the precise difference.
so what.
the point is unix is draggin around so much legacy
that it could pull you under.
dex
Dexter Hobbs
> On Fri, 07 Jan 2000 02:30:30 -0800, Dexter Hobbs <d...@landho.com>
> wrote:
> [...]
> >int gotoxy(int x, int y); //the notorious escape sequence artist
>
> This was implemented using 26 lines of code involving: 6 uses of
> strcat, 2 uses of sprintf, 1 call to printf, and 3 local variables
> _instead_ of the single line:
>
> fprintf (stdout, "\033[%dd\033[%dG", y, x);
>
> > system("exec clear");
> [...]
> > for(delay=0; delay<MyDelay; delay++);
>
> Ouch!
>
> >i think i could write an editor using what i know now.
> >i tempted. there are so many bad ones out there....
>
> Yeah, one more will not hurt.
beautiful!
where were you a week ago when i needed it?
but thanks for the lesson john...
i wont forget it.
dex
Dexter Hobbs
> John E. Davis <da...@space.mit.edu> wrote:
>
> >>i think i could write an editor using what i know now.
> >>i tempted. there are so many bad ones out there....
>
> > Yeah, one more will not hurt.
>
> whatever did become of Sam-the-fellow-who-wanted-to-change-the-console-driver ?
>
> --
> Thomas E. Dickey
> dic...@clark.net
> http://www.clark.net/pub/dickey
even david frantz seems to have left me to the crocs.
dex
David Frantz
> David Frantz <wiz...@eznet.net> wrote:
> > > Instead of just writing a program that works across platforms,
> > > you should go and whine to Compaq like a Windoze user that
> > > their xterm doesn't support ANSI color sequences. And they are
> > > REALLY likely to listen to you. They have enough problems trying
> > > to make libc5 work.
> >
> > If they can't get thier software to work that thier problem. If
> > it doesn't work then it is up to the user to point out the issue.
>
> As a programmer, it is up to YOU to make certain your
> programs work. Complaining to hardware/OS manufacturers
> is of limited effectiveness. And it amounts, in my book, to
> passing the buck. Just write something that works instead.
You really need to get a grip. Your saying that because a piece of
hardare is "computing equipment" the manufacture has no responsibility
to make sure the product works. This is absolute garbage, I you buy
a new car and the brakes don't work you sure as hell would blame the
manufacture. You certainly wouldn't stick your foot out the door to
bring the car to a stop, so why would you spend an excessive amount of
time working around a piece of software that doesn't work.
Your argument is completely without merit. The only acceptable
product is one that is based on a standard. Take for example the
instrumentation market, IEEE488 was around for a long time before in
took off. One of the reasons that it took off was the adoption of
software standards. Likewise networking hardware relies on standard
software interfaces, if your product can't work within the standard it
won't be accepted.
>
>
>
> > With all of the magic of ncurses and the other laibraies out
> > there how many editors support more than a handful of terminals
> > correctly?
>
> I can name quite a few off the top of my head. Vim, nvi,
> emacs-nox, MicroEmacs, jed, joe, vi, pico. They all use
> termcap/terminfo, [n]curses, or slang libraries for their
> terminal interface.
Yes but do they all work the same, every feature, across all terminal
types?
>
>
> > ...we have no need for vendors that deliberately
> > make the products uncompatible or can not support simple
> > standards.
>
> You may not need them, but they exist. And they will exist whether
> you write software for them or not. If you do not, they will use
> someone else's software.
Which is precisely why many of the big workstation maufactures are
experiencing hardtimes. If a customer has a choice between a
standards based system or mix mash of systems which will they
choose. The heavy adoption of Linux in place of the traditional
UNIX systems pretty much answers that question, go with something that
is at least moving towards standard solutions.
>
>
> > ...It is not unreasonable to expect that software work
> > correctly, just as one expects a bridge to stay up or
> > a train to stay on the tracks.
>
> Standards compliance is only written in stone for open source
> programs. All others deviate, either out of convenience, neglect,
> or intention. LOTS of people will still use their software, so
> there is a market there. LOTS of hackers work from those systems,
> out of need or want. Simply hoping they will go away is neither
> useful nor realistic. They will write or find or buy software to
> use. It is rather simple to write software that WORKS in terminal
> mode across all terminals. In the world of Windows it is easy to
> do that without using curses/slang/terminfo. In Unix it is
> impossible.
>
They may want to deviate, but the whole point of the entire argument is
that the customer does not have to accept it!!!!! Further more he
shouldn't accept it.
The fact that it is very difficult to support terminal I/O in a
UNIX environment, is one of the reasons that MS ended up with so much of
the corporate computing business. Its not just the question of how
well ncurses works, which is in its self questionable, but a systems
management issue.
Demanding a standard for terminal I/O is the most rational way to
correct the current problems with UNIX.
David Frantz
> David Frantz <wiz...@eznet.net> wrote:
>
> > ... I still can not accept that ncurses is any sort of
> > standard terminal, it is at best a piece of translation
> > software that isn't even needed.
>
> The terminfo database is accepted as the ONLY reliable way of
> interfacing with a terminal. Termcap is the old way. There is no
> need to use ncurses - it just makes life easy. The same result
> can be gotten by parsing the terminfo (or the older termcap)
> database by your program. Then you'd only be guilty of
> re-inventing the wheel, but at least you'd have good terminal
> support.
>
> There is, on the other hand, NO ACCEPTED CONSENSUS on what
> terminal capabilities should and should not be present. What
> will pageup/pagedown do ?? How about home and end ? How
> about <prev> and <next> ? The function keys ? DEC keyboards
> without an <esc> key ?
The point is to develop a consesus for basic terminal I/O across all
platforms. Futhermore we shouldn't be concerned about old
hardware that is of limit usefulness and by the way almost
impossible to replace for some of the older terminals.
>
>
> Terminfo is by far the best way to write portable code. Ncurses
> makes it fairly easy to write portable terminal code. Most people
> would even find it easier than writing their own escape sequence
> drivers that will only work in a linux xterm. Every modern Unix
> system will have curses or ncurses in /usr/lib or /lib.
I'm not a big fan of escape sequences embedded in a program
either. Rather I would like to see a library that supports
communications to a standard device. This library should be
compact without all of the garbage associated with ncurses.
>
>
> You can choose to write your code however you like. But you
> will find strong disagreement if you argue that you ought to
> code to ANSI terminal standards (or some subset of them),
> and that you ought to be entitled to whine about the
> terminals that do not conform. Because the world is not
> changing to meet your ANSI escape sequences.
The world is changing and will continue to change. Maybe the
future won't be ANSI, but a defacto standard from Linux, but if
UNIX is to develope any sort of market acceptance beyond what it has
not standards will have to be considered.
>
>
> --
> Dave Blake
> dbl...@phy.ucsf.edu
Robert Krawitz
> "T.E.Dickey" wrote:
>
> > Dexter Hobbs <d...@landho.com> wrote:
> >
> > > dickey, the vt users will just hafta forego
> >
> > you can't have it both ways: in a previous posting you're equating vt100
> > and ANSI, and in this one you prove that you don't know the difference.
>
> okay, i dont know the precise difference.
> so what.
> the point is unix is draggin around so much legacy
> that it could pull you under.
Maybe there's a reason *why* this "legacy" code (or more properly,
legacy entries in a database) is around???
Robert Krawitz
> The world is changing and will continue to change. Maybe the
> future won't be ANSI
Bingo. You've just said it perfectly.
Robert Krawitz
> The point is to develop a consesus for basic terminal I/O across all
> platforms. Futhermore we shouldn't be concerned about old
> hardware that is of limit usefulness and by the way almost
> impossible to replace for some of the older terminals.
Are you even listening to what anyone is saying? CURSES/NCURSES IS
*PRECISELY* THIS CONSENSUS FOR BASIC TERMINAL I/O ACROSS ALL
PLATFORMS!!!!!
What you're asking for is something quite different: for the
compatibility to be at the firmware level. But why? If an
application uses the defined terminal interface library, why should it
matter where the compatibility is?
> I'm not a big fan of escape sequences embedded in a program
> either. Rather I would like to see a library that supports
> communications to a standard device. This library should be
> compact without all of the garbage associated with ncurses.
What "garbage" associated with ncurses don't you like? Why not write
your standard library on top of ncurses?
> The world is changing and will continue to change. Maybe the
> future won't be ANSI, but a defacto standard from Linux, but if
> UNIX is to develope any sort of market acceptance beyond what it has
> not standards will have to be considered.
Right. Which is exactly why the ncurses standard is the one to use.
Peter T. Breuer
: You really need to get a grip. Your saying that because a piece of
: hardare is "computing equipment" the manufacture has no responsibility
: to make sure the product works. This is absolute garbage, I you buy
It all works fine .. to their specs, with their drivers, and their OS.
If you want to make it work, thank goodness for a programming
abstraction and someone who has done the lowlevel legwork for you.
Always use the abstraction.
Boy, I bet your code is unmaintainable! I'd fire you before hiring you
if you thought that writing ansi escape sequences direct from your code
was a good thing! Did you even use an array of sequences and refere to
them by nmemonic names? No? I bet not.
Peter
Robert Krawitz
> With all of the magic of ncurses and the other laibraies out there how
> many editors support more than a handful of terminals correctly?
Uh...emacs? vi? joe? Let's keep going...
It is not unreasonable to expect that
> software work correctly, just as one expects a bridge to stay up or a
> train to stay on the tracks.
You're making really, really good arguments for using ncurses, you
realize...
Robert Krawitz
> > I can name quite a few off the top of my head. Vim, nvi,
> > emacs-nox, MicroEmacs, jed, joe, vi, pico. They all use
> > termcap/terminfo, [n]curses, or slang libraries for their
> > terminal interface.
>
> Yes but do they all work the same, every feature, across all terminal
> types?
Subject to limitations of the variety "it's hard to have a page up if
your keyboard doesn't have a page up key", yes!
> The fact that it is very difficult to support terminal I/O in a
> UNIX environment, is one of the reasons that MS ended up with so much of
> the corporate computing business.
Absolute nonsense. Microsoft sold everyone on the notion of an
intuitive GUI to handle everything. Notwithstanding the notion that
it's possible to have an intuitive textual interface, or that a lot of
stuff isn't intuitive no matter how superficial the interface, that
sold pretty well. As for console support, Microsoft tries to hide the
very existence of a non-GUI console. How much can you actually do
from a dumb terminal in Windows?
Its not just the question of how
> well ncurses works, which is in its self questionable, but a systems
> management issue.
Exactly what are you talking about? If I hook up a VT100 to a spare
serial port on my PC and enable getty on those lines, everything just
works, and "smart console" applications will work just fine.
T.E.Dickey
>> vim uses the termcap/terminfo interface.
>> nvi uses curses.
> On a relatively recent RH linux system.
> vim-5.3
read the source:
it doesn't use curses, but uses the termcap/terminfo interface.
vim does its own cursor optimization.
(to be more complete: vim and vile both use termcap/terminfo, nvi uses curses,
and elvis may do either)
T.E.Dickey
> The point that you and others are missing is that both slang and
> curses are screen management libraries that are designed to
> *efficiently* manage the display by outputting as *few* characters as
> possible. Any idiot can write software that ``translates'' actions
> into escape sequences. The trick is to do it in the most optimal way
> and the bulk of the code deals with this problem.
well, not _any_ idiot: go over to comp.lang.c to see people asking how to
"clear the screen" (it's an faq ;-).
T.E.Dickey
> I don't consider a library that tries to interface to dozens and dozens of
> terminals to be a standard of any sort. It is a library that will allow some
certainly: now let's get rid of all of those different video cards, modems
and computer chips (we really ought to - if you're serious - program in
ANSI assembler language ;-)
David Frantz
> David Frantz <wiz...@eznet.net> writes:
>
> > The point is to develop a consesus for basic terminal I/O across all
> > platforms. Futhermore we shouldn't be concerned about old
> > hardware that is of limit usefulness and by the way almost
> > impossible to replace for some of the older terminals.
>
> Are you even listening to what anyone is saying? CURSES/NCURSES IS
> *PRECISELY* THIS CONSENSUS FOR BASIC TERMINAL I/O ACROSS ALL
> PLATFORMS!!!!!
>
> What you're asking for is something quite different: for the
> compatibility to be at the firmware level. But why? If an
> application uses the defined terminal interface library, why should it
> matter where the compatibility is?
Yes; that is what I'm asking for - compatability at either the firmware
or emulation level.
The reasons are simple
1 Maintainability
2 Much lower cost for both hardware and software.
3 Fewer systems resources consumed.
4 More reliable software.
5 Industry acceptance <-- this is a big one.
Just look at what compatable BIOS's did for lowering the price of
PC hardware. What I'm say is that it would benefit everyone in the
UNIX industry to adopt a terminal standard such as ANSI for basic
terminal I/O, and implement it correctly. Even within the Unix play
ground; we can see that things like X have created a base for the
development of GUI software that would have happened if it weren't for
predefined standard. Sure it is possible for X to be replaced in the
future but for now it is a standard for GUI like wise a standard for
terminal I/O should exist.
Granted you can argue that ncurses is a standard but I consider it a very
big stick to swing at was is a very simple problem. Lets face it
terminal I/O is going to become less and less significant as GUI's and
networking supplant serial line I/O. Keeping terminal type solutions
low in cost and compliant will provide them with a slightly extended life
span.
If I was to buy a terminal today, highly unlikely, I'd want it to be
ANSI compliant. The same goes for any terminal emulation running on
any computer system. I really can't imagine anybody else doing
anything else.
>
>
> > I'm not a big fan of escape sequences embedded in a program
> > either. Rather I would like to see a library that supports
> > communications to a standard device. This library should be
> > compact without all of the garbage associated with ncurses.
>
> What "garbage" associated with ncurses don't you like? Why not write
> your standard library on top of ncurses?
>
> > The world is changing and will continue to change. Maybe the
> > future won't be ANSI, but a defacto standard from Linux, but if
> > UNIX is to develope any sort of market acceptance beyond what it has
> > not standards will have to be considered.
>
> Right. Which is exactly why the ncurses standard is the one to use.
This is exactly the problem, wether you like it or not supporting a bunch
of terminal types is frowned upon in industry. In some places trying
to support anything other than Windows is frowned upon. If the
UNIX/Linux camp can get its act together and at least demonstrate that
they have a common standard for terminal I/O, amongst other things, then
there is a good chance to expand the market for such systems.
What I can't understand is why everyone is obsessed with supporting
proprietary terminals when we are in an era of generic computer
hardware. You don't see an interest in supporting such things as the
aged network standards that are no longer significant. So why do we
continue to hang on to this idea that terminal I/O has to be done in such
a way that any device no matter how archaic is supported.
I would have to wonder what everyone would think if SCSI drive
manufactures all of a sudden started to implement thier drives in such a
way that the standard was no longer supported. Would anyone suggest
that we create a SCSI_disk_cap file, I don't think so. Then why do we
put up with all the terminal device incompatablities and then use a high
overhead work arounds like ncurses?
David Frantz
> David Frantz <wiz...@eznet.net> writes:
>
> > The world is changing and will continue to change. Maybe the
> > future won't be ANSI
>
> Bingo. You've just said it perfectly.
Let me guess you then want to expand the size of your terminfo file and
then debug any issues that the new terminal definition raises. If
the future isn't ANSI then it best be managed standard.
Dexter Hobbs
> Dexter Hobbs <d...@landho.com> writes:
>
> > "T.E.Dickey" wrote:
> >
> > > Dexter Hobbs <d...@landho.com> wrote:
> > >
> > > > dickey, the vt users will just hafta forego
> > >
> > > you can't have it both ways: in a previous posting you're equating vt100
> > > and ANSI, and in this one you prove that you don't know the difference.
> >
> > okay, i dont know the precise difference.
> > so what.
> > the point is unix is draggin around so much legacy
> > that it could pull you under.
>
> Maybe there's a reason *why* this "legacy" code (or more properly,
> legacy entries in a database) is around???
>
> --
> 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
i think david frantz addressed this matter earlier in our discussion.
i agree with his standpoint.
imagine a bank database with the accounts of all its dead customers
still in place...8^)
i would not be proud of it.
and since we've beat this matter of the legacy terminals half to death
could we slide over to the GUI for a moment?
let me take a moment to record a few whispers of doubt i hear in my mind.
1. halcyon (www.halcyon.com) failed in its port of VB to linux (VBIX)
great idea. nothing can touch VB for RAD.
why *did* it fail?
was it bekuz X wasnt up to it?
man, what a feather in ther kap if they'd made it.
they musta hit a rock, blam.
but what was it?
it makes me nervous, friends...
2. i have red reports and asides that X is too complicated.
are they true?
3. X sports an interface verrrry similiar to windows 95.
why?
couldn't the boys at KDE and GNOME come up with something different?
are they just playin' ketch up?
4. i recently watched a mac G4 graphics demo.
beat the pants off any PC i ever saw.
and this linux box is not performing like the G4 either.
probably a little slower than the NT.
(actually, i've benchmarked some console programs
and gcc and C++ are virtually in a dead heat.
gcc is faster at looping and C++ is faster at square roots, etc etc etc)
*and* unix has no RAD development environment.
(ya, heard about delphi, and i hope the vapor goes away soon.)
5. i know MS has pushed a lot of people around, pretty ugly.
but then they're swimmin with sharks.
do you think larry ellison and scott whats his name
dont wanna be the next big kahuna.
hah!
6. and, dickey, ya know sam was correct:
you need to rewrite the keyboard driver
^[[[21~
hahahhhaaaahhhaaa
thats silly, man.
6 characters to report a single keypress.
to whom do we own this magnificient efficiency?
7. problee the only thing that could save unix
is a complete re-write from the ground up.
its too old guys.
yur trying to put a snappy porsche body
over the chassis of a model A ford.
unix is classical music.
i used t love it.
now i play my own.
dex
Grant Edwards
>> >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.
>
>Most children are started out with a little vocabulary and
>phonetics - and now that I think about it a lot of baby talk.
>Sure grammer is part of that learning process but it is
>impossible to speak with good grammer if you do not have a
>vocabulary to start with.
Right, but the completely irrelevent tangent in question was
learning to read/write before learning grammar.
>After all why do we teach children thier ABC's and 123's if not
>to provide a base to learn about language.
People are quite capable of learning language (and most do so)
before seeing ABC's or 123's.
>But; even before that a child is tught nothing but words,
>usually that first one being daddy. Once a vocabulary is
>developed the child will begin to develop the skills to put the
>words into useful sentences, assuming he is raised around
>people with the ability to do that him self.
Right. And then _after_ learning enough grammar to construct
and understand extremely complex sentences, we teach them to
read and write.
>Even in schools the emphasis in the first years are put on the
>development of basic skills before much effort is placed on the
>specifics of grammer.
That's because most of the students start Kindergarten already
knowing _huge_ amounts of grammar. You don't _need_ to teach
the average 6-year-old how to use present/past/future tense,
subject, verb, pronouns, articles, conjunctions, direct object,
and indirect objects in a sentence. They already _know_ that.
One presumes that 6-year-old German kids even know which of the
thirty-seven versions of the word "the" to use in a particular
sentence even though I don't after studying German for two
years. ;) [The problem is I'm using the wrong part of my brain
to learn German grammar. The right part stopped doing that 30+
years ago.]
>So one learns to count to ten before one counts to a hundred,
>and A - Z are learn before things like verb and noun
>relationships.
No, we learn verb and noun relationships long before we learn
A-Z. You can't construct or understand senences without
learning verb and noun relationships. My three year old nephew
(who, admittedly is one of the brightest kids on the planet ;)
has learned verb and noun relationships, direct and indirect
objects, subjective vs. objective pronouns, and tons of other
grammatical things. He can't read or write, (though he can
recognize a few letters and knows his name when he sees it).
--
Grant Edwards grante Yow! TAILFINS!!...click...
at
visi.com
David Frantz
i'd be willing to bet that he developed a vocabular before he even grasped the
concept of verbs and nouns. It certainly is what every other child does.
Dave
Robert Krawitz
> 2. i have red reports and asides that X is too complicated.
> are they true?
Try writing a simple application, then get back to us.
> 3. X sports an interface verrrry similiar to windows 95.
> why?
> couldn't the boys at KDE and GNOME come up with something different?
> are they just playin' ketch up?
X doesn't sport much of an interface at all. Red Hat has distributed
a number of versions that use fvwm95 by default as the window manager,
which is intended to ape Windows 95. It's very easy to do something
very different, though.
> 6. and, dickey, ya know sam was correct:
> you need to rewrite the keyboard driver
> ^[[[21~
> hahahhhaaaahhhaaa
> thats silly, man.
> 6 characters to report a single keypress.
> to whom do we own this magnificient efficiency?
Duh, your own favorite ANSI/VT100 spec. Mind you, if you use curses,
you can completely avoid this nonsense. Hint hint.
> 7. problee the only thing that could save unix
> is a complete re-write from the ground up.
> its too old guys.
> yur trying to put a snappy porsche body
> over the chassis of a model A ford.
> unix is classical music.
> i used t love it.
> now i play my own.
Some of us out there still appreciate Beethoven. What would you
suggest as the target for the "complete rewrite from the ground up"?
dex
Robert Krawitz wrote in message <86u2km2...@tiac.net>...
>Dexter Hobbs <d...@landho.com> writes:
>
>> 2. i have red reports and asides that X is too complicated.
>> are they true?
>
>Try writing a simple application, then get back to us.
thats a fair criticism.
it might take a year to dig down to the truth...
dont hold yur breath.
>
>> 3. X sports an interface verrrry similiar to windows 95.
>> why?
>> couldn't the boys at KDE and GNOME come up with something different?
>> are they just playin' ketch up?
>
>X doesn't sport much of an interface at all. Red Hat has distributed
>a number of versions that use fvwm95 by default as the window manager,
>which is intended to ape Windows 95. It's very easy to do something
>very different, though.
>
of course its easy to do something different.
thats the neat thing about X.
MS killed GUI development on windows with windows 95.
i think they shoulda gone to a 32 bit DOS.
and then run windows as a graphic environment
like in windows 3.11.
as it is they slammed the door on all GUI development.
so X wins that battle hands down.
but why ape windows 95 anyway.
but maybe i'm wrong.
maybe unix will take windows.
but it doubt it.
>> 6. and, dickey, ya know sam was correct:
>> you need to rewrite the keyboard driver
>> ^[[[21~
>> hahahhhaaaahhhaaa
>> thats silly, man.
>> 6 characters to report a single keypress.
>> to whom do we own this magnificient efficiency?
>
>Duh, your own favorite ANSI/VT100 spec. Mind you, if you use curses,
>you can completely avoid this nonsense. Hint hint.
>
it's not nonsense, krawitz, its what the keyboard driver sends to the CPU.
its a fundamental transaction of the OS.
every system program would consider to be an axiom of the system.
and any good applications programmer would wanna know
what the keyboard driver reports to the CPU when you press a key.
>> 7. problee the only thing that could save unix
>> is a complete re-write from the ground up.
>> its too old guys.
>> yur trying to put a snappy porsche body
>> over the chassis of a model A ford.
>> unix is classical music.
>> i used t love it.
>> now i play my own.
>
>Some of us out there still appreciate Beethoven. What would you
>suggest as the target for the "complete rewrite from the ground up"?
you cant cling to the past.
even LVB.
what areas of human endeavor move the slowest.
music and religion.
a 1000 years after the fall of sumeria
the semites were still singin sumerian hymns.
isnt the catholic mass still held in latin.
and latin is a dead language.
(maybe C++ will die soon too 8^)
concerning the unix re-write:
1. keep the forward slashes
2. keep the powerful command line
3. make it possible to map any character set to the keyboard
and make the keys remappable.
and make the number of keys variable.
maybe use unicode.
certainly a 16 bit character.
4. adopt a single terminal (so you can dump or simplify the curses lib)
5. write a better windowing system
6. allow the user to run a program in single user mode
with no multitasking and direct screen writes if he needs too.
many times i want all my horsepower on one app.
how would you re-write unix, if you had the chance?
how would brian kernigan re-write unix, if he had the chance?
how would david cutler re-write NT, if he had the chance?
i know i would like to re-write a lot of programs i've written.
dex
David Frantz
> Robert Krawitz wrote:
>
> > Dexter Hobbs <d...@landho.com> writes:
> >
> > > "T.E.Dickey" wrote:
> > >
> > > > Dexter Hobbs <d...@landho.com> wrote:
> > > >
> > > > > dickey, the vt users will just hafta forego
> > > >
> > > > you can't have it both ways: in a previous posting you're equating vt100
> > > > and ANSI, and in this one you prove that you don't know the difference.
> > >
> > > okay, i dont know the precise difference.
> > > so what.
> > > the point is unix is draggin around so much legacy
> > > that it could pull you under.
> >
> > Maybe there's a reason *why* this "legacy" code (or more properly,
> > legacy entries in a database) is around???
> >
> > --
> > 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
>
> i think david frantz addressed this matter earlier in our discussion.
> i agree with his standpoint.
> imagine a bank database with the accounts of all its dead customers
> still in place...8^)
> i would not be proud of it.
>
> and since we've beat this matter of the legacy terminals half to death
> could we slide over to the GUI for a moment?
>
> let me take a moment to record a few whispers of doubt i hear in my mind.
> 1. halcyon (www.halcyon.com) failed in its port of VB to linux (VBIX)
> great idea. nothing can touch VB for RAD.
> why *did* it fail?
> was it bekuz X wasnt up to it?
> man, what a feather in ther kap if they'd made it.
> they musta hit a rock, blam.
> but what was it?
> it makes me nervous, friends...
>
> 2. i have red reports and asides that X is too complicated.
> are they true?
>
> 3. X sports an interface verrrry similiar to windows 95.
> why?
> couldn't the boys at KDE and GNOME come up with something different?
> are they just playin' ketch up?
>
> 4. i recently watched a mac G4 graphics demo.
> beat the pants off any PC i ever saw.
> and this linux box is not performing like the G4 either.
> probably a little slower than the NT.
> (actually, i've benchmarked some console programs
> and gcc and C++ are virtually in a dead heat.
> gcc is faster at looping and C++ is faster at square roots, etc etc etc)
I'm amazed by the G4 also. In fact I'm tempted to buy a G4 justt to run Linux
on it. You have to consider overall performance though with the G4, the
results achieve with Linux apps may not look as good in comparison. Apple &
Motorola really need to give this chip a serious performance boost for integers
calculations. Also stay on the look out for new PPC based machines built
specifically for Linux.
Dave
>
>
> *and* unix has no RAD development environment.
> (ya, heard about delphi, and i hope the vapor goes away soon.)
>
> 5. i know MS has pushed a lot of people around, pretty ugly.
> but then they're swimmin with sharks.
> do you think larry ellison and scott whats his name
> dont wanna be the next big kahuna.
> hah!
>
> 6. and, dickey, ya know sam was correct:
> you need to rewrite the keyboard driver
> ^[[[21~
> hahahhhaaaahhhaaa
> thats silly, man.
> 6 characters to report a single keypress.
> to whom do we own this magnificient efficiency?
>
> 7. problee the only thing that could save unix
> is a complete re-write from the ground up.
> its too old guys.
> yur trying to put a snappy porsche body
> over the chassis of a model A ford.
> unix is classical music.
> i used t love it.
> now i play my own.
>
While I may think that the SUN would shine much britter on the Unix/Linux world
if it would just embrace a few standards, I would never call it a model A
ford. We may end up with Linux as the defacto standard, but you should
realize that in some was Linux is one of the most modern OS out there now.
Sure there are a few rough points with the GNU front end but at the kernel level
things look pretty good.
I would suggest looking at "kernel traffic" to get a flavor for were every thing
stands. Yes; some things don't get the attention they deserve - for example
compatable terminal I/O, firewire, USB, Graphics, and other features - but they
are being worked on. Whats more anyone with valid input can have it
considered. Further more some companies, mostly graphic chip hiouses, are
stepping up to the plate with drivers for thier hardware.
>
> dex
Bill Gribble
> i'd be willing to bet that he developed a vocabular before he even
> grasped the concept of verbs and nouns. It certainly is what every
> other child does.
I'd be willing to bet that of 10 randomly selected linguists and
child development experts I could find 3 who would disagree with you.
We don't really know much at all of how the acquisition of language in
children works, despite a very large amount of study and thought by
very smart folks.
Bill Gribble
Robert Krawitz
> Robert Krawitz wrote in message <86u2km2...@tiac.net>...
> >> 6. and, dickey, ya know sam was correct:
> >> you need to rewrite the keyboard driver
> >> ^[[[21~
> >> hahahhhaaaahhhaaa
> >> thats silly, man.
> >> 6 characters to report a single keypress.
> >> to whom do we own this magnificient efficiency?
> >
> >Duh, your own favorite ANSI/VT100 spec. Mind you, if you use curses,
> >you can completely avoid this nonsense. Hint hint.
> >
> it's not nonsense, krawitz, its what the keyboard driver sends to the CPU.
> its a fundamental transaction of the OS.
> every system program would consider to be an axiom of the system.
> and any good applications programmer would wanna know
> what the keyboard driver reports to the CPU when you press a key.
Why does an applications programmer CARE exactly what the keyboard
driver reports to the CPU? Doesn't it really only care what keys were
pressed? The exact sequence of bytes is a line protocol. You don't
care about the line protocol, only about what the user has done, yes?
It's only the person who writes the keyboard driver (or more likely
the person who writes the terminal description) who cares about the
specific line protocol.
> concerning the unix re-write:
> 3. make it possible to map any character set to the keyboard
> and make the keys remappable.
> and make the number of keys variable.
Unix doesn't care how many keys are on the keyboard. Hint: it really
doesn't care one whit what the input and output devices really are.
Some people control their Linux and Unix boxes via a serial port
connected to a terminal concentrator and telnet to the terminal
concentrator to connect to the system console. If you happen to use
X, all this key remapping and variable keyboard stuff works just fine
(see xmodmap).
> maybe use unicode.
> certainly a 16 bit character.
That bridge *will* have to be crossed at some point, but changing will
not be easy.
> 4. adopt a single terminal (so you can dump or simplify the curses lib)
You keep arguing for this, but you have not presented a convincing
argument as to why this should be. What's fundamentally wrong with
curses that it needs to be dumped, thereby knocking out people who
happen to have unusual hardware?
> 5. write a better windowing system
Which means...? Again, remember that X and the user interface are two
different things. Hint: there are things wrong with X; you should
phrase your answer in terms of what's wrong with X rather than what's
bad about a particular user interface. Otherwise we would simply
invite you to write your own window manager or GUI environment, or
join the GNOME or KDE projects.
> 6. allow the user to run a program in single user mode
> with no multitasking and direct screen writes if he needs too.
> many times i want all my horsepower on one app.
Many Unix versions do support real-time priority, which more or less
accomplishes this (the kernel still runs, but normal user processes do
not so long as the real time process wants the CPU). Hint: you do NOT
want to run normal user jobs as real-time processes, PERIOD. They
tend to be impossible to kill, because your shell cannot get any time
to send signals to them. I had to rewrite a script that somebody
wrote to run a program at real time priority to try to collect low
level performance data from the kernel. Everyone thought the kernel
was broken (it was a development kernel, so this was a possibility)
because when anyone tried this script on a significantly long program
the machine appeared to lock up. What was really taking place was
that the application was soaking the CPU and nothing else could get
anything in edgewise. The application did not run significantly
faster or cleaner realtime than it did normally.
If your machine is not otherwise busy, the background system stuff
doesn't take up very much CPU at all, and the stuff that it does do
you REALLY do want it to do (paging, filesystem synchronization)
whether you realize it or not. You can't tell the difference between
99% and 100% of the CPU, but that last 1% of the CPU for the system
really lets it get a lot done.
You can always shut down your machine to single user mode (none of the
usual daemons are running, and so forth) and run your job. I've done
that for some benchmarking stuff. Of course, if your machine tries to
use network services it will likely fail unless the network has
already been enabled and you're not relying on any RPC stuff, but
that's your lookout.
> how would you re-write unix, if you had the chance?
I don't claim to be a serious OS designer myself. Most of the stuff
I'd do is evolutionary, not revolutionary. The multiprocessing stuff
(SMP and NUMA) in Linux is still rather weak compared to, say, Solaris
(disclaimer: I work for Sun), for example.
Grant Edwards
>i'd be willing to bet that he developed a vocabular before he
>even grasped the concept of verbs and nouns. It certainly is
>what every other child does.
Agreed. I've never said otherwise. What I claimed was that
you learn the grammar of a language before you learn to read or
write.
--
Grant Edwards grante Yow! I'm rated PG-34!!
at
visi.com
Bill Anderson
> > > would suggest that you explain to your vendors that they either
> > > support the ANSI standard or find someone else to sell thier
> > > machines to. There is no reason to have a database of xxx number
> > > of terminals on a machine especially when the vast majority of
> > > terminals used today are emulations. This also does not mean that
> > > the console can not have extended functions, just that it support
> > > the ANSI ones correctly.
> >
> > Right.
> >
> > Instead of just writing a program that works across platforms,
> > you should go and whine to Compaq like a Windoze user that
> > their xterm doesn't support ANSI color sequences. And they are
> > REALLY likely to listen to you. They have enough problems trying
> > to make libc5 work.
>
> If they can't get thier software to work that thier problem. If
> it doesn't work then it is up to the user to point out the issue.
>
> >
> >
> > There are many flavors of Unix, many terminals, and many
> > terminal emulations. If you write an editor that doesn't work
> > for people, they will complain to YOU, not to their hardware/OS
> > vendor/supplier.
>
> Lets see if you by a car and it doesn't work as advertised, most
> likely you would make demands of the manufacture or in
> representative.
do you go to the make of the car or the radio? if you go to the
manufacturer, you go nowhere, and rightly so.
Even better, if you buy a set of rims for your car, and they don't fit,
who do you complain to?
The automaker for not conforming to the wheel standard?
"Actually, sir, they do fit the standard, you will note however, that
the standard doe snot indicate the number of lugs required. We use 5 lug
wheels, you purchased 6 lug wheels. Go see the people who sold you the
wheels."
(OK, so it would be more accurate to say they would tell you that last
sentece first as soon as they found out you were not talking about
wheels _they_ produced.)
--
Bill Anderson Linux/Unix Administrator, Security Analyst
ESBU (ARC) bill_a...@boi.hp.com
My opinions are just that; _my_ opinions.
Bill Anderson
> > > Why! Why! Why would any one in there right mind try to support every
> > > terminal out there. I have never understood this concept. It
> > > makes about as much sense as building a house with a different type of
> > > electrical power outlet in every room, just so everyone out there is
> > > considered. No one in thier right mind would do this with a house,
> > > they would use a standard product. ANSI escape sequences are a
> > > standard, if terminal doesn't support it then keep it out of the house.
> >
> > Ncurses is standard too. We're not talking about DOS, we're talking
> > about Unix, and ncurses *IS* a Unix standard! Why is an ANSI terminal
> > preferable to ncurses here?
>
> Why would anyone want to write code that has to be validated across possibly
> hundreds of devices. In practice its not done.
Yes it is!
> The preference for ANSI
> is simple; you have one standard to validate your code against, also any
> library supporting such a standard is likely to be well tested and not likely
> to consume a large amount of resources. It is a mistake to think that the
> usage of ncurses is going to allow you code to run on any terminal out there
> without exception. At least when working with a standard such as ANSI,
> the device is or isn't compatable. I still can not accept that ncurses is
> any sort of standard terminal, it is at best a piece of translation software
> that isn't even needed.
Honestly, what you accept or do not accept is irrelevant to the reality
of the situation.
> Consider this digression: Even though I hate to admit it, there are some
> well written software packages that run under windows. Some of these
> package run quite well on Linux via wine emulation.
Wine is not an emulator.
Bill Anderson
>
> Robert Krawitz wrote:
>
...
> > If you learn to use ncurses, you'll also only need to support one type
> > of terminal. The others will come for free.
>
> But you just mentioned above that all these new terminals require a
> terminal description file. So which is it free or a major development
> headache. This whole issue of terminals and thier incompatabilites
> is another in a long list of "problems" that people use as arguments to
> prevent the adoption of UNIX in business. I'm not saying that it is a
> good reason but it is correct.
I have never once heard that 'problem' as being something 'preventing
the adoption of UNIX in business'.
> > > i have also seen first hand what a mess the
> > > UNIX terminal situation is.
> > > i don't wanna hurt anybodys feelings here.
> > > but its the truth.
> >
> > What's such a mess? That there's a diversity? Is it any worse than
> > the whole mess of sound cards and graphics cards on the PC? Or are
> > there good reasons for the diversity? Or do you have something else
> > in mind?
>
> I well may be biased here prefering graphical environments, but why would
> you not want a common basic standard for console communications. ANSI
> may not be perfect but I would prefer to see code written for that
> standard then to worry about supporting hundreds of terminal types to do
> something as basic as providing a console. Really; diversity is for
> girl friends. not for such a low level piece of a system such as a
> console.
The diversity _DOES_ exist, for whatever reason. Since it does, the
programmer wanting to write _portable_ code takes this into account.
> > > what is preventing the unix camp from dropping
> > > VT52 and all the other defunct terminals anyway?
> > > they are dead weight, man....8^(
> >
> > 1) There are still a few of them around, and there's no good reason to
> > force their users to throw them away. Unlike MS, Unix folks don't
> > believe in obsoleting old hardware for some minor conveniences.
>
> They may be around but I would be surprised to find that they are being
> supported with tax payer dollars.
Only due to lack of experience. Some of us (many even?) have seen what
we are talking about.
> The reason they are around
> probally has more to do with the difficulty in replacing them then
> anything else. You could drive across a good portion of this country
> an not find a VT52 in a business situation. Unless of course that
> terminal is tied to a UNIX system, at which point the effort to fix up
> the terminal I/O makes replacement to expensive to consider.
You are admittedly arguing from a point of ignorance. You quite frankly
do not know what is out there. You are making entirely unfounded
guesses. And a good argument for ncurses it is.
> >
> > > what i'm trying to do is port my expertise with the terminal
> > > from DOS (and windows) to unix.
> >
> > Fine, so learn how to do things the Unix way *before* bashing it
> > rather than calling it a "mess" because you're too lazy to learn how
> > to do it in a way that actually will work on most of the terminals
> > that are out there.
>
> Why! Why! Why would any one in there right mind try to support every
> terminal out there. I have never understood this concept. It
> makes about as much sense as building a house with a different type of
> electrical power outlet in every room, just so everyone out there is
> considered. No one in thier right mind would do this with a house,
> they would use a standard product. ANSI escape sequences are a
> standard, if terminal doesn't support it then keep it out of the house.
--
Bill Anderson
>
> While I may think that the SUN would shine much britter on the Unix/Linux world
> if it would just embrace a few standards,
A FEW standards??
Care to guess whether *nix supports more computing stanards than
windows*?
dex
Bill Anderson wrote in message <388E5CAC...@boi.hp.com>...
>David Frantz wrote:
>>
>
>> While I may think that the SUN would shine much britter on the Unix/Linux
world
>> if it would just embrace a few standards,
>
>A FEW standards??
>
>Care to guess whether *nix supports more computing stanards than
>windows*?
>
but yur firin' on both barrels...
wujuu agree that its harder to make things works in UNIX
than in Windows (and i presume Mac)?
could it be bekuz of the diversity of standards.
too many libraries.
too many terminal types.
too many kernal types.
very old device drivers
the characters returned from the keyboard driver
are ridiculously complex.
why?
problee historical...
all historical reasons.
UNIX is old.
and UNIX has aged faster than C.
i have a theory that UNIX is no good.
but C is great.
if C hadn't come along UNIX would be forgotten.
C saved UNIX from extinction.
(mind you, its only a theory 8^)
C was so good that UNIX went places
the assembly language boys just couldn't go.
(they were muckin around with ther loop counters too much)
so UNIX produced a body of software unmatched
by any other operating system.
and all bekuz of C.
if C had been born on IBM equipment
you might be touting the virtues of MVS
instead of UNIX.
i dont see anything so all fired great about UNIX.
i _do_ see the quantum leap of C
over assembler.
enlighten me, boys.
dex
Bill Anderson
>
> Bill Anderson wrote in message <388E5CAC...@boi.hp.com>...
> >David Frantz wrote:
> >>
> >
> >> While I may think that the SUN would shine much britter on the Unix/Linux
> world
> >> if it would just embrace a few standards,
> >
> >A FEW standards??
> >
> >Care to guess whether *nix supports more computing stanards than
> >windows*?
> >
> bill, ya got in late.
> but yur firin' on both barrels...
>
> wujuu agree that its harder to make things works in UNIX
> than in Windows (and i presume Mac)?
Nope. And I have done both.
>
> could it be bekuz of the diversity of standards.
> too many libraries.
Now which damned dll do I need?
> too many terminal types.
As one who supports man terminals, nope, as it is not a problem
> too many kernal types.
Not even close.
> very old device drivers
Only used when using 'very old devices'
Much of unix driver action seems to be abstracted, unless you are going
for specific peices of hardware with additional features.
> the characters returned from the keyboard driver
> are ridiculously complex.
> why?
beats me, i never need to deal with them. Higher libraries.
> problee historical...
> all historical reasons.
> UNIX is old.
> and UNIX has aged faster than C.
Age of Unix is Irrelevant. And when used would be used on the opposite
side of your argument.
> i have a theory that UNIX is no good.
> but C is great.
> if C hadn't come along UNIX would be forgotten.
> C saved UNIX from extinction.
> (mind you, its only a theory 8^)
And you are certainly entitled to it. Malthus had a theory too.
> C was so good that UNIX went places
> the assembly language boys just couldn't go.
> (they were muckin around with ther loop counters too much)
> so UNIX produced a body of software unmatched
> by any other operating system.
> and all bekuz of C.
>
> if C had been born on IBM equipment
> you might be touting the virtues of MVS
> instead of UNIX.
A world of could-have-happens is irrelevant and boring.
I can just as easily, and with just as much veracity say that had Unix
not gone closed source, you would never have seen the rise of windows.
> i dont see anything so all fired great about UNIX.
> i _do_ see the quantum leap of C
> over assembler.
>
> enlighten me, boys.
> dex
Enlightenment comes from experience and use, not from a usenet posting
(although ... you could download Enlightenment, but that's not what you
have in mind, is it?).