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

 
 

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

Submitter:  Rik <rik5>
Submitted:  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:  rik5
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

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>
Group administrator
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>
Group administrator
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>
Group administrator
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>
Group administrator
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>
Group administrator
Wed 19 Feb 2020 12:47:30 AM UTC, comment #8: 
Rik <rik5>
Group administrator
Wed 19 Feb 2020 12:31:58 AM UTC, comment #7: 
Rik <rik5>
Group administrator
Wed 19 Feb 2020 12:12:49 AM UTC, comment #6: 
Rik <rik5>
Group administrator
Wed 19 Feb 2020 12:11:56 AM UTC, comment #5: 
Rik <rik5>
Group administrator
Tue 18 Feb 2020 11:59:52 PM UTC, comment #4: 
Rik <rik5>
Group administrator
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>
Group administrator
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>
Group administrator
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>
Group Member
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>
Group administrator

 

(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)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group 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.13-4448.
    Corresponding source code