astrand

> I've thought hard about this and I've written up responses only to find that they are too verbose. I don't want to waste your time, but I do want...

Thanks a lot for this extensive feedback! A few comments below: > Command Expected Behavior Corresponding Arguments > `xclip` Print the contents of the clipboard. `xclip -out` > `foo |...

I didn't reallize that 4) blocks other applications from accessing the clipboard. So, it's not useful for the event driven hook I described above. Original comment by: joeymingrone

Ah, silly me. This might not actually be a bug, per se, as it seems xclip-copyfile's parameters are simply passed to `tar'. Though, I do still think that being bombarded...

- **summary**: xclip-copyfile's --help flag passes its help output to `tar' --> xclip-copyfile's --help flag results in unexpected output Original comment by: bapabooiee

Thanks for the report. It is probably possible to deal with this situation better. However, to be honest, I lack the knowledge how it should be, and the time to...

The problem is just that xclip, just like most other open source projects, depends on volunteer work. Unfortunately, it seems like this particular problem is not a showstopper for me...

Addendum: I know of xclip's -help switch, but most other CLI programs use two dashes, so that's what most people (and POSIX) expect. Original comment by: boldewyn

for X application, -help seems to be the standard syntax see xedit, xevt which support only "-help" switch (not "--help" switch) Original comment by: *anonymous

xclip already has "-h" and "-help". I don't think we should add a special exception just for help. We could consider supporting both single and double dashes for all options...