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:
(earliest affected)
3.6.2.2 release
Hardware: Other All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 48782 59127 64720 93345 117363 (view as bug list)
Depends on:
Blocks: Commandline
  Show dependency treegraph
 
Reported: 2011-08-19 04:02 UTC by Tristan Miller
Modified: 2018-07-18 17:46 UTC (History)
14 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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 Comment hidden (obsolete)
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. ***
Comment 12 Nuno J. Silva 2015-04-17 09:46:19 UTC
I would also like to see this happening.
Comment 13 Maxim Monastirsky 2015-08-11 07:53:10 UTC
*** Bug 93345 has been marked as a duplicate of this bug. ***
Comment 14 pete 2016-02-16 16:25:10 UTC
The related behaviour about respecting paths (as in comment 10) is also needed. This really slows down what is otherwise a standard workflow.
Comment 15 Boris Kheyfets 2017-08-14 08:18:44 UTC
Here's a bash function to create empty spreadsheet:

function lo-create-spreadsheet () {
  # usage:
  # lo-create-spreadsheet test.xlsx
  # lo-create-spreadsheet test.xls
  # lo-create-spreadsheet test.ods

  baseName=${1%.*}
  ext=${1#*.}

  csvFile="${baseName}.csv"
  touch "$csvFile"

  loffice --convert-to "$ext" "$csvFile"

  rm "$csvFile"
}
Comment 16 Nuno J. Silva 2017-08-14 10:12:31 UTC
I'm afraid that function won't be convenient when filename.csv already exists in the current directory and has important information. You probably want to use a file under /tmp, for example, using mktemp to generate the temporary filename. I'd not be surprised if libreoffice required files to have extensions, so you'll probably have to use the --extension option of GNU mktemp (coreutils >=8.2) or something equivalent.

Of course, it would be simpler if libreoffice could be more compatible with this kind of workflow...
Comment 17 freta 2018-02-17 08:20:26 UTC
I would also appreciate this feature very much.
Comment 18 Maxim Monastirsky 2018-05-01 13:04:33 UTC
*** Bug 117363 has been marked as a duplicate of this bug. ***