bugGNU Octave - Bugs: bug #57830, rmdir and other file functions...

 
 

bug #57830: rmdir and other file functions should not return status unless nargout > 1

Submitted by:  Rik <rik5>
Submitted on:  Sun 16 Feb 2020 06:14:36 PM UTC  
 
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Matlab Compatibility
Status:  Fixed Assigned to:  Rik <rik5>
Originator Name:  Open/Closed:  Closed
Release:  dev Operating System:  Any

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Wed 19 Feb 2020 06:50:49 PM UTC, comment #14: 

I added a note to the NEWS file about all the changes from this bug report.

- Many functions in Octave can be called in a command form---no
parentheses for invocation and no return argument assignment---or in a
functional form---parentheses and '=' for assignment of return values.

    Command Form Example

    `mkdir new_directory`

    Function Form Example

    `status = mkdir ("new_directory")`

    Octave now handles errors that occur in a consistent manner.  If
    called in command form and there is a failure, an error is thrown
    and a message printed.  If called in functional form, no error or
    message is printed and the failure is communicated to the programmer
    via the output status variable.

    The following list of functions have been modified.

    * `copyfile`
    * `fcntl`
    * `fileattrib`
    * `kill`
    * `link`
    * `mkfifo`
    * `movefile`
    * `rename`
    * `rmdir`
    * `symlink`
    * `unlink`

Finally, marking this bug as fixed and closing this report.

If further examples of functions are found which need the same changes, please file a new bug report about those.

Rik <rik5>
Project AdministratorIn charge of this item.
Wed 19 Feb 2020 04:21:58 PM UTC, comment #13: 

fileattrib.m required a real overhaul.  It is still not Matlab compatible because it only allows read access to file attributes, while the Matlab version allows write access as well.  I'll file a different bug report about that.  See changeset https://hg.savannah.gnu.org/hgweb/octave/rev/ff3b8b21a890.

Rik <rik5>
Project AdministratorIn charge of this item.
Wed 19 Feb 2020 04:15:25 PM UTC, comment #12: 

@Guillaume: Yes, I see the same thing.  We're dealing with an unfortunate choice by Matlab.  In UNIX environments, the return value from a function call is most often an "int" where a value of 0 indicates success, and any non-zero value indicates failure.

First, Matlab chose to reverse this convention so that a return value of 1 indicates success and a value of 0 indicates failure.  For compatibility, this means Octave becomes more confusing because Matlab-compatible functions have to use this convention, but Octave extensions such as the 'stat' function follow the C library convention and return 0 on success.

Second, Matlab chose to change the type of the status output from int to logical.  This is a shame because it allows only one binary bit of information to be communicated.  If an 'int' were used you could encode information in the return value.  For example, values greater than 1 might indicate a failure, but not a severe one, more like a warning.  Values less than 1 could indicate true failure, and 0 would mean success.  In any case, none of that is possible for functions which must follow Matlab exactly.

As an aside, I find Matlab documentation hard to understand sometimes.  For 'mkdir', they say that the return value on success is 1.  It is only if you read closely do you find that the data type is logical.  It would have been much more straightforward if they simply said, the return value was true on success and false on failure.

I don't have any objections to making the return data type in Octave also a logical value.  However, could you file a separate bug report about any instances you find?

Rik <rik5>
Project AdministratorIn charge of this item.
Wed 19 Feb 2020 12:27:32 PM UTC, comment #11: 

Thanks for this, Rik. I notice you use a numeric output instead of logical, for Matlab compatibility:
http://hg.savannah.gnu.org/hgweb/octave/rev/cd7331af2e97
but this does not correspond to what I can observe with R2019b:

>> sts = mkdir ("/foo")

sts =

  logical

   0

>> sts = rmdir ("/foo")

sts =

  logical

   0

Guillaume <gyom>
Wed 19 Feb 2020 01:49:36 AM UTC, comment #10: 

A fix for movefile checked in here: https://hg.savannah.gnu.org/hgweb/octave/rev/b2e0a2ddfd7d.

Rik <rik5>
Project AdministratorIn charge of this item.
Wed 19 Feb 2020 01:28:45 AM UTC, comment #9: 

