I must embedd the shell of an interpreter language (most likely it will be python) inside my application. So i need a console widget in my GUI toolkit. I want to write this from ground up myself.
I know that i must start the process with pipes redirecting the standard input/output/error to my console widget. I have to set the environment variable TERM=vt100 and send a SIGWINCH signal whenever i resize my terminal.
For the output of the program i have to check the octet stream for vt100 control characters as explained here VT100 commands.
This sounds to be easy and a nice weekend hack.
But what do i do about the input? Who is responsible for echoing the characters and the line mode editing?
Do i miss something else which is serious?
To control the input in console, you have set it to canonical mode. Please check this like link, it may help you:
Canonical vs. non-canonical terminal input
Related
Program that I write often crashes leaving terminal in a S-Lang library state (similar to ncurses). I would want to add a check into development's branch Makefile main all target for such an improper state and and an automatic invocation of reset command. How to approach this task?
reset does two things; you can write a shell script which detects one of them:
it resets the terminal I/O modes (which a shell script can inspect using stty)
it sends escape sequences to the terminal (which more often than not will alter things in the terminal for which there is no suitable query/report escape sequence).
For the latter, you would find it challenging to determine the currently selected character set, e.g., line-drawing. If the terminal's set to show line-drawing characters, that's the usual reason for someone wanting to run reset (e.g., cat'ing a binary file to the screen).
There happens to be a VT320 feature (DECCIR) which can provide this information (which xterm implements):
but with regard to other terminals, you're unlikely to find it implemented:
(iTerm2 doesn't do it)
(nor does VTE). You can read an extract from the VT510 manual describing the feature on vt100.net
I'm trying to build a GUI wrapper over an external command line application. Everything is fine until this application wants to get an input from user. How to know if the process is asking for an input? For example, so I could show the GUI input dialog for the end user.
Also, the fact is I don't need this input functionality at all, so it would also be fine to simply omit / suppress the input.
I am using QT under windows and have an application where I want to use the arguments to determine if this comes from a bat file and so all data is in the arguments, or if it should pop us the menu window to allow the user to input the data.
Any examples of how to do this?
Thanks
Simply don't create or show the QMainWindow
There are a few extra complexities about event loops and signals/slots. There is also an issue on Windows that whether the create a console or not is a linker not a runtime option.
See How do I create a simple Qt console application in C++?
I think you want to check if your application is lauched with command line argument or not. If not then display some dialogbox to get input.
main function of c++ program has two argument, first is the number of arguments and other is an argument array. you can use these two parameters to decide it you got the command line parameter the from user or not.
I have several question:
If there is an error which has to be displayed to the client - It is a good thing to use STDERR stream instead of STDOUT? Or is it a trivial issue?
I want to add color support to output messages of this utility. Do I have to use some environment-tolerant framework for that?(it can be 256 color mode and "pure" one). Or how to make it tolerant?
I'm afraid to add colors to the output because clients may redirect output to log file. Can it potentially "break" anything because of that?
Please help me to build this utility in UNIX-way(Do one thing and do it well).
STDERR is better than STDOUT for errors for a couple of reasons. Redirecting the output won't hide the errors from you. You can prevent warnings from mixing with the output which makes it easier to parse/process in some cases.
You may want to look into the curses library which should support the ANSI color sets.
Utilities like ls will detect if their output is being redirected and drop the color codes so that log files, etc. don't get horked up. You should do the same.
Use STDERR. As for the colors, your concern can be alleviated by checking if the output is a tty before printing colors to it. During initialization, have a check that enables or disables colors on the fly. It's also good practice to have a --color=[on|off|auto] flag that a user can pass to select one explicitly.
I am implementing my own shell. But to supprt for command history, I need to use monitor up/down arrow key as in standard shells. Please tell me how to handle arrow keys as input or does these keys generate signals? Please elaborate.
Arrows and other special keys send you special strings that depend on the terminal being used or emulated. To deal with this most simply, you could use a library such as termcap. Even simpler, given your stated purpose (command history support), would be to use readline, which basically does it for you (and lets the user customize aspects of their preferred mode of working across the many applications that link to the same library).
It depends on how gnarly you're expected to go. Worse case, you're writing the keyboard interrupt handler. Best case, something like readline.
Check with your prof for direction here. Also check your course materials to see if the prof has given links/examples regarding this.
Does the assignment specifically say you need to have a "cursor key driven" command history?
Simple option is to mimic the shells fc e.g.
$ ls
... file listing ...
$ fc -l
1 ls
2 fc -l
$ fc -r 1
... file listing ...
and (while I'm presenting established ideas as my own, might as well go all the way) to be able to edit the command line you could use
fc -e start end
to write the history from start to end into a file, launch an editor and then execute the resulting file as a script. This way your shell is not using a library, but launching commands and executing scripts, which is what shells are supposed to do anyway.