Attempt to create a new spreadsheet, from the command line:

    % F=/tmp/whatever.gnumeric
    % ls $F 	# show it doesn't exist
    ls: cannot access /tmp/whatever.gnumeric: No such file or directory
    % gnumeric $F ; echo $?
    0

An error window pops up, it says:

    /tmp/whatever.gnumeric: No such file or directory

The exit code '0' seems inappropriate.

But why not create a new file?  Both 'siag' and 'kspread' can.

Hope this helps...

I do not see a problem here. Quite contrary, it seems that this
particular behaviour was implemented deliberately.

I agree that for command-line utility the described behaviour would
undoubtedly make sense. However for GUI application like `gnumeric` I
don't see value in the proposal and I'm not convinced that `gnumeric`
should behave as other application(s). Besides implementation of
desirable behaviour (as described in bug report) can hardly be
straightforward.

For instance there are too many tricky situations that make it
difficult to return "correct" exit code if user changed her/his mind
and decided not to save the document or to save it to another file or
even change file format on save... What error code to return if empty
file with no data was saved (is it error or not)?

Another challenge is detection (and enforcing) file format and locking
save operation to it, etc.

When scripting it is easy to test whenever expected file was created
by using the following check (or similar):

    [ -s "file.gnumeric" ]

So my resolution is "wontfix" and I'm closing this bug as there is
nothing left for maintainer to do about it.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 571286@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

All the best,
 Dmitry Smirnov
 GPG key : 4096R/53968D1B

---

We must conduct research and then accept the results. If they don't
stand up to experimentation, Buddha's own words must be rejected.
        -- Tenzin Gyatso, 14th Dalai Lama, "Time" April 11, 1988

Doesn't seem difficult.  Let's work backwards...

1) An empty spreadsheet file with "no data" cannot be simpler.

Consider the minimal invocation:

	% gnumeric

Gnumeric then creates a blank spreadsheet, and even offers a name, "Book1".
Suppose the User then presses <Ctrl-S>, <Enter>, and <Ctrl-Q>.  The result
is a new file:

	% ls -log Book1.gnumeric
	-rw-r--r-- 1 1704 Jun 26 03:36 Book1.gnumeric

Note how it's 1704 bytes.  Those 1704 bytes comprise a correctly
formatted blank spreadsheet.  Rather like a printed paper & ink form,
not yet filled out by a human.

Now suppose this bug was fixed as I'd prefer:

	% gnumeric foo.gnumeric

Followed, (same as before), by the User pressing <Ctrl-S>, <Enter>, and
<Ctrl-Q>.  Which we suppose to produce this:

	% ls -log foo.gnumeric
	-rw-r--r-- 1 1704 Jun 26 03:48 foo.gnumeric

No need for an error code.


2) User changes format to '.ods'.  Same as before but:

	% ls -log Book1.ods foo.ods
	-rw-r--r-- 1 5209 Jun 26 03:55 Book1.ods
	-rw-r--r-- 1 5209 Jun 26 03:55 foo.ods

No need for an error code for either file.


3)  Save to another filename, i.e. "File>Save As":

	% ls -log bar.gnumeric
	-rw-r--r-- 1 1704 Jun 26 03:48 bar.gnumeric

No need for an error code.


4) User quits without saving.  Same as when the user doesn't save "Book1".
No need for an error code.


Summing up, to fix this bug, just parse the command line, and if there's a
nonexistent file name 'foo', rename the current default of 'Book1' to 'foo'.


If you agree, (and have no further difficulties in mind), please kindly
reopen this bug.

Dear A. Costa,

Thanks for your comments.

Perhaps it is up to upstream to decide on this matter. I invite you to
take this discussion to corresponding upstream bug report and share
your ideas there:

https://bugzilla.gnome.org/show_bug.cgi?id=633826

At the moment I re-opened bug so we could track upstream progress.

Best wishes,
 Dmitry Smirnov
 GPG key : 4096R/53968D1B