A fix for copyfile checked in here: https://hg.savannah.gnu.org/hgweb/octave/rev/1cb3c33f97dc.

Rik <rik5>
Project AdministratorIn charge of this item.
Wed 19 Feb 2020 12:47:30 AM UTC, comment #8: 
Rik <rik5>
Project AdministratorIn charge of this item.
Wed 19 Feb 2020 12:31:58 AM UTC, comment #7: 
Rik <rik5>
Project AdministratorIn charge of this item.
Wed 19 Feb 2020 12:12:49 AM UTC, comment #6: 
Rik <rik5>
Project AdministratorIn charge of this item.
Wed 19 Feb 2020 12:11:56 AM UTC, comment #5: 
Rik <rik5>
Project AdministratorIn charge of this item.
Tue 18 Feb 2020 11:59:52 PM UTC, comment #4: 
Rik <rik5>
Project AdministratorIn charge of this item.
Tue 18 Feb 2020 11:49:48 PM UTC, comment #3: 

I fixed link, symlink in this changeset: https://hg.savannah.gnu.org/hgweb/octave/rev/e8246b4a5459.

Rik <rik5>
Project AdministratorIn charge of this item.
Sun 16 Feb 2020 10:33:08 PM UTC, comment #2: 

For functions which always return a value, and their status and error message are simply opional argout, it isn't necessary to throw an error.  In that case, the returned value is either the requested information, or a null string or other "bad" value, so the exit status of the operation is always communicated.

For example, for waitpid,

If the returned value of PID is greater than 0, it is the process
ID of the child process that exited.  If an error occurs, PID will
be less than zero and MSG will contain a system-dependent error
message.  The value of STATUS contains additional system-dependent
information about the subprocess that exited.

But, you're right that these three functions should behave similarly

copyfile
movefile
fileattrib

Of the last three, 'exec' is just weird and probably doesn't need special treatment.

If successful, 'exec' does not return.  If 'exec' does return, ERR
will be nonzero, and MSG will contain a system-dependent error
message.

Most of the time, there will never be an exit status.  If it does return, that implies there was an error.  Maybe that means we shouldn't even bother to return status since it is redundant with continuing execution of the m-file, but I don't think we need to be too worry too much here.  'exec' isn't a Matlab function so we can do what we want, and I don' think this gets much use anyways.

I do agree that

fcntl
kill

seem like they should base their behavior on nargout.

Rik <rik5>
Project AdministratorIn charge of this item.
Sun 16 Feb 2020 06:39:09 PM UTC, comment #1: 

How about system functions that also return a value in addition to a status flag and error message? Should these throw an error if nargout < 2 (or nargout < 3 in the case of 'pipe')?

  • lstat
  • pipe
  • readdir
  • readlink
  • stat
  • uname
  • waitpid

More functions that I think fit your original criteria, first those that are in Matlab, so we can test whether they need to be changed:

  • copyfile
  • fileattrib
  • movefile

And these POSIX system functions similar to the others you listed:

  • exec
  • fcntl
  • kill
Mike Miller <mtmiller>
Project Administrator
Sun 16 Feb 2020 06:14:36 PM UTC, original submission:  

This bug is similar to bug #57799 which resolved the same situation for mkdir().

The Matlab compatibility issue regards file functions (such as rmdir) when called with no output arguments, or more than 1 output argument (nargout > 1).

In Matlab, when called with no output arguments, and the file operation fails, an error is thrown and a message printed to the screen.  If there is at least one output argument (status) then no error is thrown because the failure of the operation is signaled through the return variable instead.  This is a sensible pattern that Octave should follow as well.

Functions which appear to require changeover are:

link
symlink
rename
rmdir
unlink
mkfifo

Rik <rik5>
Project AdministratorIn charge of this item.

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by gyom (Posted a comment)
  • -email is unavailable- added by rik5 (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-02-19 rik5 StatusIn Progress => Fixed
        Open/ClosedOpen => Closed
    2020-02-19 rik5 Assigned toNone => rik5
    2020-02-18 rik5 StatusConfirmed => In Progress

    Back to the top


    Powered by Savane 3.5