Cannot open file with spaces in path [mac]

[mediapathic]

If I try to link to a file with spaces, I get an error message clearly splitting the path at the spaces:

The files /Users/mediapathic/vault/02\, /Users/mediapathic/vault/OUTPUT/Stories/02\, /Users/mediapathic/vault/Drafting/Low\, /Users/mediapathic/vault/Tide/low\, and /Users/mediapathic/vault/tide.md do not exist.

This happens if I leave the spaces as is, escape them with backslashes (as in the example above), or enclose the path with either single or double quotes within the task.

[artur-shaik]

try this in your settings:

files.command = "xdg-open \"$FILE\""

[lukebarton]

I spent at least 30 minutes trying every combination of escaping and quotes I could. I could not find a functioning combo. There appears to be some sort of escaping going on which leads to escaping of escaping.

[jschlatow]

I do not have a mac for testing but I might be able to help with a few debugging hints:

• You may run taskopen --debug to show the executed command line.
• You may also run `taskopen -x'echo $FILE' to output what taskopen grabbed as the file part from the annotation.
• Taskopen does not do any escaping. It simply grabs what's configured as file.regex, expands a preceding ~ if necessary, and puts the result into $FILE.

On Linux, there are two ways to deal with spaces in file paths for taskopen.

• You either add the paths to a task's annotation with backslash-escaped spaces
• or your wrap $FILE in quotes, e.g. files.command = "xdg-open \"$FILE\"".

[lukebarton]

The problem is, I believe related to auto-opening with the `editnotes` command. I have no reason to believe it is Mac related at this point.

…

On Wed, 29 May 2024, at 07:44, Johannes Schlatow wrote: I do not have a mac for testing but I might be able to help with a few debugging hints: • You may run `taskopen --debug` to show the executed command line. • You may also run `taskopen -x'echo $FILE' to output what taskopen grabbed as the file part from the annotation. • Taskopen does not do any escaping. It simply grabs what's configured as `file.regex`, expands a preceding `~` if necessary, and puts the result into `$FILE`. On Linux, there are two ways to deal with spaces in file paths for taskopen. • You either add the paths to a task's annotation with backslash-escaped spaces • or your wrap `$FILE` in quotes, e.g. `files.command = "xdg-open \"$FILE\""`. — Reply to this email directly, view it on GitHub <#163 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAYA62P5F6FSPTMH7JRVB3ZEV2N7AVCNFSM6AAAAAAVBTMCICVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMZWGY2TKNBWGM>. You are receiving this because you commented.Message ID: ***@***.***>

[jschlatow]

@lukebarton I cannot reproduce the issue with editnotes or ls either. Taskopen passes the command you configured as is to the system shell (basically /bin/sh -c '<command>'). Hence, I'm wondering why -x'ls "$FILE"' or files.command = "ls \"$FILE\"" seems to have any effect.

[dstark]

• You either add the paths to a task's annotation with backslash-escaped spaces
• or your wrap $FILE in quotes, e.g. files.command = "xdg-open \"$FILE\"".

@jschlatow, running under Windows Subsystem for Linux, backslash-escaped spaces spits out a lengthy error with exit code 1 or 2. Modifying .taskopenrc to have files.command = "xdg-open \"$FILE\"", however, works perfectly.

Thanks so much!