[SOLVED] Strange xsel bug when run as shortcut?

[chconnor]

Howdy -- I make this script:

#!/bin/bash
touch /tmp/begin
xsel > /tmp/middle 2>&1
touch /tmp/end​

...if I run that from a bash command line, the files begin, middle, and end all appear in /tmp as expected.

If I configure that as a custom shortcut in KDE, with the Action like "~/bin/mytestscript", and fire the shortcut, I see only /tmp/begin and /tmp/middle. It's as if xsel is crashing out and taking the bash script with it. I see nothing in journalctl or dmesg when this happens.

Anything I can do to debug further? E.g. a way to run the script manually that more faithfully recreates how it is run from a shortcut?

For the purposes of bug reporting, should I start by assuming this is an xsel bug?

Thanks for any ideas.

[jlittle]

tl;dr add -o to the xsel command.

For the purposes of bug reporting, should I start by assuming this is an xsel bug?

For such an ancient command, forty years old I guess, any behaviour, regardless of how much a misfeature that behaviour may be, is unlikely to be considered a bug.

For your script, I speculate that where the man page says "Without this (the --nodetach) option, xsel will fork to became a background process" is happening. When run from a konsole, konsole itself is doing something to the selection causing xsel to exit; when run from a custom shortcut, xsel is becoming a background process, channelling your script's standard output, or something. If I pressed the shortcut 4 times, I got 4 xsel processes just hanging around, and the "end" file was not written to. Adding "-o" stopped this.

Note that no line terminator is output to xsel's output.

I debugged with

#!/bin/bash
function dt () {
date +"%F-%T.%N $*"
}
dt begin >> /tmp/begin
xsel -o >> /tmp/middle 2>&1
dt ending >> /tmp/end​

With the timestamps and appending to the files (that is, using ">>") I could follow what was going on.

[chconnor]

That was totally it, thanks! Didn't notice the xsel process was still hanging around.