I want to implement an overlay for terminal (to see keystrokes on a terminal session) based on Implement overlay in terminal
That was just a proof of concept what I really want is to convert input to keystrokes: Ctrl+, , , 1-9, a-z, A-Z, etc
Is there any way to process input normally and render keystrokes to stdout?
Basically I want to reimplement tee
https://superuser.com/a/557291/158200
So stdin goes to /dev/pts/ (terminal) but to my program too.
As I write this I feel that my two process involved are bash and my new program but don't know where stdin comes from
Seems whatever script does will be the answer, but isolating only stdin https://unix.stackexchange.com/a/200642/23369
Related
I have a command line program that receives interactive input.
I want to have the program backgrounded after it has read the input.
After it has read the input, it execs another program. I want to be able to control that program using shell job control.
I am lazy, so I don't want to type C-Z and bg to achieve that.
I am in control of that program (I wrote it and can change it), and it 'knows' when it should be backgrounded.
I'm sure this is achievable (for example, I guess an expect script could start my program, which could then signal its parent (expect) when it's ready to be backgrounded.
What is the best (simplest, easiest, best-behaving) way to achieve this?
Have you tried the following (Assuming bash)?
# Get necessary input
exec "/usr/bin/bash" ./AnotherScript.sh
Programs like vi, less, screen, when executed, they fill the terminal with their data, and then, if you press c - Z (or terminate the program) the terminal return as it was before the execution of these programs.
How usually a program do that? What is the correct terminology this kind of thing?
PS: The words used in the title may be not correct since I've no even idea about the terminology of this kind of things.
EDIT:
Thank to #Atropo I now know the correct name of these is foreground process,
but, how a program do that? How the program can clear the screen, do its writing and, at the end of the execution, let the shell reappear with all the old writings?
They're called foreground processes.
Usually a foreground processes show the user an interface, through which the user can interact with the program. So the user must wait for one foreground process to complete before running another one.
While you use a foreground process the shell prompt disappears until you close the process or you put it in the background.
By default CTRL-C generates SIGINT signal and CTRL-Z SIGTSTP:
https://en.wikipedia.org/wiki/Unix_signal
To change the behavior you can:
redefine or mask signal handler
disable the key combination for stdin http://linux.die.net/man/3/termios
close stdin descriptor (like daemons do)
I have a program that runs in the command line (i.e. $ run program starts up a prompt) that runs mathematical calculations. It has it's own prompt that takes in text input and responds back through standard-out/error (or creates a separate x-window if needed, but this can be disabled). Sometimes I would like to send it small input, and other times I send in a large text file filled with a series of input on each line. This program takes a lot of resources and also has a large startup time, so it would be best to only have one instance of it running at a time. I could keep open the program-prompt and supply the input this way, or I can send the process with an exit command (to leave prompt) which just prints the output. The problem with sending the request with an exit command is that the program must startup each time (slow ...). Furthermore, the output of this program is sometimes cryptic and it would be helpful to filter the output in some way (eg. simplify output, apply ANSI colors, etc).
This all makes me want to put some 2-way IO filter (or is that "pipe"? or "wrapper"?) around the program so that the program can run in the background as single process. I would then communicate with it without having to restart. I would also like to have this all while filtering the output to be more user friendly. I have been looking all over for ideas and I am stumped at how to accomplish this in some simple shell accessible manor.
Some things I have tried were redirecting stdin and stdout to files, but the program hangs (doesn't quit) and only reads the file once making me unable to continue communication. I think this was because the prompt is waiting for some user input after the EOF. I thought that this could be setup as a local server, but I am uncertain how to begin accomplishing that.
I would love to find some simple way to accomplish this. Additionally, if you can think of a way to perform this, do you think there is a way to also allow for attaching or detaching to the prompt by request? Any help and ideas would be greatly appreciated.
You could create two named pipes (man mkfifo) and redirect input and output:
myprog < fifoin > fifoout
Then you could open new terminal windows and do this in one:
cat > fifoin
And this in the other:
cat < fifoout
(Or use tee to save the input/output as well.)
To dump a large input file into the program, use:
cat myfile > fifoin
I'm building an application in PostScript that needs to take input fom the user at a prompt (I will be using the GhostScript executive, and the file won't be sent to the printer). I can't see anything in my PostScript Language Reference Manual that suggests this is possible, and I don't want to drop back to the executive, so is this possible?
It's not that hopeless! But it ain't exactly easy, either. There are two other special files besides %stdin that you can read from. (%lineedit)(r)file dup bytesavailable string readstring pop will read a line from stdin into a string. There is also the (%statementedit) file which will read until a syntactically valid postscript fragment is typed (plus newline). This will match parentheses and curlies, but not square brackets. Before reading, you should issue a prompt like (> )print flush.
One more thing, you can catch ^D by wrapping all this in a stopped context.
{ %stopped
(> )print flush
(%lineedit)(r)file
dup bytesavailable string readstring pop
} stopped not {
(successfully read: )print
print
}{
(received EOF indication)print
}ifelse
Instead of popping that bool after readstring, you could use it to cheaply detect an empty input line. Note also, that the stop that triggers on EOF is from an error in file (ghostscript calls it /invalidfilename), but although file is defined as an operator, and operators are supposed to push their arguments back on the stack when signaling an error, I've noticed ghostscript doesn't necessarily do this (I forget what it leaves, but it's not 2 strings like you'd expect), so you might want to put mark in front and cleartomark pop after this whole block.
The special files (%lineedit) and (%statementedit), if available, will successfully process backspaces and control-U and possibly other control. I believe real Adobe printers will respond to ^T with some kind of status message. But I've never seen it.
PS. :!
I've got a more extensive example of interactive postscript in my postscript debugger. Here's a better version of the debugger, but it's probably less useable as an example.
PostScript isn't designed as an interactive language, so there is no great provision for user input.
You can read input from stdin, and you cat write to stdout or stderr, so if those are wired up to a console then you can theoretically prompt the user for input by writing to stdout, and read the input back from stdin.
Note that reading from stdin won't allow the user to do things like backspace over errors. At least not visually, the data will be sent to your PostScript program which could process the backspace characters.
That's about the only way to achieve this that I can think of though.
Is there a terminal program that shows the difference between input, standard output, error output, the prompt, and user-entered commands? It should also show when standard input is needed vs. running a command.
One way would be to highlight each differently. The cursor could change color depending on if it was waiting for a command, running a command, or waiting for standard input.
Another way would be to have 3 frames -- a large frame on the top for output (including prompt and commands running), a small frame near the bottom for standard input, and an one-line frame at the bottom for command line input. That would possibly even allow running another command to provide input while the previous command is still waiting for standard input.
From http://jamesjava.blogspot.com/2007/09/terminal-window-with-3-frames.html
Hotwire could be a good candidate, but it's not doing that out of the box, AFAIK
For now it appears that there is no such program.
My program gush (Graphical User SHell) does part of this.
It uses different colours for commands and program stdin/stdout/stderr.
Note that the traditional separation of shell and terminal makes this
impossible because the interface between them models an old serial
terminal connection and therefore only has a single input and single
output channel. I get around this problem by combining shell and
terminal into one program.
It would be nice to also indicate when a program is waiting for input,
but I don't think there's any way to detect this, unless you traced the
system calls of the child program to detect when it tries to read stdin.
For interactive programs, you can guess that if the last output did not
end with newline it's probably prompting for input, but this would not
work for non-interactive programs, eg. sed.