convert xlsx to CSV

users
#21

​Maybe THAT should be fixed before investigating further, because it should
work. This means that somehow​ libreoffice can't find it's installation
directory. It might or might not be related to your difficulties, but
there's no doubt that something's wrong here.

#22

Good call. I have a document I modify multiple times per day, so I leave it open 24/7. That document has a macro I wrote, which has a bug I have not had time to deal with. That bug crashes LO - but only when I try to shut LO down. So I can modify the doc all day for weeks to do what I need to do, but once I close LO I get the crash. I just sent yet another auto-generated error report (several hundred probably by now) to wherever it is they go.

So, exiting LO allows "libreoffice -h" as well as your suggested solution "libreoffice --headless --nolockcheck --convert-to csv a.xlsx" to work. Going back into LO - even *without* opening my document with the macro - causes the conversion to fail silently. Adding "-env:UserInstallation=file:///tmpdir" fixes the silent failure.

So, the issue seems to be twofold. My macro gunked up LO and caused the conversion to fail, and having LO open requires use of the -env option as noted.

Wouldn't you agree the real fix is to get the LO crash fixed in which case my macro - buggy or not - shouldn't affect anything?

Thanks for all your and everyone else's help & suggestions!

#23

So, the issue seems to be twofold. My macro gunked up LO and caused the
conversion to fail, and having LO open requires use of the -env option as
noted.

​If something's borked in the user profile, telling LO to use another one
(or even create one for the occasion, who cares) will indeed fix the issue
:slight_smile:
I've been giving this some thought; and for an automated/independant
process​ it might be better to to it this way anyway; to avoid weird
interaction with various user settings, even non-crashy ones.

Wouldn't you agree the real fix is to get the LO crash fixed in which case
my macro - buggy or not - shouldn't affect anything?

​Yes, that would be the best solution: not crashing, or at least providing
some output about an error​. But debugging weird interactions between such
big piece of softwate and user code might require more work than redoing
the macro a different way, unless the right guy happen to check it and
pinpoint the issue very fast :frowning:

Thanks for all your and everyone else's help & suggestions!

​Glad you got it working :)​