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

[John W. Eaton]

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

I'm sure that I copied things like absolute_pathname from bash.  In bash
version 5, the definition is as follows, but it has been similar for many
years.


/* Return 1 if STRING contains an absolute pathname, else 0.  Used by `cd'
   to decide whether or not to look up a directory name in $CDPATH. */
int
absolute_pathname (string)
     const char *string;
{
  if (string == 0 || *string == '\0')
    return (0);

  if (ABSPATH(string))
    return (1);

  if (string[0] == '.' && PATHSEP(string[1]))   /* . and ./ */
    return (1);

  if (string[0] == '.' && string[1] == '.' && PATHSEP(string[2]))       /* ..
and ../ */
    return (1);

  return (0);
}


I probably extracted the check for ./ into a separate function because I
thought that would be useful by itself (I could have been wrong).

In the past, I thought it was useful to have the load-path handle "foo/bar" as
a relative path name.  Now I think it makes better sense (and is much simpler)
to always use absolute names even if the user specifies a relative name. 
Re-scanning relative directories when the current directory changes seems like
trouble (even for ".", but we are stuck with that one).

So maybe the whole idea of a rooted_relative filename is not needed in
Octave?


    _______________________________________________________

Reply to this item at:

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

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