Re: bash doesn't display user-typed characters; can interfere with COPY/PASTE
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.
Re: bash doesn't display user-typed characters; can interfere with COPY/PASTE
On 2020/12/08 06:28, Greg Wooledge wrote: The end result is that it's basically impossible to preserve the original whitespace of your source material across a terminal copy/paste operation. So don't count on that. If you use a random terminal to copy/paste, sure, but if you use a specific product that maintains fidelity, then it's not true. Especially nice are term-progs that automatically reflow text *as you resize* the terminal. Like if you see 100 characters written to an 80-column terminal, that line wraps the text, when you expand the width, you retain the original white space. That's why programs that don't preserve what you wrote are annoying. And note -- you see the reflow in real-time as you change dimensions -- not just at the end. Imagine working on a terminal that only displayed upper case even if the differentiation was saved when stored. You can't really see the text as "it is" when you enter it or re-edit it. With it putting in something different on display than what is really there, you get things like (tab chars between each letter): echo "a b c d e f g h i j k l m n o p q r s t a b c d e f g h i j k l m n o p q r s t" a b c d e f g h i j k l m n o p q r s t a b c d e f g h i j k l m n o p q r s t If you re-edit a line with tabs in it that displays like it does in the bottom line, above (tabs ever 2 spaces), the re-edited "line" takes up 4 lines.
Re: bash doesn't display user-typed characters; can interfere with COPY/PASTE
On Tue, Dec 08, 2020 at 09:07:33AM -0500, 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. In addition to what I said earlier, there is a distinction between things that you *typed* in bash/readline, and then tried to copy with the mouse, and text that was generated by a command (e.g. cat yourscript), which you then tried to copy. And if you're actually typing in a text editor, rather than in bash, then obviously the behavior of the editor is what matters. The end result is that it's basically impossible to preserve the original whitespace of your source material across a terminal copy/paste operation. So don't count on that. There's a *reason* bash introduced the $'\t' quoting. Use it, rather than using literal tab characters.
Re: bash doesn't display user-typed characters; can interfere with COPY/PASTE
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. 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. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: bash doesn't display user-typed characters; can interfere with COPY/PASTE
On Tue, Dec 08, 2020 at 08:07:18PM +0700, pepa65 wrote: > On 08/12/2020 19.55, Greg Wooledge wrote: > > Some terminals, when fed a tab character, will preserve that knowledge > > in memory; then, when you copy text from that part of the terminal > > window using your mouse, the terminal will put a tab byte into the > > selection/clipboard. > > Interesting! Which terminal does that?? It seem that ``gnome-terminal'' and ``mate-terminal'' do so. while ``xterm'', ``rxvt'' and ``konsole'' does'nt. -- Félix Hauri -- http://www.f-hauri.ch
Re: bash doesn't display user-typed characters; can interfere with COPY/PASTE
On 08/12/2020 19.55, Greg Wooledge wrote: > Some terminals, when fed a tab character, will preserve that knowledge > in memory; then, when you copy text from that part of the terminal > window using your mouse, the terminal will put a tab byte into the > selection/clipboard. Interesting! Which terminal does that?? (Slightly OT?) Peter
Re: bash doesn't display user-typed characters; can interfere with COPY/PASTE
On Mon, Dec 07, 2020 at 05:02:35PM -0800, L A Walsh wrote: > If I type in ( + are keypresses) > > if [[ '' == $'\t' ]]; then echo ok; else echo notok; fi > > bash displays: > > if [[ ' ' == $'\t' ]]; then echo ok; else echo notok; fi > ok Bash doesn't "display" things. Your terminal displays that. > if I now copy the 'if' line and paste it > > if [[ ' ' == $'\t' ]]; then echo ok; else echo notok; fi > notok Some terminals, when fed a tab character, will preserve that knowledge in memory; then, when you copy text from that part of the terminal window using your mouse, the terminal will put a tab byte into the selection/clipboard. Other terminals, when fed a tab character, will just dump out a bunch of spaces, and will not remember that there was originally a tab character as part of their input. Then, if you copy that part of the text, you'll just get a bunch of spaces instead of the original tab character.
Re: bash doesn't display user-typed characters; can interfere with COPY/PASTE
Just use history or fc -l to display the line as is. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: bash doesn't display user-typed characters; can interfere with COPY/PASTE
On 08/12/2020 01:02 am, L A Walsh wrote: If I type in ( + are keypresses) if [[ '' == $'\t' ]]; then echo ok; else echo notok; fi bash displays: if [[ ' ' == $'\t' ]]; then echo ok; else echo notok; fi ok if I now copy the 'if' line and paste it if [[ ' ' == $'\t' ]]; then echo ok; else echo notok; fi notok if I take the same line from an editor like gvim, it works. If the test line is in a file, and I use 'cat file' and copy/past the resulting line, it works. It is only when bash is displaying the line that it doesn't work. The problem is that bash isn't displaying a 'tab' character where one was typed. 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. Can this be fixed -- maybe with an option in 'shopt', for those who might be using a non-expanding terminal, but anyone using an xterm/linux compatible terminal should get the expansions from their terminal. Where this can be even more annoying is if your terminal's response to a tab is different than that used on old-hardware terminals. Thanks, -l Try Ctrl-V before hitting . -- Chris Elvidge England
bash doesn't display user-typed characters; can interfere with COPY/PASTE
If I type in ( + are keypresses) if [[ '' == $'\t' ]]; then echo ok; else echo notok; fi bash displays: if [[ ' ' == $'\t' ]]; then echo ok; else echo notok; fi ok if I now copy the 'if' line and paste it if [[ ' ' == $'\t' ]]; then echo ok; else echo notok; fi notok if I take the same line from an editor like gvim, it works. If the test line is in a file, and I use 'cat file' and copy/past the resulting line, it works. It is only when bash is displaying the line that it doesn't work. The problem is that bash isn't displaying a 'tab' character where one was typed. 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. Can this be fixed -- maybe with an option in 'shopt', for those who might be using a non-expanding terminal, but anyone using an xterm/linux compatible terminal should get the expansions from their terminal. Where this can be even more annoying is if your terminal's response to a tab is different than that used on old-hardware terminals. Thanks, -l
