Is this literal strings issue intentional?

[ConversionMan]

Hi. I’ve been working with an organisation to implement document conversion, and spent many hours trying to figure why the Windows version soffice.exe (5.4.4) was not converting documents, and saw a lot of people reporting the same issue but with no real resolution.

After much experimentation, I discovered that LibreOffice’s executable does not actually tolerate literal strings (and thus, by extension, spaces) when supplying either directory or filename arguments to convert-to. The only exception seems to be the calling of the LibreOffice executable itself, which can be a literal string - all subsequent arguments appear not to allow spaces of any kind.

So, for example:
“C:\Program Files\LibreOffice 5\program\soffice.exe” -headless -convert-to pdf -outdir “C:\Some Directory” “C:\Some Directory Complete\Some Document.doc”

Won’t work because the arguments to LibreOffice use literal strings, spaces, but:

“C:\Program Files\LibreOffice 5\program\soffice.exe” -headless -convert-to pdf -outdir C:\Directory C:\Directory\Test.doc

Will, as it contains no literal strings or spaces. I find this hard to believe it’s intentional given that most filenames will contain spaces. Why is this? Is it a bug? Do the arguments have to be called in a different manner?

Not that I think it’s relevant, but: Windows 7, LibreOffice 5.4.4, called via cmd.exe using the above arguments.

[mikekaganski]

Works fine for me with both 5.4.4.2 and 6.0.0.3 on Win10.

[ConversionMan]

This isn’t a helpful comment. What exactly “works fine for you”?

[librebel]

Hello @ConversionMan,

Please try if it works when you specify in the last argument only the filename, but not the full path ( first move the command prompt to the folder where that file is located, using the cd command ).

HTH, lib

[mikekaganski]

While @librebel’s advise is fine from user’s PoV, when one tries to find a workaround for a problem, I also ask @ConversionMan to share some details wrt the problem, because for me (as someone who had worked on different Win-specific path-related problems in LO) it’s important to find the bug (if exists); esp. as for me, exact command given in the Q does work OK (created the paths, and a sample file).

[ConversionMan]

Hi Librebel. Unfortunately this suggestion is no good, because the CWD only covers one directory, and there are, of course, two. Even if it was a centralised directory, LibreOffice convert-to cannot handle spaces in filenames, and I find it bizarre as a programmer it is unable to accept literal string arguments.

[ConversionMan]

Mike (I apologise, @ strings do not appear to work for me), LibreOffice 5.4.4 does not appear to handle literal strings from cmd.exe. The first command does not work - one which contains spaces within the directory structure and the file name - but the second does. Obviously, I cannot expect files to not have spaces in them, so I’m baffled why the first command does not work. This is after extensive checking.

[mikekaganski]

Sigh… it seems to me sometimes that people just can’t read. I wrote here twice that your exact command line does work for me; I created the directories with names you wrote (just to ensure clear experiment), and a DOC file with that name, and started cmd in default directory (which is my profile), and from there, issued the command, and it works (I repeat it in the third time). Both 5.4.4.2 and 6.0.0.3. So it’s crucial to see the difference between systems - locales, special characters, etc.

[mikekaganski]

Here is the screencast to show that the command indeed works. Of course, it isn’t meant to “prove” that it “works for you”; just that it works in principle, so your problem needs investigation and should be treated as bug.