Gfilui

I am using PDFXCview.exe in Ubuntu 16.04 under wine-3.1.

When I specify a pdf file as an argument to PDFXCview.exe, absolute pathname to the pdf file doesn't make PDFXCview.exe find the pdf file, while relative pathname to the pdf file does.

For example:

wine /path/to/PDFXCView.exe my.pdf

will open my.pdf in PDFXCView.exe, while

wine /path/to/PDFXCView.exe "$PWD"/my.pdf

doesn't.

1. 
   

   The absolute path argument is used by PDFXCView.exe only, not by
   wine, so converting the absolute path to a wine recognizable path
   doesn't help. For example, wine /path/to/PDFXCview.exe "$(winepath /tmp/test/O.pdf)" doesn't make PDFXCview.exe find and open the
   pdf file, where .the wine-recognizable path is:

   
   
   

   $ echo wine /path/to/PDFXCview.exe "$(winepath /tmp/test/O.pdf)"
   wine /tmp/test/PDFXCview.exe /home/t/.wine/dosdevices/z:/tmp/test/O.pdf
   

   
   


2. On the contrary, when I specify a text file as an argument to
   notepad.exe, I can specify either the absolute pathname or a
   relative pathname to the text file, and notepad.exe can find the
   text file to open. For example, both wine notepad "$PWD"/note and
   wine notepad note can make notepad find and open the text file
   note.

Is the above also the case to other people?

What is the reason that PDFXCview.exe doesn't recognize the absolute pathname to its argument, but only a relative pathname?

I was wondering if the above problem with PDFXCview.exe is because of the program itself or wine?
I don't have Windows to test, and also wonder if PDFXCview.exe behaves in Windows in the same way as in Wine.

Thanks.

Screenshot of Drive tag of winecfg

You're providing an absolute Linux-style path to a Windows executable that is being executed by Wine, not giving that path argument to Wine itself. Therefore, you have to treat every argument after the path to the .exe as a Windows-style argument (i.e. wine /home/$USER/.wine/drive_c/path/to/Windows/executable.exe [Windows Style Arguments]).

The full Linux style paths work for notepad.exe, but consider that notepad.exe is likely not the pure Windows version of Notepad, it's included with the Wine setup, and is probably tweaked to accept Linux paths (like /tmp/test/O.pdf).

Most of the applications that wine can execute, however, do not have those tweaks, and therefore only accept Windows-style paths. So, you need to give those apps a Windows-style path, in the format like C:WindowsSystem32... but with regards to the actual location of the files, and with respect to the drive mappings in Wine, while taking into account Bash / Linux console style interpretations* of paths.

First, find the drive mappings and to where they 'exist' in the Linux file infrastructure. To do this, load up winecfg, and in the Wine configuration window, go to the "Drives" tab. It'll look something like this:

As you can see, I have C: which is mapped to the Wine drive_c directory which in this instance is in /home/teward/.wine. I also have a drive M: mapped to my /mnt/ directory, which is relevant because I have things referenced by M: in the Wine apps.

What's most relevant is the Z: mapping, which maps to the root / partition on my Linux environment. This usually is a default mapping, but isn't necessarily going to be in your environment (so make sure it is). Whichever Wine drive is mapped to /, you'll need to use. And if one doesn't exist, you'll need to add a drive mapping that matches either / or the actual directory your data is actually in that you're opening with the Windows application. Technically, you could have T: mapped to /tmp/ and then do T:.pdf, but I'm not assuming that for my answer.

So, for the purposes of this answer, I'm going to assume that Z: is actually mapped to / and use that from this point forward in my answer.

You need to take the Linux path and convert it to Windows-style from the Z: drive root. So, for /tmp/test/0.pdf in Linux, you'll actually give it 'Z:tmptest.pdf' (including the single ' quotes so the shell doesn't mess up with interpretation* of the path). This way, the Windows-style application is getting a path it can read and understand, not a path that it can't.

Very few Wine applications are actually capable of understanding the /foo/bar/baz style paths of Linux, and most of the ones that do were tweaked and installed as part of setting up Wine to begin with. Therefore, it's best to give Windows-style paths to Windows applications running inside Wine, rather than Linux style paths.

* When I refer to 'interpretation', I don't refer to the :, but the that's in the paths. And though your path doesn't contain spaces, I also refer to spaces. In Bash syntax, the is used as part of an escape character. Further, in the command line, arguments are space-delimited, so it doesn't know how to process spaces in the paths, and as such you would have to escape them with backslashes. So for what would be C:Program FilesFoobar.exe, you'd actually have to put C:\Program Files\Foo\bar.exe for the path. However, with the default Bash shell, you can negate this misinterpretation of slashes and spaces by wrapping the path with single quotes (') which treats it as a literal argument being passed, in its entirety, so you could do 'C:Program FilesFoobar.exe' without having to deal with escaping backslashes or spaces.