I am looking for a terminal on Ubuntu Desktop (or Windows) that can split input and output in different windows. Like a split window, on the left side I type all the commands, the results will be displayed in the window on the right side.
I've been seaching for this for a long time and so far I have not found anything can do such.
Any good suggestions?
I don't know of a dual-pane terminal window but I can tell you how to send the output to another open terminal window. Open two terminal windows and in the second, use the tty command. The result will be something like /dev/pts/1.
Back in the first window, type your command and send the output to the second window.
For example, $ls > /dev/pts/1.The result will show up in the second window.
I managed to produce this output without any special software. I did the following -
Opened up 2 windows. (The left I will use for input, the right for output)
In the right hand window I created a named pipe with the below command (I used /dev/shm because that is shared memory but I could have just as easily put it somewhere else, and the output filename is arbitrary).
mkfifo /dev/shm/test.fifo
In the second window I then issued a command to read the pipe -
tail -f /dev/shm/test.fifo
On the left side I typed the below to create a bash shell whose contents was sent to the FIFO file which was read by the fifo. This will push stdout to the fifo. This seems to leave the command prompt on left window
bash > /dev/shm/test.fifo
Alternatively, to output both stdout and stderr (this removes the command prompt on the left window)
bash > /dev/shm/test.fifo 2>&1
You can type exit to close the bash shell, to stop catting the output and rm /dev/shm/test.fifo to remove the named pipe.
I would love to see a mockup (maybe a pencil drawing on a piece of paper) how you imagine this to look like.
How would the inputs and the outputs be paired up? What would be displayed on the left side if the output is quite long? How would it not result in an enormous waste of precious screen space? (Or would it?)
How would it look like when you have an interactive application (e.g. text editor) running?
What do you exactly consider "input" vs. "output"? For example, is the shell prompt "input" or "output" according to your idea? If you press Ctrl+R and the shell displays (reverse-i-search), where does it belong? These are strings output by your shell, so strictly speaking you said you'd want them in the right column. But if they're displayed there then editing the command line would work quite silly, so I'd rather expect you'd like to see it in the input pane...
The reason that there's no such terminal is probably partially some of the above (e.g. figuring out how to use the space efficiently), but mainly that the notion of input and output are quite different from how you imagine them to be.
In fact, everything that a terminal displays is the output of some other component (sometimes an application, sometimes the kernel). The keyboard input (which I presume you refer to by "input") is never(*) directly displayed by the terminal.
((((*) Strictly in parentheses, just for technical correctness: a few terminals implement a mode when the input is displayed immediately by the terminal, but it's hardly, if ever, in use in practice. It's a legacy we've left behind decades ago. Forget that I said anything here.)))
Depending on what application is running in the terminal emulator and what context that application is in (e.g. you're typing a command line), if you press a certain letter, let's say you press the letter x, the response may or may not be a letter x appearing. But it's never because the terminal decides to paint the pressed letter. It's because the terminal forwards that letter to the kernel, which may respond itself or may forward it to an application, which may respond, and that response may be (but is not necessarily) to print the letter x, which then causes the terminal to paint the letter x.
The differentiation that you imagine between the input and the output of the terminal is not what it has. The input is a keypress that it forwards but doesn't display. Everything that the terminal displays is the output of the kernel or an application (nitpicking: which is an input to the terminal, not from the user but from the application, but this is what we usually refer to as "output", i.e. looking at the story from the kernel's or application's point of view).
What I presume you'd like to have split into two panes are the command line (prompt and the command you're editing) versus the command's output. The terminal emulator could not automatically make such distinction, it has no idea whether the received data was sent by the shell (command line handler) or by an application; in fact, a terminal emulator has no idea what a shell is. All it sees is a single stream of instructions. The prompt, and then if you're typing "ls" then the letters "l" and "s", and then if you press Enter then the file listing all arrive in the same single stream, and the terminal treats them all equally because that's what it has to do, and because even if it wanted to it had no clue how to separate them into multiple kinds of data.
What you would like to have would require some kind of splitting. Either escape sequences in this stream that tell the terminal which side to print the data to, or two separate tty lines and then support from the shell to print the prompt and the command line into one tty line and connect the application's output to another – coupled up with a terminal application that displays two terminals next to each other and launches that special shell in a way that it's connected to both of these terminals.
I'm fairly confident that what you wish to have doesn't exist. Reasons include that it's not a commonly sought feature, that it would need cooperation between multiple crucial components (therefore it's unlikely that one person would quickly implement it and gain some popularity), that it would likely result in large unused screen area, and that the whole concept of terminal input and output (that I believe you fundamentally misunderstand) aren't built up in a way that could easily accomodate support for this feature.
My best recommendation is to get used to how existing terminals and shells work. Feel free to play around to find your preferred shell and customization thereof, make the prompt and the command line stand out or blend in the context as much as you wish to (e.g. using colors, bold or italic typeface, special Unicode characters, possibly multiline prompt etc.).
