wl-copy of one character without newline is unpastable

[arcxio]

if I wl-copy one character without newline (echo a | wl-copy -n or trimming manually echo a | tr -d '\n' | wl-copy), I cannot paste this character.
wl-paste also doesn't append newline without -n:

~$ wl-paste
a~$

while it does when two or more characters without newline were copied:

~$ echo aa | wl-copy -n
~$ wl-paste
aa
~$ 

[bugaevc]

Hi,

please mention which Wayland compositor you're getting this on. Are you perhaps using some clipboard manager that could be messing things up here?

echo a | wl-copy -n or trimming manually echo a | tr -d '\n' | wl-copy

You should be able to just use echo -n a, no need for tr 🙂. You can also just use wl-copy a.

I cannot paste this character.
wl-paste also doesn't append newline without -n

~$ wl-paste
a~$

So you can paste it, at least with wl-paste? But not into some other client(s)? Which one(s) are you trying to paste into?

wl-paste not appending a newline (without it being explicitly requested with --no-newline) can only happen if it thinks your selection type is binary, not textual. That would also explain other clients refusing to paste it. What does wl-paste --list-types say for your single-character copies? Are you using the real xdg-mime from xdg-utils, or some replacement version? (which one?)

[arcxio]

please mention which Wayland compositor you're getting this on

sway

Are you perhaps using some clipboard manager that could be messing things up here?

nope. does it not reproduce on your end?

You can also just use wl-copy a.

that works. I can do this without issues:

~> set tmp (echo -n a)
~> wl-copy $tmp
~> wl-paste
a

seems to be the problem with reading from a pipe

So you can paste it, at least with wl-paste

technically, but with a twist that wl-paste should include a newline by default and it doesn't. I included this example to demonstrate that it's bugged.

What does wl-paste --list-types say for your single-character copies

~> echo -n a | wl-copy
~> wl-paste --list-types
application/octet-stream

indeed, binary not textual

Are you using the real xdg-mime from xdg-utils

yes

[bugaevc]

nope. does it not reproduce on your end?

No.

sway

So, this might explain it. The compositor itself is not involved; we query the file type using xdg-mime query filetype, and on my end here, it does print text/plain:

$ echo -n a > test
$ xdg-mime query filetype test
text/plain

but, xdg-mime is actually a shell script which delegates to a DE-specific backend. Under GNOME here, it calls into gio info. Without a DE, it must be doing, well, something else, which is why you'd get different results.

If what you're doing is writing a shell script that uses wl-copy, why don't you pass --type text/plain explicitly?

seems to be the problem with reading from a pipe

It's just that when you pass the text to wl-copy in its argv, it treats it as textual by default, whereas for data read from stdin it runs xdg-mime to figure out the MIME type.

[arcxio]

Without a DE, it must be doing, well, something else, which is why you'd get different results

I've looked into it, without a DE xdg-mime tries to call mimetype if it exists (it didn't, but it reports text/plain correctly), and finally falls back on file otherwise - which is the actual cause of the issue:

~> file --brief --dereference --mime-type test
application/octet-stream

If what you're doing is writing a shell script that uses wl-copy, why don't you pass --type text/plain explicitly?

yeah, that solves it for me, thanks!