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
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:
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.
notepad.exehowever can find a text file whether its absolute path or relative path is given. Why is the difference between
wine, but it doesn't work. See my update.
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.exeis 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...