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.

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

Command-line argument does not work under windows #635

Closed
lazka opened this Issue Mar 14, 2015 · 12 comments

Comments

Projects
None yet
1 participant
@lazka
Member

lazka commented Mar 14, 2015

Original issue 635 created by bernhard.streit on 2010-12-28T13:10:31.000Z:

Hi,

it seems that the command line args as described under

http://code.google.com/p/quodlibet/wiki/ExtendingGuide

does not work under windows. For example, the --play-pause-switch.

If I start quodlibet with this, nothing happens at all.

Can this be fixed? :)

Bernhard

@lazka

This comment has been minimized.

Member

lazka commented Mar 14, 2015

Comment #1 originally posted by reiter.christoph on 2011-02-15T17:03:18.000Z:

<empty>

@lazka

This comment has been minimized.

Member

lazka commented Mar 14, 2015

Comment #2 originally posted by muelma on 2011-04-10T01:35:36.000Z:

I stumbled across the very same problem today when I tried to get my multimedia-keys working in Windows 7. Quodlibet uses a named pipe for remote control, which is rather difficult in Windows (at least for me). So I hacked the source code using sockets for communication. Tested on Windows 7 (64bit) and Arch Linux.

Hopefully, someone else might enjoy it ;-)

Comments are welcome, as this is my very first attempt on socket programming.

@lazka

This comment has been minimized.

Member

lazka commented Mar 14, 2015

Comment #3 originally posted by muelma on 2011-04-10T18:42:10.000Z:

A patch is attached allowing to control quodlibet with udp-sockets instead of named pipes. However, it is implemented by overwriting methods of FIFOControl instead of introducing another control object. The file .quodlibet/control is now used to store the UDP-port where quodlibet is listening for commands.

As said before, it was tested using Windows 7 and Arch Linux, I didn't notice any problems so far.

@lazka

This comment has been minimized.

Member

lazka commented Mar 14, 2015

Comment #4 originally posted by nick.boultbee on 2011-04-11T20:08:39.000Z:

<empty>

@lazka

This comment has been minimized.

Member

lazka commented Mar 14, 2015

Comment #5 originally posted by joe.wreschnig on 2011-04-12T07:37:14.000Z:

If you're going to use sockets,

  1. You need authentication, some kind of secret key at least. A port number is not a sufficient secret.
  2. You need to read the entire socket up to a delimiter, not just the first 4k. 4k is not even enough to guarantee you've read a command followed by a single filename.
  3. You need to supplement, not replace, the standard control file.
@lazka

This comment has been minimized.

Member

lazka commented Mar 14, 2015

Comment #6 originally posted by bernhard.streit on 2011-04-12T13:51:44.000Z:

Hi guys,

I'm glad someone is taking care of this now - unfortunately, I do not have any ideas about sockets, otherwise I would offer my help :)

Many thanks, anyway!!

@lazka

This comment has been minimized.

Member

lazka commented Mar 14, 2015

Comment #7 originally posted by muelma on 2011-04-12T23:01:42.000Z:

@ jow
I would rewrite the whole stuff, if you can point me in the right direction ;-). This was my very first attempt and as I like quodlibet a lot, I would gladly like to contribute more...
I understand your third point (as I mentioned before, I did not create a new object for controlling quodlibet, because I wanted to have something that works at least) -- this should not be any problem.
With your second remark you mean that I should not read a fixed amount of bytes, but rather read a full message until some kind of marker is send (like "\n" or something?)? I need some guidance on this, since I haven't any clue on how to read a socket up to some marker. Do you have any recommendation on literature about socket programming?
The first remark is the hardest, of course. Also here I would gladly extend the code, however I have no idea on how to implement a secret key. As the server-socket is only listening to 'localhost' I don't see the security problem. If I used some kind of encryption I would have to share the encryption key to all processes (for example via some file) - so there wouldn't be any benefits, as far as I can see. If the key was hardcoded, we would gain nothing, because the key could be retrieved from source code. I don't see how a security risk is raised, since the command sent on the UDP port is interpreted. Probably the only thing I should be taking care of, is that the interpretation is safe (and does not allow some commands to be executed in the surrounding shell (like dhcpclient did some days ago :-))).
AFAIK, there might be a better solution using dbus, but I don't know how long it would take for dbus to compatible with Windows.

To summarize, I would need some help (or literature recommendations) on the whole issue.

@lazka

This comment has been minimized.

Member

lazka commented Mar 14, 2015

Comment #8 originally posted by doorknobslayer on 2014-10-15T22:12:28.000Z:

This issue is a few years old; has anyone else poked at this? I've noticed the same problem, and would love command line support (so I can tie global hotkeys to it in Windows).

@lazka

This comment has been minimized.

Member

lazka commented Mar 14, 2015

Comment #9 originally posted by reiter.christoph on 2014-10-16T12:23:17.000Z:

I have a half working patch lying around using local named pipes. I'll look into it.

@lazka

This comment has been minimized.

Member

lazka commented Mar 14, 2015

Comment #10 originally posted by reiter.christoph on 2014-10-16T22:55:33.000Z:

Kinda fixed by revision a1190e5

https://bitbucket.org/lazka/quodlibet/downloads/quodlibet-3.2.-1-rev7074-95d0f8ec7136-portable.exe
https://bitbucket.org/lazka/quodlibet/downloads/quodlibet-3.2.-1-rev7074-95d0f8ec7136-installer.exe

  • --quite doesn't work, I still need to look into that
  • Any command that should print to stdout doesn't work.
    Windows doesn't support stdout for GUI programs, so that wouldn't work anyway, but we could provide a second executable "quodlibet-cmd.exe" that works in the console. This would also be nice for debugging the py2exe version.
@lazka

This comment has been minimized.

Member

lazka commented Mar 14, 2015

Comment #11 originally posted by doorknobslayer on 2014-10-21T19:58:02.000Z:

Nice! I'll try to give a go sometime in the next week or two. Thank you for the rapid response.

@lazka lazka removed the priority-low label Mar 15, 2015

lazka added a commit that referenced this issue Apr 8, 2015

windows: Implement cli command handling using a named pipe. Atm only …
…works with commands that don't send data back. See issue #635.

@lazka lazka removed the confirmed label Apr 22, 2015

@lazka

This comment has been minimized.

Member

lazka commented Sep 15, 2016

--play-pause works now... so let's close this.

@lazka lazka closed this Sep 15, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment