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. ***

I would also like to see this happening.

*** Bug 93345 has been marked as a duplicate of this bug. ***

The related behaviour about respecting paths (as in comment 10) is also needed. This really slows down what is otherwise a standard workflow.

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"
}

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

I would also appreciate this feature very much.

*** Bug 117363 has been marked as a duplicate of this bug. ***

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 :-(

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.

(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.

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

*** Bug 159881 has been marked as a duplicate of this bug. ***

*** Bug 159880 has been marked as a duplicate of this bug. ***