bugGNU Octave - Bugs: bug #48105, function "glob" oddities...

 
 

bug #48105: function "glob" oddities with trailing "/"

Submitted by:  None
Submitted on:  Fri 03 Jun 2016 04:02:28 AM UTC  
 
Category: Octave FunctionSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Incorrect Result
Status: FixedAssigned to: Mike Miller <mtmiller>
Originator Name: Originator Email: -unavailable-
Open/Closed: ClosedRelease: 4.0.2
Operating System: GNU/Linux

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 Jump to the original submission)

Sun 05 Jun 2016 02:44:55 AM UTC, comment #9:

Fixed for me as ell. I did have to run 'make maintainer-clean' and 'bootstrap' in order to get the new glob.c copied over to libgnu.

Rik <rik5>
Project Administrator
Sat 04 Jun 2016 02:24:18 AM UTC, comment #8:

Fixed on default for me with an updated gnulib

http://hg.savannah.gnu.org/hgweb/octave/rev/96c56993e679

We typically do not update the gnulib subrepo on the stable branch, so this is fixed for the future 4.2 releases but not for any future 4.0.x bugfix releases.

Mike Miller <mtmiller>
Project AdministratorIn charge of this item.
Sat 04 Jun 2016 01:43:11 AM UTC, comment #7:

My mistake, testing across different versions of gnulib.

Gnulib master glob works correctly, the version that we have in Octave is buggy. This upstream commit fixed a lot of glibc issues:

http://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=36cc6c33ade715a844662cefd256f8f8fdd8a05d

I'll update our copy of gnulib and rebuild and see if this is fixed.

Mike Miller <mtmiller>
Project AdministratorIn charge of this item.
Sat 04 Jun 2016 12:48:06 AM UTC, comment #6:

Hm, maybe it is. I wrote a standalone C++ program to demonstrate this supposed bug with gnulib but it's not giving me the same as Octave does. If I have two files named file1 and file2, Octave's glob("f*/") returns file1 and file2. Calling gnulib::glob from a separate C++ program returns GLOB_NOMATCH.

Mike Miller <mtmiller>
Project AdministratorIn charge of this item.
Sat 04 Jun 2016 12:03:45 AM UTC, comment #5:

So Octave is unconditionally using gunlib's glob which is not equivalent to the shell's glob. It seems like we should just report this upstream, and mark this as not Octave's problem.

Rik <rik5>
Project Administrator
Fri 03 Jun 2016 11:02:56 PM UTC, comment #4:

And I can confirm if I write a short C program using the standard glob function, it also fails to return a matching entry for a matched broken symlink:

While Perl and Python both do return matches for broken symlinks, so they are working around or reimplementing glob to fix this defect.

Mike Miller <mtmiller>
Project AdministratorIn charge of this item.
Fri 03 Jun 2016 10:48:13 PM UTC, comment #3:

At least on my system, the reason gnulib's own glob function is used is the following:

This defect means that gnulib's glob is enabled. Our logic in Octave also unconditionally uses gnulib::glob, so we are currently assuming that it's always enabled.

I didn't know what this test actually means until I looked into it. The gnulib test creates a broken symlink to a non-existent file, then calls glob with a pattern that matches the symlink. If glob returns GLOB_NOMATCH, then it is considered to be broken and gnulib's replacement function is used. I don't know the history of this or on which systems it actually works, if it's something they're trying to get rolled into glibc, etc.

Mike Miller <mtmiller>
Project AdministratorIn charge of this item.
Fri 03 Jun 2016 09:25:35 PM UTC, comment #2:

I'm pretty sure this is a gnulib quirk. I created the same test directory containing two directories and two files

I then used perl, which I believe is linked against the system library version of glob, to check.

So, the first question is why gnulib isn't just using the system version of glob that is defined in glob.h, as long as it is reasonable. I thought gnulib was smart enough not to substitute C code where it didn't have too. Second, since it appears to be using it's own implementation, why doesn't it have it right?

Just to check, I went and edited oct-glob.cc. I changed

to

I then took the gnulib:: namespace decorator off the call to glob and globfree. After re-compiling, Octave returns an empty cell array for the pattern 'f*/'.

Rik <rik5>
Project Administrator
Fri 03 Jun 2016 05:39:10 AM UTC, comment #1:

Thanks very much for the bug report. Confirmed here in the development version of Octave. This may be a bug in the underlying gnulib glob function, which wraps the system glob function in some additional logic. I think it would be worth writing a standalone test function using gnulib's glob to see if it has the same behavior, and report a bug to the gnulib project if so.

Mike Miller <mtmiller>
Project AdministratorIn charge of this item.
Fri 03 Jun 2016 04:02:28 AM UTC, original submission:

After trying many examples, absolute path or relative path, with or without wildcard, it is found that
if the pattern ends with "/" and has three or more characters,
the result will matches not only directories but also ordinary files.

I'm not sure whether this is a bug, although this is different from Unix shells where a pattern ends with "/" matches only directories.

Here is some examples:

OK with only two or less characters:

Incorrect with three or more characters:

Anonymous

 

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

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by rik5 (Posted a comment)
  • -unavailable- added by mtmiller (Posted a comment)
  • -unavailable- added by None (Submitted the item)
  •  

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

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 5 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sat 04 Jun 2016 02:24:18 AM UTCmtmillerStatusIn Progress=>Fixed
      Open/ClosedOpen=>Closed
    Sat 04 Jun 2016 01:43:11 AM UTCmtmillerStatusConfirmed=>In Progress
      Assigned toNone=>mtmiller
    Fri 03 Jun 2016 05:39:09 AM UTCmtmillerStatusNone=>Confirmed

    Back to the top


    Powered by Savane 3.1-cleanup1