Re: bash doesn't display tabs for tabs -- ignores tabstops.

[Greg Wooledge]

On Wed, Apr 24, 2013 at 08:02:29PM -0700, Linda Walsh wrote:
>       My terminal is displayed via 'X' --- X pics up
> the actual characters that were echoed to the screen.  If TABS are
> used, it put's TABS in the copy/paste-buffer.

That is not how my terminal works.

imadev:~$ echo $'tab>\t<tab'
tab>    <tab
imadev:~$ od -t x1
tab>    <tab
0000000   74  61  62  3e  20  20  20  20  3c  74  61  62   a
0000015

This is in rxvt (not rxvt-unicode), on HP-UX 10.20.  I triple-left-clicked
the line that the shell produced, then typed the od command and pressed
Enter, then pasted the line by pressing the middle mouse button, then
pressed Ctrl-D.

SOME terminals may remember whether a tab character was used to move
the cursor around, and may then decide to tell the X libraries, when
they ask, that the selection string should contain a tab rather than
a bunch of spaces.

Other terminals -- in my limited experience, virtually all of them --
do not.  They don't retain such information, so when the X libs ask
what string to put into the selection, those terminals simply report
back a bunch of spaces.  You can see this in the od output above.

> If some lame application
> substitutes some other character for tabs, it will pic up the wrong value.

The application in this case is the TERMINAL, not the shell.  Or, as
you point out, the COMBINATION of the terminal plus the shell, since
BOTH of them must handle tabs in the way you desire for that feature
to work.

But this is getting farther and farther off topic.  Bash has nothing
to do with the pasting of stuff from an X client application (terminal,
web browser, etc.) to another X client application.

> It uses the curses library.  The code has references through-out that look to
> see what column it is in.   Bash has builtin features in the prompt-build
> feature, to help it determine the correct column so it knows when to wrap your
> cursor -- and it knows when to wrap output.
> 
> The same library it uses to keep track of that can tell it what the tabs
> stops are -- either directly or indirectly.

If you say so.

>       Imagine that you have a terminal where people paste intput from X.

Already refuted above.

> Ok.. not hard at all to image where the TABS come from.  Imagine that they
> can invoke a full-screen oriented editor like emacs or vim to edit a line --
> and that they are used to tabbing over when indenting code.

You can repeat this demonstration from within an editor instead of
a shell.  It's difficult to render such an experiment within an email
message.  If you're willing to take my word for it, I performed the
following steps:

In rxvt window 1:

imadev:~$ echo $'tab>\t<tab' > foo
imadev:~$ /usr/bin/vi foo

Triple-left-click the line with the mouse, populating the X selection
buffer.

In rxvt window 2:

imadev:~$ od -t x1
tab>    <tab
0000000   74  61  62  3e  20  20  20  20  3c  74  61  62   a
0000015

Just as before, the X selection buffer is filled with spaces, not a tab
character.

I repeated the experiment with vim instead of /usr/bin/vi and still
got the 20 20 20 20 output.

>       So If a users terminal uses "." -- it would be ok for bash to display
> "dot", instead of the actual character?

Straw man argument.

> As for how hard it would be to find out the current tab setting?
> 1) allow the user to specify a tab settting in the ENV... like "duh? -- you 
> mean

None of this makes any sense at all.  Bash must work in the real world,
not in some alternate universe where things are implemented differently.
How would an environment variable possibly stay in sync with a terminal's
internal state, anyway?

> #console_codes(4) man page...

Is specific to ONE terminal emulator.  There are many others that do
not work the same way.  Plus there are real hardware terminals, and most
of them are VERY quirky.

If you think Bash is misbehaving, submit a patch, or wait for Chet to
comment on one of these threads.