Package: xsel Version: 1.2.0-1 Severity: important Hi,
when the selection is larger than 4000 bytes, xsel gives sometimes the expected output with trash appended, sometimes no output at all, in a nondeterministic way. Expected behaviour with 4000 bytes of input: $ yes a | tr -d '\n' | head -c 4000 | xsel ; xsel | wc -c 4000 Now run with more than 4000, a few times to see different error kinds: $ yes a | tr -d '\n' | head -c 4001 | xsel ; xsel | wc -c 0 $ yes a | tr -d '\n' | head -c 4001 | xsel ; xsel | wc -c 4009 I looked into the code and there is actually a 4000 hardcoded in it. It is the largest property size that can be transmitted in one event. The bug must hide somewhere in the handling of the incremental retrieval. I've not tried hard, so didn't find the bug. -- While at it, I found that the program is in a bad state unfortunately. Some examples which turned up in short time: Memory management is broken, so it's not debuggable using valgrind. The get_homedir() function returns a char * either to an environment variable or to strdup()ed memory. There are a few locations where the program sometimes allocates 0 bytes and then aborts thinking something went wrong (I've reproduced it). These are mostly of the fixable sort, but they also serve as a good illustration of the program state... Another problem is that selections are represented as char * so the following behaviour isn't surprising: $ head -c 42 /dev/zero | xsel ; xsel | wc -c 0 Replace by xclip -i / xclip -o to get the expected 42. Maybe this package should be deprecated? xclip seems to work better in half the lines of code. I don't think xsel does a reliable job and it is very large for what it does. I feel unsafe having relied on it during several years. Jens -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
