Bug 40227 - Create new files from the command line
Summary: Create new files from the command line
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Libreoffice (show other bugs)
Version: 3.6.2.2 release
Hardware: Other All
: medium enhancement
Assignee: Not Assigned
QA Contact:
URL:
Whiteboard:
Keywords:
: 48782 59127 64720 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-08-19 04:02 UTC by Tristan Miller
Modified: 2015-01-11 19:13 UTC (History)
8 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Tristan Miller 2011-08-19 04:02:40 UTC
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
Comment 1 Björn Michaelsen 2011-12-23 12:32:12 UTC
[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
Comment 2 Hein Zelle 2011-12-29 03:57:15 UTC
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.
Comment 3 Tristan Miller 2012-08-15 19:18:37 UTC
Confirming problem still exists with LibreOffice 3.6.0.4.
Comment 4 Robert Marmorstein 2013-01-31 07:18:20 UTC
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.
Comment 5 Richard Neill 2013-04-09 17:33:48 UTC
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.
Comment 6 Julien Nabet 2013-05-17 18:27:29 UTC
*** Bug 59127 has been marked as a duplicate of this bug. ***
Comment 7 Julien Nabet 2013-05-17 18:27:46 UTC
*** Bug 64720 has been marked as a duplicate of this bug. ***
Comment 8 Julien Nabet 2013-05-17 18:29:31 UTC
Michael: It seems a feature quite expected by users (see dup). Do you think it could be relevant?
Comment 9 Michael Meeks 2013-05-17 19:43:30 UTC
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.
Comment 10 Nadav Har'El 2014-11-19 11:17:54 UTC
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
Comment 11 Maxim Monastirsky 2014-11-27 22:54:35 UTC
*** 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.