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

[steve jenkin]

Brenton,

great piece of research - definitive answer on copy/paste buffers.
 - xclip and the internal formats (UTF8_STRING) is stuff I didn’t know.

Thanks very much for your useful response. Not just for me, but others that don’t yet know they have the question.
I imagine ppl in the future searching and finding your nice test & explanation - it’s not just list subscribers that will read posts.

cheers
steve

> On 18 Jun 2019, at 17:00, Brenton Ross via linux <linux at lists.samba.org> wrote:
> 
> 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

--
Steve Jenkin, IT Systems and Design 
0412 786 915 (+61 412 786 915)
PO Box 38, Kippax ACT 2615, AUSTRALIA

mailto:sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin