Windows UNC Path within PowerShell failed on openBinaryFile

oToToT commented 3 years ago

Reporting a bug? Please include your pandoc version and an example that allows us to reproduce the problem (complete input, exact command line used, expected and actual output). The smaller the example, the better.

Version Information

PS C:\> pandoc --version
pandoc.exe 2.11.2
Compiled with pandoc-types 1.22, texmath 0.12.0.3, skylighting 0.10.0.3,
citeproc 0.2, ipynb 0.1
User data directory: [SOMEWHERE]
Copyright (C) 2006-2020 John MacFarlane. Web:  https://pandoc.org
This is free software; see the source for copying conditions. There is no
warranty, not even for merchantability or fitness for a particular purpose.

Way to reproduce

If one have a WSL 1 (not sure for WSL 2), he could simply reproduce the problem by typing the command below in PowerShell.

cd \\wsl$\Ubuntu
pandoc a.md -o a.pdf

Expected Result

build a pdf and save it to \\wsl$\Ubuntu.

Actual Result

pandoc.exe: a.md: openBinaryFile: does not exist (No such file or directory)

Other Information

I know that there is a closed issue #5127 related to UNC Path in Windows. However, I think this is not that related to the UNC path itself. Maybe this is a problem that PowerShell somewhat treat the UNC Path as Microsoft.PowerShell.Core\FileSystem::\\wsl$\Ubuntu instead of \\?\UNC\wsl$\Ubuntu or similar, and, thus, causing pandoc not handling the path.

mb21 commented 3 years ago

so it only happens if there is a dollar in the path of the current working directory, or.. what's this cd \\wsl$\Ubuntu business?

mb21 commented 3 years ago

btw. why don't you just use the pandoc windows binary? seems you're using the WSL (windows subsystem for linux)...

jgm commented 3 years ago

Try it with --verbose to see if you get more useful information. Unfortunately I don't have a windows box to experiment on.

oToToT commented 3 years ago

@mb21

btw. why don't you just use the pandoc windows binary? seems you're using the WSL (windows subsystem for linux)...

I'm using windows binary here (see the version information is pandoc.exe 2.11.2 not pandoc 2.11.2).

Saying WSL here is just to simplify the way to retrieve a valid UNC Path. (I just think that most of the developer using Windows will have WSL)

so it only happens if there is a dollar in the path of the current working directory, or.. what's this cd \\wsl$\Ubuntu business?

I don't think it is a problem of the dollar sign or the UNC Path itself because executing something like

PS C:\> pandoc \\wsl$\Ubuntu\a.md -o \\wsl$\Ubuntu\a.pdf

works great for me.

I use cd \\wsl$\Ubuntu just say that I've change the working directory to a remote folder.

Notice that executing cwd on PowerShell in a remote directory gives

Path
----
Microsoft.PowerShell.Core\FileSystem::\\wsl$\Ubuntu

while it gives

Path
----
C:\

inside normal folder like C:\

Sorry for the inaccurate description above.

oToToT commented 3 years ago

@jgm

Try it with --verbose to see if you get more useful information. Unfortunately I don't have a windows box to experiment on.

Sorry, but after executing pandoc --verbose a.md -o a.pdf, I still only got pandoc.exe: a.md: openBinaryFile: does not exist (No such file or directory) .

Not sure how to make pandoc display more logs.

jgm commented 3 years ago

Well, I guess the problem is really just finding the input file, so it has nothing to do with pdf production. I guess you get the same with -o a.html?

oToToT commented 3 years ago

Ah, yes, -o a.pdf is not necessary, something like pandoc a.md -o a.html, pandoc a.md or pandoc a.txt produce the error.

jgm commented 3 years ago

You don't happen to have Haskell installed, I assume? It would be helpful to check some of the basic functions.

kysko commented 3 years ago

I'm actually on a WSL2 Ubuntu, and confirm this situation also (although I have no personal need of this, fyi).

However I've found a workaround, that I read from this review of wsl2 (see "File Performance" section), which might be tolerable, if it can be applied with WSL1. It is to assign a virtual drive to the wsl instance. So if you don't have the U drive already assigned:

subst u: \\wsl$\Ubuntu

You can then cd to where your file is, and apply your Windows pandoc.exe. To unassign:

subst u: /d

@oToToT Didn't know you could touch the Linux fs from Windows though with WSL1. Anyway, that seemed to have worked for you.

Don't know if the above can help resolve the problem (if any) at pandoc's level, seems to be one of those Windows quirks. \\wsl$ doesn't seem to have an usual "UNC long form".

jgm / pandoc