Skip to main content
gamedev.net
🔒 Locked

Linux - Curses Problem

Started by dave Mar 16, 2005 at 6:28 AM 7 replies 1.4k views
Original Post
dave
dave
Hi, I know this probably should have gone in the linux forum, but i had a feeling that it might get more attention here. The problem is with curses. For a uni project we have to write a basic shell for linux and it has to have the commands 'pwd', 'cd', 'ls', 'kill' and 'ps' coded, ourselves. Well i have coded all but ls and ps and have also given it the ability to fork-exec external commands. Now the problem lies in the fact that i am writing the interface using curses. I am testing fork-exec by running the commands 'ls -l' , therefore the external command. ut the problem seems to be that since im in curses mode and since ls appears NOT to use curses, the formatting is messed up and i get staircasing of data. I have looked on various curses tutorials for this kinda thing and have turned up nothing. So somehow what i need to do is drop out of curses (which i know how to do), leave the curses output on the screen (i dont know how to do in coop with the first), have ls run without staircasing with propper formatting then lastly having curses back on and resume my shell at the bottom of the ls output. I'm pretty sure this is doable in some form, if not how ive described, but i cant figure out how. Any pointers would be greatly appreciated. ace
doynax
doynax
I don't think there is any nice solution for this problem. AFAIK Curses has to know the display's state so letting a foreign application circumvent it should mess things up.
You could write a terminal emulator for translating the external applications' output to curses calls (much like screen does), but that would involve a lot of work.

Perhaps you could gain more control by using basic termcaps directly instead? Terminals usually only need to do simple terminal manipulations anway.

I guess it'd be wise to look at the sources of some common shells too. They might've found some nice way to avoid the problem.
dave
dave
I had a long talk with my tutor and we came to the conclusion that the best way of doing it would be to pipe the output from the ls command back itno my own shell where i would print it our myself.

DOH!

ace
markr
markr
You can't really handle subprocesses' output sensibly unless you want to write "screen" which contains its own terminal emulator.

I suggest you use a curses function to put the terminal back into relatively "normal" mode, while you run the subprocess, then go back into curses mode.

The problem with this is it will obliterate the output from the command.

Therefore you might want to consider doing what most shells do - don't use curses.

Consider the following situations:
- User runs a command which does not uses curses (e.g. ls)
- User runs a command which DOES use curses (vi, pine etc)

Is your solution going to work for both of them? Unless you rewrite "screen", it is not.

If stdout is redirected into a pipe, subprocesses which expect stdout to be a terminal (e.g. ones which uses Curses themselves) will fail.

If you're happy with that, by all means use a pipe.

Mark
dave
dave
The only reason that i and several others opted togofor curses in our shells was because we wanted to be able to easily detect the arrow keys for scrolling up and down the histoy. We saw no other ways of doing this without using curses.

ace
markr
markr
You haven't heard of "getline" then?

This is what bash and others use to create a command-history and allow tab-completion etc.

Mark
jperalta
jperalta
Quote:
Original post by markr
You haven't heard of "getline" then?

This is what bash and others use to create a command-history and allow tab-completion etc.

Mark


I'm pretty sure they read each line letter by letter using getc to do tab-complettion and command-history. At least that's how Berkely 'sh' does it.
markr
markr
Apologies, my mistake. The library is called "readline", not "getline".

More info

Mark

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.