How to redirect output

ubuntu 16.04
LibreOffice Version:
Build ID: 1:5.1.6~rc2-0ubuntu1~xenial2
CPU Threads: 8; OS Version: Linux 4.4; UI Render: default;
Locale: en-US (en_US.UTF-8); Calc: group

Two part question.

  1. I have the following in a bash script:
    libreoffice -env:UserInstallation=file://${tmpdir} --headless --nolockcheck --convert-to csv --infilter=CSV:44,34,76,1 --outdir=myDir fileToConvert.xls

Without --outdir it works fine. With it, I get a usage message and “Unknown option: --outdir=myDir”. Can someone confirm and report it as a bug? Or tell me what I’m doing wrong? I get the same result from the command line.

  1. After converting I’ve tried redirecting error output to /dev/null, but it fails to redirect. It seems informational messages are sent to stdout, not stderr. Can someone confirm and if so, perhaps report it as a bug? Converting batches of files isn’t pretty especially if using cron. Perhaps there is an option to make it run silent?

Thanks in advance!

  1. You are doing that wrong.

The --outdir parameter is not standalone: it is only valid immediately after --convert-to and its filter definition. So, if you have used another standalone parameter after --convert-to (in your case, it’s --infilter), then you cannot use --outdir after that. (EDIT: also there is no = between it and directory path.)

The correct command line would be

libreoffice -env:UserInstallation=file://${tmpdir} --nolockcheck --infilter=CSV:44,34,76,1 --convert-to csv --outdir myDir fileToConvert.xls

--headless is redundant here since it’s implied with --convert-to. To see the command line usage help, please use libreoffice --help.

  1. Don’t ask “someone” to file bugs for you. Please do it yourself, because it’s you who is interested in that. There will be plenty of other work for others to do: try to reproduce, debug and fix. So please do your part and file a bug at Bugzilla.

I believe that I had a discussion wrt using stdout for our output instead of stderr, and I was given some good reason for that, but I cannot remember it now, so filing a bug will help even if it will be closed WONTFIX or NOTABUG, because some background information will be given.

I don’t have enough karma to upvote the answer. Sorry.

Thank you for your response.

–headless is redundant here since it’s implied with --convert-to.
To see the command line usage help, please use libreoffice --help.

I looked long and hard at it many times before posting. And yet I still failed to see that statement in the usage until you mentioned it and then I checked it three more times before I finally saw it.

In any event, I copied and pasted your suggestion…

libreoffice -env:UserInstallation=file:///tmp/libreoffice-k4GhMV1U2wiX --nolockcheck --infilter=CSV:44,34,76,1 --convert-to csv --outdir=myDir myDir/fileName.xlsx

LibreOffice 10m0(Build:2)

Unknown option: --outdir=myDir

Usage: soffice [options] [documents…]

P.S. I tried to enter this as a comment instead of an answer, but apparently “this content is forbidden”.

I am sorry, I simply copy-pasted part of your initial command line to my answer, just changed order. I must have checked also that there should be no = between --outdir and myDir.

Which again reinforces the statement that one should look at the documentation (in this case, --help output) closely in case of such errors.

And also: why do you use the “wiki” checkbox? I’m just curious why would people think they need to check it??? See this my proposal for background of my curiosity.

I improved the error message that LO will give in the case when you put --outdir in the wrong place. The wrong spelling error message (like “–outdir=myDir”), however, will stay as it is now.

Thank you, that worked. My original command was pieced together based on various Net postings, so that = sign someone either goofed when they posted, or the behavior changed since that time. As to the help page it’s too dense and intimidating. It suffers from a severe lack of white space for starters. I think that would go a long way - right now the eyes tend to glaze over, especially around the parts we’re talking about now. Finally, the difference between --headless and not using it is:

(soffice:27333): Gtk-WARNING **: Unable to locate theme engine in module_path: “hcengine”,

(soffice:27333): Gdk-WARNING **: gdk_window_set_icon_list: icons too large

(soffice:27346): Gtk-WARNING **: Unable to locate theme engine in module_path: “hcengine”,

(soffice:27346): Gdk-WARNING **: gdk_window_set_icon_list: icons too large

(soffice:27346): Gdk-WARNING **: gdk_window_set_icon_list: icons too large

–headless eliminates the above messages.

Actually… got one more thing to mention. Your statement about “using stdout for our output instead of stderr”… the simple solution is to add a --quiet (-q) option. Thanks!

I guess I have more finallys… I checked the wiki box because I thought it would be more helpful to others. The fact that no karma is awarded is a bit confusing. I didn’t realize it was telling me that by NOT checking the box, I WOULD get karma. I agree with the comments made about your proposal, which is that someone should have greater reputation to check the box. In fact, it shouldn’t even be displayed for those not experienced enough to know what it really means.

Your improved error message is a great improvement. However, the = sign issue is a real gotcha. Look at the syntax for infilter and env:UserInstallation. Both include = signs. So why would outdir not include an = sign? Inconsistent option syntax isn’t good and leads to the kind of mistake I made. Add the vague error message to the mix and well… here we are :slight_smile:

Having now thought about it for 5 more minutes, unless there’s a good reason I’m unaware of, it really should simply accept the = sign and treat it the same as white space. i.e. ignore it and process the option in normal fashion. That’s my opinion anyway. Thanks for all the help!

May I suggest adding CSV in as one of the examples in the help section, what’s scattered around the Net is vastly different from what actually works. CSV is likely used more than any other format, due to it being universally used to import & export data.