Terminal emulator from scratch.


 
Thread Tools Search this Thread
Top Forums Programming Terminal emulator from scratch.
# 8  
Old 09-01-2010
I'd start with the Simple Directmedia Layer. It's a trimmed-down interface for single-window applications that handles keyboard interfacing and graphics and multimedia in a portable way(meaning, it's usually simple to get the same program running in Windows, Linux, and other.) that's got tons and tons of examples. I'd also use the SDL_gfx library with it, because it comes with a built-in primitive ASCII font. These two things should make it a lot easier to make a program that lets letters appear on the screen when you hit keys.
This User Gave Thanks to Corona688 For This Post:
# 9  
Old 09-02-2010
Also, you might not need to bother with the virtual terminal stuff immediately. Only interactive programs like nano, su, and the like care, you could make a shell capable of simple noninteractive commands without it and add that later.
# 10  
Old 09-03-2010
I had initially planned on using Qt4 for my interface, but after reading on SDL I think i'll go that way. Allow me to ask the most pertinent question anybody undertaking such a project would like to ask. Exactly how does one execute a program from within the TE application, get the stdin, stdout and stderr of this newly executed program (my best guess for now is using some fork()ed processes) and spit this back out on my for now string variables for parsing and other processing?
I quite simply just have to know this now before I even go further. I hoped to locate a hint of this in your earlier code script but it didn't contain such a scenario. Can you point me in the right direction. Thanks
# 11  
Old 09-03-2010
Quote:
Originally Posted by howdini
I had initially planned on using Qt4 for my interface, but after reading on SDL I think i'll go that way. Allow me to ask the most pertinent question anybody undertaking such a project would like to ask. Exactly how does one execute a program from within the TE application, get the stdin, stdout and stderr of this newly executed program (my best guess for now is using some fork()ed processes) and spit this back out on my for now string variables for parsing and other processing?
Good guess.
  • Create two pipes with the pipe() call. One will be shell input, one will be shell output. Two pipes, not three -- stdout and stderr usually just go to the same output unless the shell's told otherwise. It's fine to have the same pipe opened in two or more places, the kernel will do the smart thing and merge their output and only remove the pipe when all copies are closed.
  • fork(). This creates a clone of the process differering only in the return value they see from the fork() call. The pipes will join them: write() to one end in the parent, and you can read() from the other end in the child.

    You might want to do an immediate SDL_Quit() in the child after the fork. Or even just create a process before you call SDL_Init() that does the actual shell work while the original one handles all the graphics. (At this stage though, you might not need graphics at all, just dump to shell and avoid these complications)
  • In the child process, use dup2() to replace stdin, stdout, and stderr with the appropriate ends of the input and output pipes. i.e. the writing end of the output pipe gets duplicated over STDOUT_FILENO and STDERR_FILENO, and the reading end of the input pipe gets duplicated over STDIN_FILENO. (I think STDIN_FILENO etc is available in stdio.h, and pipe() is in unistd.h)
  • In both parent and child, close() the ends of the pipe you aren't using. You don't need the copies, and they'll jam it open later if you don't close them.
  • In the child, run execv or execvp to replace the child process with the command you want to run. Something like execvp("/bin/echo", "/bin/echo", "asdf", NULL); The exec family of functions is in unistd.h
  • You now have a child process of your choosing whose input you can write to by write()ing to the input pipe and whose output you can read() by reading from the output pipe.
  • Keep read()ing output from the program until it dies, then close() both remaining pipes, and wait() for the child so it can enter the digital afterlife instead of lingering as a zombie. (see man 2 wait).
...oh, and when you initialize SDL, initialize it with SDL_INIT_NOPARACHUTE to prevent it from catching signals like SIGPIPE and SIGCHLD for you. Normally SDL catching rogue signals is a good thing, helps games not crash, but you definitely want to handle these signals in your own code for a shell.

Last edited by Corona688; 09-03-2010 at 12:36 PM..
This User Gave Thanks to Corona688 For This Post:
# 12  
Old 09-07-2010
Now we are talking. Let me see just how far I can go with this info. Thanks a tone for your help Corona688
# 13  
Old 09-13-2010
Quote:
Virtual Terminal.

A lot of terminal behavior is actually handled by the terminal device, not the user-mode program. Things like sending SIGINT on ctrl-C, EOF on ctrl-D, and so forth are handled not by your code but by kernel code controlling the device. In particular if you want programs in your terminal to get a "yes" when they ask the kernel if they're in a terminal, you'll need to use a virtual terminal. I've written a short example when I was figuring out how to use virtual terminals myself.
I have tried to wrap my mind around this particular statement. Does this mean that no terminal based programs can be run successfully from a GUI based application without some special work on the calling command e.g 'system()', or does 'system()' handle this trickery for us. Please enlighten me.
# 14  
Old 09-13-2010
Quote:
Originally Posted by howdini
I have tried to wrap my mind around this particular statement. Does this mean that no terminal based programs can be run successfully from a GUI based application without some special work on the calling command e.g 'system()', or does 'system()' handle this trickery for us. Please enlighten me.
It's not a question of GUI vs non-GUI. The difference between a "window mode" application and a "console mode" application is that the "window mode" application has extra code to talk to an X11 server. It doesn't lack anything a "console" app has.

The dilemma is terminal vs non-terminal. Commands can tell whether their stdin/stdout/stderr is attached to a terminal device or not via the isatty() system call. Nothing but a real or virtual terminal will qualify.

system() doesn't help you arrange a terminal. system() can't even capture the command's output.
Login or Register to Ask a Question

Previous Thread | Next Thread

5 More Discussions You Might Find Interesting

1. UNIX for Dummies Questions & Answers

Terminal Emulator

Hi, I was just wondering how to distinguish between the two terms: 1. Terminal emulator (vt100, vt220 and so on) 2. shell command line Then i decided to conclude myself that these 2 are very equivalent. am I right? this actually came to my mind when I was using my HP-UX terminal. I am... (1 Reply)
Discussion started by: messi777
1 Replies

2. Solaris

Tera Terminal Emulator

Hello Expert! :b: Question for you guys, Can anyone tell me how to use terminal emulator on Windows XP to view Solaris config? I have no idea on Solaris and the only thing I could do is to boot it up. Honestly, I have given a tasked to delete all the files and some necessary memory information... (2 Replies)
Discussion started by: katsloko
2 Replies

3. UNIX for Advanced & Expert Users

Filesystem from scratch

Hey, Had anyone tried with writing a new FS - file system ( whether its useful or not, that doesn't matter ) ? I tried one couple of years ago, but that was a fatal failure :( and can't continue working on it since then. :( Anybody got some experience with writing file system from the... (4 Replies)
Discussion started by: matrixmadhan
4 Replies

4. UNIX for Advanced & Expert Users

unix from scratch

hi all, i'm trying to write a unix system from scratch (not re-writing the kernel) does anyone have information about that? tips and stuff...?i would appreciate every help, thnks :) (9 Replies)
Discussion started by: elzalem
9 Replies

5. Linux

how to use terminal emulator???

hello, can any body tell how to use terminal emulator.... i want to check he serial port communication with the help of that terminal emmulator.... also tell me how to open terminal emmulator.....and how to configure it........and how to use it... I am using fedora core 6..... (1 Reply)
Discussion started by: arunchaudhary19
1 Replies
Login or Register to Ask a Question