It is impossible to open a new, non-existent document from the command line like so: $ libreoffice3.4 --writer new_document.odt Trying to do so causes LibreOffice to pop up an error dialog with the text "/home/psy/new_document.odt does not exist" instead of a new, empty text document with the filename preset to "new_document.odt" as I would have expected. This feature is so common in text editors and other Unix programs that it should be present in LibreOffice as well. It has a number of useful applications, such as allowing a third-party application to invoke LibreOffice as an editor for a new document, and then processing that document once LibreOffice is closed. This problem isn't limited to the Writer component. This issue has been reported for OpenOffice.org as well; see their Bug 6077: https://openoffice.org/bugzilla/show_bug.cgi?id=6077
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Confirmed with libreoffice 3.5.0beta2, linux32, ubuntu 10.04. I would very much appreciate if this could be tackled. It would make perfect sense to make libreoffice confirm to normal command-line program behaviour. An old annoyance from the openoffice days, still.
Confirming problem still exists with LibreOffice 3.6.0.4.
I can confirm that this issue still exists with 3.6.2.2. This is a really important missing features. As the OP pointed out, this functionality exists in pretty much every other A workaround is to keep a blank file around as a sort of template and copy it with cp before opening the file. Something like: soffice.sh: #!/bin/sh NAME=$1 [ -e $NAME ] || cp $HOME/blank.odt $NAME soffice $NAME If you make this executable and place it somewhere in your path, it does essentially what you might expect. BUT this requires keeping a blank ODT file in your home directory and being careful not to edit it (unless you want to start out with some formatting or something. It does have the advantage that you can define some default styles to apply to your text and have them be consistent across documents, though.
Still true in 4.0.2.2 In every other editor, starting the editor with a non-existent filename causes it to begin a new file of that type, in the relevant directory. I do understand the rationale for the error-dialog "file doesn't exist", to help out users who made a genuine error, but perhaps it could be changed to give us a choice. Eg: Error. The file you selected wasn't found. Would you like to create a new file with that name? [cancel] [create] So, for example this should work to open a new blank presentation in the Documents/projects/penguins directory: cd Documents/projects/penguins/ libreoffice herring.odp Thanks for your time. P.S. A possible heuristic would be to look at the shell environment variables; if $PWD != $HOME, then it's highly likely that the user intended the action of creating a new file, rather than accidentally typing a broken filename.
*** Bug 59127 has been marked as a duplicate of this bug. ***
*** Bug 64720 has been marked as a duplicate of this bug. ***
Michael: It seems a feature quite expected by users (see dup). Do you think it could be relevant?
Sure sure - anyone is most welcome to hack on this one :-) We should of course distinguish nicely between files we cannot open, and locations we cannot write to, but I see no problem with this. It's prolly easy-hack material in desktop/source/app/app.cxx and cmdlineargs.cxx in there. HTH.
I am also really annoyed by this missing feature, which anyone who actually uses a shell expects. To explain why this lack is annoying, consider what happens when I am in some directory /some/directory/deep/deep/in/the/hierarchy, and want to create a new document there. All I can do is run "ooffice --writer" and then use "save as" which will start in my home directory, not in the current directory I was in, and it's a pain to put the file where I originally wanted it. Robert's workaround in comment 4 is nice, but I'd prefer the file not to be saved until I actually do. In other words, here is what I expect to happen: If I do "ooffice file.odt", and file.odt doesn't exist yet, file.odt wouldn't be created yet. Rather, "ooffice file.odt" will behave exactly like "ooffice --writer" (open a new document window), and the only difference would be that openoffice remember the name of the file so when I press "Save" (not "Save as") it will written to the file I originally chose. If I don't "Save", the file will never be created. This is how Unix editors, e.g., vi, behave, and is the most useful behavior for people who run commands in the shell. BTW, the link above the same bug report in OpenOffice is dead. Here is an up-to-date link: https://issues.apache.org/ooo/show_bug.cgi?id=6077
*** Bug 48782 has been marked as a duplicate of this bug. ***
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.