[clug] copy/paste of commands, tabs & bash's $'\t'. Any better solutions?

[Brenton Ross]

See end

On Tue, 2019-06-18 at 14:57 +1000, steve jenkin via linux wrote:
> One of the problems I have with copy/paste between terminal screens or file is losing tabs.
> They get converted to spaces, which is rarely good.
> 
> sort & other programs take a “-t” option as the field separator.
> 
> 	sort -t’	‘ xxx (field sep is tab)
> 
> transforms after it’s journey through the copy/paste buffer into:
> 
> 	sort -t '      ‘ xxx (field sep is multiple blanks)
> 
> Which is an error.
> 
> I’ve lately read the man page and $’\t’ expands to a tab.
> 
> Can’t, AFAICS, be enclosed in soft-quotes:
> 	 “$’\t’” doesn’t work
> 
> This version will survive a journey through the copy/paste buffer.
> 
> 	sort -t $’\t’ xxx (tab as field sep)
> 
> It’s slightly cumbersome, but at least it works.
> 
> Anyone got a better solution.
> 
I just did a few experiments.
It appears to be a function of the source program rather than the cut-n-paste system or the target program.

When copying from gnome-terminal the observed behaviour is confirmed, however if you copy from a 
text widget in a Qt GUI program the tabs are preserved. Of course the tabs get interpreted by the bash interpreter if you 
paste on to the command line, but works OK for pasting into vi, for example.

I tried the epad editor and that seems to preserve tabs when copying.

It appears that the problem occurs when the target and source decide that UTF8_STRING is the format to use.
The recommendation in an early draft (all that I could find) was that tabs should be translated to spaces
by the source program but the target should be prepared to accept tabs. [All other control codes are discarded, 
apart from line feed.]

A useful program for examining the clipboard and for interfacing between GUIs and the command line is xclip.

I suppose the take-away is that copy-n-paste of strings containing tabs cannot be relied upon.

Brenton