[Octave-bug-tracker] [bug #58547] gzip()/bzip2() do not handle relative paths in first argument correctly

[Carnë Draug]

Follow-up Comment #7, bug #58547 (project octave):

I would argue that "foo/bar" is a relative path, just like "./foo/bar". Why is
it not a relative path? And what kind of path it is then?

> This is not an absolute path, and let's assume there is no subdirectory of
the current directory named "Mickey_Mouse".  In that case, both tests return
false--this is not a pathname--and the string is returned unaltered. 

There being no such subdirectory is irrelevant. The behaviour of such
functions should not be dependent on what directories exist at the moment on
the current working directory. We may be manipulating paths with the aim of
creating them or we may be handling paths relative to somewhere else. This
should return the string unaltered because there is no file separator,
therefore its value is the basename part of the filepath. This is the
behaviour in Linux basename command, on perl, on php, on python, and C++17
std::filesystem::path so it's very surprising that Octave does something
different.

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?58547>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/