Ref: https://ask.libreoffice.org/t/cant-start-libreoffice-with-socket-settings/125164/2 Ref: https://ask.libreoffice.org/t/passing-in-json-parameters-into-writer-for-the-convert-to-option/88142 and many more. Some examples in help quote command line parameters. That is system-dependent; Linux command line may accept single-qouted parameters, while on Windows, cmd.exe doesn't. Of course, it's also shell-dependent; e.g., the syntax differs between cmd.exe ad powershell (and even between different powershell versions, sigh). We need to make system variants; and also always explicitly mention, which shell that is.
We can distinguish between WIN, UNIX and MAC operating systems in the help, but beyond that, the type of shell is not implemented as selector in the Help. Besides, the many possible shells can be hard to document all of them. We expect that command line users are savvy in shell use. Suggest WONTFIX. Feel free to reopen if you disagree.
(In reply to Olivier Hallot from comment #1) I disagree. As I wrote: > We need to make system variants; and also always explicitly mention, which > shell that is. And *that* is definitely doable. We must *make system variants* - for most common shell on the platform; and we must *mention* the shell used in the example.
documenting shell (or any exec wrapper) specifics seems beyong LO scope. (maybe extended examples on wiki) but having a warning/disclaimer about quotes makes definitely sense. In https://help.libreoffice.org/latest/en-US/text/shared/guide/start_parameters.html existing "warnings" could be made less "generic" - ... The use of command line parameters is only recommended for experienced users. - For normal handling, the use of command line parameters is not necessary. A few of the parameters require a deeper knowledge of the technical background of LibreOffice software technology. This one even is sounds superfluous - Starting LibreOffice Software From the Command Line Open a shell under Linux, *BSD, or macOS platforms. // Search for Run in the Windows Start menu Type the following line of text, then press Return: This one should be a warning (linked to -env: ) : - LibreOffice requires write access to its user profile directory. etc etc
(In reply to fpy from comment #3) > documenting shell (or any exec wrapper) specifics seems beyong LO scope. 1. As long as we provide a command line example, documenting the environment where the example works *definitely is* in the scope of the help. 2. As long as there is a reasonable way to provide a useful example for a given OS, as opposed to useless bash example for Windows users, it **definitely is** in the scope of the help to provide a useful example.
(In reply to Mike Kaganski from comment #4) > documenting almost agree, for the record, I make a distinction between /mentionning/ and /documenting/. Q: are the double quotes of this example mandatory ? (on all OSes). Or optional or replaced by single quotes ? ... pdf:draw_pdf_Export:{"PageRange":{"type":"string","value":"2-"}}
(In reply to fpy from comment #5) > almost agree, > for the record, I make a distinction between /mentionning/ and /documenting/. Which makes no sense at all. As usual, nonsensical "disagreement" dilutes the original idea, and prevents useful implementation. The examples are there. They are provided after testing in *some* environment (or that must be so; if not, it's a problem of the one who created the example). This is the final fact; and here, *mentioning* which environment (here: shell flavor) this example works in, is exactly the same as *documenting* this environment. The original comment 0 already used the wording "explicitly mention, which shell that is". There was no mention that we need to differentiate the shown example based on the shell that user uses (even though that is *possible* - in a *different* way, similar to how many API documentations provide a variety of examples, sometimes as "tabbed" box with tabs representing different programming languages; nothing prevents us from providing a similar thing, with tabs for bash/csh/..., and for cmd/powershell/...) - but THAT WAS NOT the topic here, and comment 1 somehow assumed what was not here. Only OS-based differentiation was proposed, with the obvious "use example with the default / most-used / reasonable shell for the OS, and mention that shell". > Q: are the double quotes of this example mandatory ? (on all OSes). Or > optional or replaced by single quotes ? > > ... pdf:draw_pdf_Export:{"PageRange":{"type":"string","value":"2-"}} Which is another off-topic here. Please don't hijack this. If you have a question, ask on Ask LibreOffice.
oops. forgot your narrow minded and insulting signature. fair enough.
(In reply to Mike Kaganski from comment #6) > If you have a question, ask on Ask LibreOffice. be sure I won't :(
Trying myself to document the command lines examples, I feel the pain on writing the right CLI on windows 11 PowerShell. To convert an odt file to PDF page 2 to 5 I was able to use the command below under cmd.exe: ----------------8<---------------- C:\Users\olivi>"c:\Program Files\LibreOffice\program\soffice.com" --convert-to pdf:writer_pdf_Export:{\"PageRange\":{\"type\":\"string\",\"value\":\"2-5\"}} C:\Users\olivi\Downloads\WG2508-IntroStyles.odt ----------------8<---------------- However under powershell, that is another story. The best so far was using ----------------8<---------------- start-process 'C:\Program Files\LibreOffice\program\soffice' -ArgumentList "--convert-to pdf:writer_pdf_Export:{`"PageRange`":{`"type`":`"string`",`"value`":`"2-5`"}}","C:\Users\olivi\Downloads\WG2508-IntroStyles.odt" ----------------8<---------------- but it does not work and it seems the argument list is not parsed correctly. The console shows ----------------8<---------------- Could not find platform independent libraries <prefix> convert C:\Users\olivi\Downloads\WG2508-IntroStyles.odt as a Writer document -> C:\Users\olivi\WG2508-IntroStyles.pdf using filter : writer_pdf_Export:{PageRange:{type:string,value:2-5}} Overwriting: C:\Users\olivi\WG2508-IntroStyles.pdf ----------------8<---------------- Looks like the double quotes are discarded in the argument list. note: The backtick (`) for escaping double quotes is dangerous as it also work as continuation line... Help welcome in clarifying this PowewrShell issue.
(In reply to Olivier Hallot from comment #9) > Help welcome in clarifying this PowewrShell issue. https://ask.libreoffice.org/t/cli-convert-custom-page-range-to-pdf/108475/2 I will try myself, a bit later.
So, using both PowerShell 7.5.4 and 5.1, the following command seems to work for me (note that the leading & is part of the command, allowing to use the syntax as is, without start-process): > & 'C:\Program Files\LibreOffice\program\soffice.com' --convert-to 'pdf:writer_pdf_Export:{\"PageRange\":{\"type\":\"string\",\"value\":\"3-4\"}}' --outdir C:\Downloads\ C:\Downloads\file.odt It seems there was a bug somewhere in PS 7.4, which prevented it from working, as shown in my reply there on Ask.
Please ignore my comment #11 - I was not paying due attention to the exported result. So, using PowerShell 5.1, the following command seems to work for me (note that the leading & is part of the command, allowing to use the syntax as is, without start-process): > & 'C:\Program Files\LibreOffice\program\soffice.com' --convert-to 'pdf:writer_pdf_Export:{\"PageRange\":{\"type\":\"string\",\"value\":\"3-4\"}}' --outdir C:\Downloads\ C:\Downloads\file.odt For PowerShell 7.5.4, this works: > & 'C:\Program Files\LibreOffice\program\soffice.com' --convert-to 'pdf:writer_pdf_Export:{"PageRange":{"type":"string","value":"3-4"}}' --outdir C:\Downloads\ C:\Downloads\file.odt i.e., the single quotes escape inner double quotes.
Olivier Hallot committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/help/commit/aac8d60b47589c8ba6d5eda78dc6d901c80eaa79 tdf#167830 CLI examples for several shells.
https://help.libreoffice.org/master/en-US/text/shared/guide/pdf_params.html?DbPAR=SHARED