0

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

enter image description here

8
  • you're passing a Linux style path into a Windows application, which won't work well. You need to know how the Windows system is laid out with regards to Wine and your 'drive mounts' for how to traverse from Wine into the Linux filesystem, and give it the corresponding "Windows" file path (with respect to the drive mappings in winecfg)
    – Thomas Ward
    Commented Mar 21, 2018 at 22:12
  • Thanks. notepad.exe however can find a text file whether its absolute path or relative path is given. Why is the difference between notepad.exe and PDFXCview.exe?
    – Tim
    Commented Mar 21, 2018 at 22:16
  • I also tried to convert the absolute pathname argument into a path recognizable by wine, but it doesn't work. See my update.
    – Tim
    Commented Mar 21, 2018 at 22:25
  • No... you're still giving it a Linux path. Open up winecfg, and screenshot the 'Drives' tab and add it here. You need to give it a Windows path, not a full Linux path, and you need to start by understanding how Wine translates paths. It doesn't translate Linux paths for arguments to Windows programs, and I bet PDFXCview.exe is expecting a Windows file path. Or, the program is 'weird' and doesn't want to work properly. Note that the WINE test results for PDF XChange suggest that there's problems with it, that it doesn't save files and doesn't like opening them...
    – Thomas Ward
    Commented Mar 22, 2018 at 13:40
  • @ThomasWard Screenshot added. Appreciated
    – Tim
    Commented Mar 22, 2018 at 13:43

1 Answer 1

1

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:\Windows\System32\... 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:

Wine Config: Drives

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:\0.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:\tmp\test\0.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 Files\Foo\bar.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 Files\Foo\bar.exe' without having to deal with escaping backslashes or spaces.

2
  • Thanks. So we have used pure Linux paths and pure Windows paths in the discussion. Is a wine-based Linux path ever useful in some cases? see askubuntu.com/q/1018400/1471
    – Tim
    Commented Mar 23, 2018 at 0:11
  • @Tim I've answered, but I don't think it's the answer you're really looking for directly...
    – Thomas Ward
    Commented Mar 23, 2018 at 0:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .