Skip to content
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

accepting absolute paths for -l option #4439

Open
sevu opened this issue Oct 8, 2019 · 1 comment

Comments

@sevu
Copy link
Member

commented Oct 8, 2019

I looked some time ago into mimetypes, and could register the fileextension *.map to be opened in the wesnoth editor. I could commit this to the repository.

For this to work, Wesnoth itself must be capable to deal with a command like this:
wesnoth -e -l /tmp/foo.map, which it does.

(For saves a problem is that *.bz or *.gz is to generic to be associated to wesnoth by default. It could maybe work for uncompressed ones by matching the first line of the file instead of the extension.)

The command for opening saves (generated by the filemanager) would be
wesnoth -l /tmp/blargh, but wesnoth does NOT handle absolute paths here, it will try to open /home/user/.local/share/wesnoth/1.14/saves//tmp/blargh.bz2
(more specifically, it tries this three times without extension and *.gz too)

I worked around this by placing a symlink pointing to /tmp in the saves directory, but …
(linking #2000, not relevant for this issue, but in general)

wesnoth -l should handle paths like wesnoth -e -l

@sevu sevu changed the title association \ accepting absolute paths for -l option Oct 8, 2019
@GregoryLundberg

This comment has been minimized.

Copy link
Contributor

commented Oct 9, 2019

What about Windows and macOS. Seems to me this is probably a cross-platform issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.