10000 Empty options get reverted to default · Issue #15 · wincent/clipper · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Empty options get reverted to default #15

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
johnadamson opened this issue Sep 9, 2017 · 3 comments
Closed

Empty options get reverted to default #15

johnadamson opened this issue Sep 9, 2017 · 3 comments

Comments

@johnadamson
Copy link

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
Copy link
Owner
wincent commented Sep 23, 2017

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
Copy link

@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.

@wincent wincent closed this as completed in 47ab84d Oct 4, 2018
@johnadamson
Copy link
Author

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@wincent @dennistang @johnadamson
0