Issue 282: xdg-open /path/to/file fails if /path/to/file looks like /path name/to the/file (i.e., has spaces in it)

Hubcapp writes

right clicking to "open directory" in Recoll 1.21.0 (debian package) doesn’t work with file paths which have spaces in them. The path is improperly passed as second argument starting with wherever the space is.

recommend taking the path holder and using .replace(" ","\ ") on it.

medoc writes

Hi,

I tried to reproduce this on a just updated debian stretch with xfce4, and Recoll 1.21.0-1+b1 from the standard repos, and I could not.

I tried both to use "Open Parent document/folder" from the right click menu for a file contained in the directory with space characters in the name, and also the "Open" link on the directory itself (obtained from another search) and both worked. I am not sure about "Open directory" though, is this a litteral quote or an approximation of "Open Parent…" ?

Recoll does not use a shell when executing commands to open a filesystem element, it directly calls execve(), so no quoting can be needed or appropriate on the argument path names.

I would suspect an issue in the desktop-dependant part of xdg-open. What desktop are you running this under, and did you try on the command line ?

xdg-open ~/"my dir with spaces"

Hubcapp writes

Both "Open" and "Open Parent document/folder" don’t work for me (on paths with spaces in them).

Recoll tells me

    Executing: [xdg-open file:///path/to/file &]

if it works, or

    Executing: [xdg-open file:///path/to the/file &]

if it doesn’t.

running

xdg-open /path/to the/

xdg-open file:///path/to the/

or (surprisingly)

xdg-open "file:///path/to the/"

or (surprisingly)

xdg-open "file:///path/to\ the"

doesn’t work either.

the only way I could get xdg-open to open a path with spaces in it properly is by telling it

xdg-open /path/to%20the/

the "open with" dialog in Recoll works (doesn’t use xdg-open), so I agree that it seems like a xdg-open quirk. Still don’t know how to fix this though. (short of patching recoll to replace spaces with %20, not recommended since apparently it doesn’t always work on every xdg-open implementation; see: https://unix.stackexchange.com/questions/169241/xdg-open-doesnt-handle-percent-encoded-file-urls-with-lxde). I’m using Cinnamon as my de,

echo $XDG_CURRENT_DESKTOP
returns
X-Cinnamon

xdg-utils is version 1.1.1-1

medoc writes

I think that you should report the issue both to the distribution and the people who develop xdg-utils.

White-space quoting in shell scripts is a horribly complicated and frustrating issue.

Maybe the simplest approach would be to replace xdg-open as the universal file opener for recoll, and use a shell-script which would url-encode the space characters (as it apparently works with your specific xdg bits)

In ~/.recoll/mimeview, replace xdg-open:

[view]
application/x-all = /path/to/my/script %u

And then in script, something like:

#!/bin/sh
arg=`echo $1 | sed -e 's/ /%20/g'`
xdg-open "$arg"

You could add sed edit commands for tabs, newlines, etc. if necessary.

You will find more explanations in the standard mimeview file: /usr/share/recoll/examples/mimeview

It could be argued that recoll should always apply url-quoting to %u, but as you noted, this would not really ensure that things would always work.

Hubcapp writes

Okay, that seems pretty helpful. At the very least, I didn’t know about ~/.recoll/mimeview, I’m sure I can put together a work-around script like you suggested to handle the whitespace. I’ll try to take it up with the xdg-open people in the meantime. Every year or two, I try using Linux as my daily driver, and there’s always something broken like this.

I’ll take this opportunity to thank you for making Recoll. It’s been an essential replacement for voidtool’s Everything over on Windows. It’s very good software, better than anything available on Linux.

I guess I’ll also take this opportunity to complain about Recoll. My wishlist would be

ability to avoid indexing file contents for speed (not sure if this is already implemented, didn’t look into it)
split media radio into music/video/photo
more clear database updating. Building my initial database (with about 8TB of drives) took about a week. I’m not entirely sure it finished, or had to start over, etc, since I rebooted a few times while it was doing that. I had to go out and buy a cpu cooler just to run recoll. I had it running on start up, and I couldn’t ask it to stop, so it was requesting files so fast I guess it burnt out the cpu (problem started once I asked recoll to start indexing). Cpu had previously been stable on windows… If database updating were less "in the background", I would be able to stop it, or monitor it in some way. I think I’ve read you explain that it’s complicated, and I understand that indexing would be slower if you added more things for the indexing to do (monitoring stuff). I guess you’re doing it the best way possible already, and recoll does (sometimes) report "Indexing in progress" from its main interface (if started from there), I just wish there were a better way comparable to Everything’s NTFS table cheat.

medoc writes

I find that you are a bit hard on Linux there. Of course you are going to find a problem from time to time. It’s not really like Windows or Mac OS X are perfect. I actually replaced Mac OS X on my old macbook after several years of use because I found the new system versions very ennoying. I am also an occasional Windows user and developper, and I’m never tempted to switch. Anyway…

I’ve revisited your examples above, and some of them are not correct (before you take it up with xdg).

xdg-open /path/to the/

This can’t work as the white-space is interpreted by the shell and the path is broken into 2 args, $1 and $2, which is not what xdg-open expects. This is not the same as what recoll does, as your command is interpreted by the shell, it would be equivalent to recoll doing system("xdg-open /path/to the/"), or execve("sh", "-c" ...), which is not what it does (the path is a single argv element passed to execvx()).

Same for the second example with file:///

xdg-open "file:///path/to the/"

This actually works for me, but my xdg-utils is 1.1.0~rc1-2ubuntu7-1linuxmint1 (not 1.1.1). Currently updating the mint vm, we’ll see if it’s an 1.1.1 issue… xdg-open "/path/to the" also works. Ok, updated to 17.3, and xdg-utils is still 1.1.0 and still works sensibly. What system version are you using ?

xdg-open "file:///path/to\ the"

This can’t work because of the double quoting. The actual arg obtained by the command will contain a backslash.

About Recoll issues:

There will be several references to the recoll manual in the following, it’s here: http://www.lesbonscomptes.com/recoll/usermanual/usermanual.html

Avoiding indexing file contents: I think that this can be done on a subtree basis by setting "indexedmimetypes" to empty for the subtree (or the root, but why use recoll then…). Search for indexedmimetypes in the manual.
Split media: the categories are actually defined in the configuration. This would be a bit of a hassle because you have to list all mime types, but it can be done. See the [categories] and [guifilters] section in the mimeconf file (the default file is in /usr/share/recoll/examples, and you can define/replace what you want in the version in ~/.recoll/mimeconf. Also see the manual, there must be at least some doc about it
About database updates. Sorry about the melted CPU, but Recoll assumes that the hardware is sound and will use as many cores as possible while indexing. This can also be customized (look for thrQSizes in the manual). Also, you can interrupt indexing (from the GUI "File" menu), and indexing will not start automatically if you did not set it up to do so.

A GUI instance will monitor the indexer for its main configuration (~/.recoll/ by default). If nothing is shown on the status line, and except for a possible bug, I think that you can assume that the indexer is not active (there is possibly an exception while indexing a very big document, I guess that the status line could become inactive because the state file does not change).

The state file is named idxstatus.txt, and it is located in the configuration directory. The indexer will list the currently processed file from time to time, and this is what gets shown in the GUI status line.

I don’t know about Everything NTFS table cheat, and I’d be interested by a description…

Hubcapp writes

On Windows vs Linux, because there are less choices for Windows, programs can make more correct assumptions about their environment. Some kind of incorrect assumption was made somewhere by xdg people, and now I can’t open things with spaces in their path. Windows/OSX are just more polished, and I spend less time fighting with them to get what I want done. I shouldn’t say "Less choices" is a feature, it’s just a fact that having so many choices in Linux has caused this problem… I’m sticking with Linux for at least a few more months though, all the shenanigans on Windows 10 have steered me away once again. I can always eventually find solutions, but the scouring of forum posts is much rarer on Windows (especially for issues as simple as opening a file). Anyway…

It’s Debian Jessie 8.2 with Cinnamon de with all packages installed from debian repos.

I use Recoll because it offers a gui which allows to sort by date, filesize, etc in a preindexed database. "find" doesn’t use indexing (slow to regenerate every time I search something), and "locate" doesn’t use filesize, or date sorting (iirc), (I am used to these tools from Everything on Windows, and find myself pretty lost without them). The ability to grep the contents of files is not something Everything offers, and so it will take some getting used to. I may or may not find it useful in the future… Usually I put all the tags I want in the filename. I’ll at least tell it not to archive the contents of my emails and game installation subdirectories. +1
Cool, I’ll see if I can set this up. +1
No problem. Honestly, my cooling setup was all screwed up and I even had cool air blowing out the side due to a fan being installed the wrong way… No program ever tried to use all 8 cores at 100%, apparently. I guess on Windows, the fan software kept it happy, maybe some underclocking happened. With the new cooler/fan setup I’m idling between 12c and 32c which makes me pretty happy (used to idle between 45c and 70c). +1

For Everything, I only know what I read here: https://en.wikipedia.org/wiki/Everything_(software)#How_it_works . Apparently, on Windows, NTFS automatically logs file changes to some "NTFS Master Table", so Everything can cheat and instead of searching for updated files, it can just read that table for instant updates. Very fast, always up to date. Unfortunately not available on Linux. (from what I understand, at least, that’s how it works… I didn’t read into it very much so don’t take my word for it obviously.)

medoc writes

I guess that we old Unix hands have just been conditionned the hard way to avoid spaces in file names… This must be why they invented the dash and the underscore :)

I can promise that content search becomes addictive once you’ve begun to rely on it. I wouldn’t dream of not indexing email for example (even if your mail client has a good search, this probably does not go down into attachments).

Thanks for the NTFS link, I’ll take a look.

I installed Cinnamon on Debian 8.2 but it was still xdg-utils 1.1.0 and working. Then I installed the 1.1.1 xdg-utils package from Stretch, and bingo, does not work any more with spaces in file names.

I think that you found a major issue in a very common utility, file a bug report and become famous :)

Just adding: you probably have experimented with an unstable release at some point because all stable Debian releases have xdg-utils 1.1.0 or older. This makes it less shocking that you are experimenting issues…

medoc writes

xdg-open bug

Hubcapp writes

Filed the bug with the xdg-people, thanks for the help (and for Recoll, and for being nice, and for independently confirming the xdg-utils bug). Yeah, I did have apt set up to grab some testing packages (I think I needed some for some application that hadn’t been updated to support some feature…?) but this was supposed to be a stable installation of Debian, so I guess I’m going to have to try and fix that. I’ll try to downgrade to 1.1.0 at least, that will definitely fix my issue.