On 2020/12/08 06:07, Chet Ramey wrote:
On 12/7/20 8:02 PM, L A Walsh wrote:
The problem is that bash isn't displaying a 'tab' character where
one was typed.
It's readline and redisplay. Readline expands tabs to spaces using an
internal tab stop of 8. This allows it to be sure of the physical cursor
location, especially when you're doing things like wrapping lines, and
insulates it from varying terminal behavior.
*snark* That's nice, why not just display 'X' instead of spaces? Wouldn't
that also insulate readline from varying terminal behavior? *not really,
but...*
I'm not sure it is the place of a an in-line-editor to override terminal
features.
However, as readline is an editor and most editors allow setting the
tabs (as well as
whether or not to use hard-tabs or expand them). If readline has to
"insulate",
just like vi/vim -- have the tabstop and whether to expand be in a startup
file like .inputrc. Right now, .inputrc has the facility to define how
characters
are to be interpreted. Why not put the option to expand w/spaces in
there, as well
as what a tab character expands (or maps to).
Bash also overrides existing standards with regards to tabs wrapping.
It seems that
many or most terminals (xterm compat, linux console-compat, etc) don't
wrap to the
next line when a tab is pressed. The reasoning for that was that tab was
supposed to
skip to the next field in the same line. Wrapping is beyond the scope
of function
for tabbing.
With many (most?) terminal windows these days, especially
Unicode-enabled ones, the terminal has to read what is on the screen to
be able to read the binary code of whatever is displayed on the screen,
Otherwise, it wouldn't be able to read typed unicode.
This is not relevant to the issue.
----
It was meant to illustrate that terminals are using the binary
representation
of the characters typed -- and that arbitrarily changing the binary
representation
(like tabs->spaces) will mess up / corrupt the user's output stream.
