Problem description: The LibreOffice executable (soffice.exe) supports a number of command line arguments as described in http://help.libreoffice.org/Common/Starting_the_Software_With_Parameters. The linked document (as well as blog posts on the internet) suggests that it should be possible to use the command line to convert all MS Word documents in a directory to odf. However, following command line does not convert anything: soffice.exe --headless --convert-to odf --outdir C:\Docs\Out C:\Docs\In\*.doc If the direct path is used, e.g. soffice.exe --headless --convert-to odf --outdir C:\Docs\Out C:\Docs\In\a.doc the specified document is converted to a.odf and placed in the out directory. I run Windows 7 64 bit and have LibreOffice 3.5.1.2 installed. I have made sure that no instance of soffice is running before trying to use the command line. Steps to reproduce: 1. Open command prompt to C:\Program Files (x86)\LibreOffice 3.5\program 2. Enter >soffice.exe --headless --convert-to odf --outdir C:\Docs\Out C:\Docs\In\*.doc 3. The documents in C:\Docs\In are not converted. 4. Enter >soffice.exe --headless --convert-to odf --outdir C:\Docs\Out C:\Docs\In\a.doc 5. The specified document, a.doc, is found in C:\Docs\Out. Current behavior: Using *.doc does not convert any documents in the input directory. Expected behavior: Using *.doc converts all documents in the input directory and copy the result to the output directory. Preferably, it would also iterate through sub directories, maintaining the directory structure in the outdir, but I'm unsure if that is the intended behaviour. Platform (if different from the browser): Browser: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20100101 Firefox/11.0
Findings on my Linux/32 machine with LibO 3.5.3.1: 1) conversion works well with one or several input files 2) stops working if a certain file amount (size?) is exceeded (here: 5 files, total about 10m size) 3) did not get it to work if filename inludes path information So my conclusions are, A) LibO fails to handle path information correctly. B) LibO seems to fail if too many files (or too big size) are given as arguments Hint for devs: if B is correct, a nice Error Message would be fine ;-) Setting prio to low as good workarounds exist @zumbs@yahoo.com: Can you try this workaround: 1) cd into directory containing original files 2) do not convert all files at once but start with fewer (e.g. 5 or less) files Does it work? In case it does not, you could try the following workaround (but again you have to cd into appropriate directory first): for %i in (*.doc) do soffice.exe --headless --convert-to odf --outdir C:\Docs\Out %i * take care that all is in one line; * maybe you have to lookup correct syntax for loop command ("help for")
I installed LibreOffice 3.5.1rc1 and tried out the following command line argument: C:\Docs\In>for %i in (*.doc) do soffice.exe --headless --convert-to odf --outdir C:\Docs\Out %i Output: C:\Docs\In>soffice.exe --headless --convert-to odf --outdir C:\Docs\Out File1.doc C:\Docs\In>soffice.exe --headless --convert-to odf --outdir C:\Docs\Out File2.doc C:\Docs\In>soffice.exe --headless --convert-to odf --outdir C:\Docs\Out File3.doc The first file was correctly converted, but conversion of subsequent files failed. It would seem that Windows starts the three calls in parallel, which causes us to run into the bug where the command line fail to succeed if LibreOffice is already running (bug 37531). I saw a lot of instances of soffice.exe and soffice.bin in Taskmanager. I tried using an Ubuntu 11.04 live cd. With command line arguments similar to the one in my original bug report, I got full conversion of the contents of C:\Docs\In, so it seems like it is a Windows bug. On a side note, I made a small .net tool to convert the files one at a time, so I no longer need a workaround.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: (1) Test to see if the bug is still present on a currently supported version of LibreOffice (4.3.5 or later): https://www.libreoffice.org/download/ (2) If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior (3) If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT (1) Update the version field (2) Reply via email (please reply directly on the bug tracker) (3) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) Thank you for your help! -- The LibreOffice QA Team
Verified that bug is still present with LibreOffice 4.3.5.2 running on Windows 7 SP1 64 bit. (Note that as per the comments above, the issue is not present on Linux, but I have not verified that again.)
*** Bug 68647 has been marked as a duplicate of this bug. ***
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.1.5 or 5.2.1 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20160920
Bug is still present with LibreOffice 5.2.1.2 on Windows 7 SP1 64 bit. As before, I have not investigated Linux. No change in behavior.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
This bug is still present on LibreOffice 6.1.2.1 for Windows x86. I am seeing this problem for years, and ONLY on Windows, when wildcard "*" is used. *.doc will NOT work <filename>.doc will always work. Workaround: Convert files using LibreOffice on Linux
Dear zumbs, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
I have tested the bug with 6.3.1.2 (x64) on Windows 10 Pro x64 Version 10.0.18362 Build 18362 and the bug has not been fixed..
I can confirm on LibreOffice version 6.4.3.2 (x64) for Windows 10 Pro x64 the bug is still there. Wildcards should be definitely handled nicely by the soffice executable in headless mode. Example of not working command: "C:\Program Files\LibreOffice\program\soffice.exe" -ArgumentList "--headless --convert-to pdf *.odt Workaround: if anyone is in search of a temporary solution, you may use a powershell or batch script. Here is a simple example Powershell script I wrote to convert all odt documents inside a folder to pdf: Get-ChildItem *.odt | Foreach { Write-Host "Converting `"$_`" ..." Start-Process -Wait -FilePath "C:\Program Files\LibreOffice\program\soffice.exe" -ArgumentList "--headless --convert-to pdf `"$_`"" } You may: - change "Get-ChildItem *.odt" to your favourite input format. Ex. "Get-ChildItem *.docx" - add -Recurse to it if you need to convert files in nested folders. Ex. "Get-ChildItem *.odt -Recurse" - change "--convert-to pdf" to your needed output format. Ex. "--convert-to docx" Hope this issue gets addressed. Good luck everyone!
It seems you cannot edit a post on Bugzilla. I did a small mistake when I copy&pasted the example command. Here is a correct example of command not working: "C:\Program Files\LibreOffice\program\soffice.exe" --headless --convert-to pdf *.odt
This Windows-only enhancement needs LibreOffice to implement own wildcard matching when pre-processing the passed command line on Windows. Unlike *nix environment, On Windows there's no shell pre-processing that the resulting command line that LibreOffice gets is already expanded. For now, tricks like > for %%f in ("input folder\*.sxd") do "C:\Program Files\LibreOffice\program\soffice.exe" --convert-to png --outdir "output folder" "%%f" are needed (the example above is for batch files; if using in console, %% should be replaced into %; see e.g. [1]). Code pointer: the command line handling happens in desktop/source/app/cmdlineargs.cxx. It must be Windows-only, since on other platforms, the file path is an arbitrary byte sequence, which itself may include bytes like '*' or '?' (different flavors of FS may apply own restrictions). [1] https://ask.libreoffice.org/en/question/86800
I will try this. I think I need to link setargv.obj.
setargv.obj doesn't work with winmain. Trying direct calls to FindFirstFileA
(In reply to Deb from comment #16) > setargv.obj doesn't work with winmain. Trying direct calls to FindFirstFileA Please never use *A WinAPI. Always use *W variants, *explicitly*.
(In reply to Deb from comment #16) > setargv.obj doesn't work with winmain. Trying direct calls to FindFirstFileA And also it's unexpected that "setargv.obj doesn't work with winmain", given the MS-specific documentation on this: https://docs.microsoft.com/en-us/cpp/c-language/expanding-wildcard-arguments
(In reply to Mike Kaganski from comment #18) Specifically, note that soffice.bin is a console application on Windows, which uses main, not WinMain. So it's unnecessary to rely on wildcard processing in soffice.exe (which indeed uses WinMain itself, but passes the command line arguments to the console-based soffice.bin). But it's OK either way, whatever you consider easier.
(In reply to Deb from comment #16) > setargv.obj doesn't work with winmain. Trying direct calls to FindFirstFileA After looking at that MS documentation on setargv.obj, I now see where the problem is. Indeed, it will not work with LibreOffice, since it doesn't use crt's main arguments at all. It uses WinAPI to access the original command line arguments (so any crt pre-processing is ignored), and you would surely need to use the FindFirstFile WinAPI (or the like) to do the job.
Deb Barkley-Yeung committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/7f477f8dd85c84c9c1a9e673b685dc0e03d1d45a tdf#48413 handle wildcards on Windows It will be available in 7.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Just confirming... this won’t be available for another year in v7.2.0?
(In reply to Scott from comment #22) This *will* be available in v7.2.0. It will be released in Aug 2021.
\soffice_safe.exe --convert-to pdf D:\inputdir\* --outdir D:\outputdir\ It works in 7.2. However, how to iterate through subdirectory?
If it works, we set Verified. I guess that for subdirectory another enhancement bug would be needed. .
As noted in bug 148275, from LO 6.3 proper console mode in Windows is `soffice.com`, so calling should be with "soffice.com" or just "soffice" but not soffice.exe. Only then it waits for a command to finish to continue with the next one. https://mikekaganski.wordpress.com/2018/11/21/proper-console-mode-for-libreoffice-on-windows/
Is this working or not? I get this error: At line:1 char:50 + "C:\Program Files\LibreOffice\program\soffice" --headless --convert-t ... + ~~~~~~~~ Unexpected token 'headless' in expression or statement. At line:1 char:1 + "C:\Program Files\LibreOffice\program\soffice" --headless --convert-t ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The '--' operator works only on variables or on properties. + CategoryInfo : ParserError: (:) [], ParentContainsErrorRecordException + FullyQualifiedErrorId : UnexpectedToken
(In reply to asbjoern.skoedt from comment #27) Your problem has nothing to do with this bug; you need to learn how to use PowerShell to call programs. Specifically, operator & is used for that in that environment [1]: > & "C:\Program Files\LibreOffice\program\soffice" --headless --convert-to ... [1] https://www.delftstack.com/howto/powershell/powershell-run-exe/