Empty options get reverted to default

[johnadamson]

Using Clipper with Windows Subsystem for Linux (Bash for Windows) requires an executable value of /mnt/c/Windows/System32/clip.exe and no flags.

WSL reports as Linux, and gets the default flag of -selection clipboard. When providing an empty flag -f via config or cli, the empty value gets reverted back to the default by https://github.com/wincent/clipper/blob/master/clipper.go#L188.

On my local version, Clipper works correctly in this environment when the else branch of that condition is removed. Is there a reason for normalizing empty options?

[wincent]

Thanks for bringing this up, @johnadamson.

Is there a reason for normalizing empty options?

Nope, it's just an edge case that I hadn't considered. It seems quite reasonable that you should be able to explicitly set an empty flag and not have it revert to the default.

[dennistang]

@johnadamson do you get issues with [ERROR] pipe copy: write |1: broken pipe when using clipper with WSL?

I've had to introduce a deadline to conn to get it to work. If I don't I'll get either the broken pipe error or [ERROR] pipe copy: read tcp4 127.0.0.1:8377->127.0.0.1:62851: i/o timeout

I'm not very familiar with golang, but the errors lead me to think it may be an issue with WSL's I/O performance.

Happy to open another issue for this, but I thought I'd ping someone who was also a WSL user.

[johnadamson]

@dennistang Apologies for the late reply. I am a user of all platforms, though I've mostly used macOS the last year. So, my recollection is vague on the exact error when I reported this issue: #11. Yet, I remember the connection would hang immediately, and indefinitely without it.

This is off topic for this thread, but in the spirit of collaboration, there's also a different hang I've seen which occurs when piping into clip.exe after maybe a dozen invocations. As soon as this phenomenon manifest, I would need to kill WSL completely to restore the ability to pipe from Linux. Restarting the clipper daemon had no effect. Piping into clip.exe by any method, clipper or not, would indefinitely result in a hung process.

I'd be curious to know if you've seen this. I don't believe this to be anything with clipper and more to the I/O with the Linux subsystem.