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)
(earliest affected) release
Hardware: Other All
: medium enhancement
Assignee: Not Assigned
: 48782 59127 64720 93345 117363 159880 159881 (view as bug list)
Depends on:
Blocks: Commandline
  Show dependency treegraph
Reported: 2011-08-19 04:02 UTC by Tristan Miller
Modified: 2024-03-11 03:09 UTC (History)
15 users (show)

See Also:
Crash report or crash signature:


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
Comment 4 Robert Marmorstein 2013-01-31 07:18:20 UTC
I can confirm that this issue still exists with  

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:


[ -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

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.

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


  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. ***
Comment 19 Nadav Har'El 2021-09-21 18:20:22 UTC
In the decade (!) that this issue has been open, it had 14 people registering on it and 5 duplicates. It would have been nice if someone with knowledge of the relevant code finally fix it. My sad conclusion from this issue not having been fixed long ago (and getting only 5 duplicates) is that probably very few people still use the command line as much as I do. Because nobody can use the command line to run libreoffice without noticing that this feature is missing :-(
Comment 20 Michael Meeks 2021-09-21 18:51:39 UTC
I miss it; but not enough to implement it. Luckily - we now should tolerate zero-byte files and infer the type from the extension, so you can have a shell wrapper that checks if it's not there, and touches it for you if you like. HTH.
Comment 21 Mike Kaganski 2022-08-02 11:54:02 UTC
(In reply to Michael Meeks from comment #20)
> we now should tolerate zero-byte
> files and infer the type from the extension, so you can have a shell wrapper
> that checks if it's not there, and touches it for you if you like. HTH.

I would say, that fixed bug 123476 and bug 139991 together solve this perfectly, in line with the Unix philosophy: you don't need any new switches / command line arguments for LibreOffice to allow all uses listed here.

Basically a one-liner:

> touch ./myNewFileName.odt && soffice ./myNewFileName.odt

which solves both comment 0 (any third-party application can do that), as well as comment 10.
Comment 22 Mike Kaganski 2022-08-02 11:59:48 UTC
... and that has the additional benefit over comment 5, that it (1) doesn't need to create intrusive UI (many people dislike questions on opening); (2) doesn't get in the way of command-line processing of existing documents (when a wrong filename would silently open something empty). One can always create a dedicated 'create_document' shell script that takes an argument, touches the file and opens LibreOffice with the file, to have exactly the wanted functionality.
Comment 23 V Stuart Foote 2024-02-26 12:19:20 UTC
*** Bug 159881 has been marked as a duplicate of this bug. ***
Comment 24 V Stuart Foote 2024-02-26 12:19:50 UTC
*** Bug 159880 has been marked as a duplicate of this bug. ***
Comment 25 lilly2812 2024-03-11 03:09:26 UTC Comment hidden (spam)