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.
