The context
We have a 9-line Braille display (Canute 360) which is exactly emulating the visual output of a terminal window. Both the Braille display and the gnome-terminal window are 40 characters wide and 9 lines long so the Braille display should be able to exactly mimic^1 the visual terminal window.
You should not need to understand Braille displays or BRLTTY to help with this query. I am looking for a solution in the shell and will try to explain the screen-reader part as well as possible.
^1: (Exactly mimic when using a one-to-one Braille conversion table.)
The problem
In the gnome-terminal, when a line goes over 40 characters is wraps to the next line. BRLTTY doesn't know it has wrapped and so that line overflows off the edge of the display and is either cut off or the whole display pans over.
This command:
$ echo "12345678901234567890123456789012345678901234567890"
Renders like this on the gnome-terminal:
$ echo "12345678901234567890123456789012
345678901234567890"
1234567890123456789012345678901234567890
1234567890
$
But like this on the Braille display:
$ echo "12345678901234567890123456789012
1234567890123456789012345678901234567890
$
Evidently the wrapped line is actually all one line as BRLTTY sees it. The wrapping is presentational.
What is the intended outcome?
A way of actually hard wrapping those lines so that the Braille output looks like this:
$ echo "12345678901234567890123456789012
345678901234567890"
1234567890123456789012345678901234567890
1234567890
$
... without editing BRLTTY. I am looking for a solution that works with the current expected behaviour of BRLTTY.
Alternative, less desirable but workable outcome
Stopping the lines from wrapping in gnome-terminal, so the visual gnome-terminal looks like this:
$ echo "12345678901234567890123456789012
1234567890123456789012345678901234567890
$
For the applications I am working on I can work with that if that is the simpler solution.
What I've tried
Screen or shell within a shell
I thought running screen might work because the shell within a shell would hard wrap the lines and BRLTTY would therefore read them as separate lines, but it makes no difference.
Running screen as a very wide shell within a shell did work to a degree, but then certain applications don't know to wrap at 40 characters. Currently applications like less, micro, pico, mc work fine on both the Braille display and the visual terminal. That would break if we make it very wide.
I tried sshing into a server to see if that would give hard line breaks but it didn't.
However I wonder if this approach might have legs, if I understood better how the shell and terminal work together.
Horizontal-scroll-mode
I've tried changing set horizontal-scroll-mode on in /etc/inputrc and that changes the prompt line to behave like the alternative, less desirable approach as above. However it doesn't change how the printed lines display.
Thoughts
- I am open to trying different shells/terminal emulators.