octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #39684] WHAT function lists wrong directory


From: anonymous
Subject: [Octave-bug-tracker] [bug #39684] WHAT function lists wrong directory
Date: Sat, 03 Aug 2013 22:33:56 +0000
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/536.30.1 (KHTML, like Gecko) Version/6.0.5 Safari/536.30.1

URL:
  <http://savannah.gnu.org/bugs/?39684>

                 Summary: WHAT function lists wrong directory
                 Project: GNU Octave
            Submitted by: None
            Submitted on: Sat 03 Aug 2013 10:33:55 PM UTC
                Category: Octave Function
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: Incorrect Result
                  Status: None
             Assigned to: None
         Originator Name: Ben Kurtz
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
                 Release: 3.6.1
        Operating System: Any

    _______________________________________________________

Details:

The "what" function is documented as

w = what (DIR)
     List the Octave specific files in directory DIR


However, the test in the code doesn't actually behave this way.  Specifically,
the code uses strfind without any backup checks, such that you can get things
like the result below, where the input to what() doesn't match the directory
looked up, or even any whole directory name.


octave:3> x = what('o')
x =

  scalar structure containing the fields:

    path = /usr/local/Cellar/octave/3.6.1/share/octave/3.6.1/m/time
    m = 
    {
      [1,1] = addtodate.m
      [1,2] = asctime.m
      [1,3] = calendar.m
      [1,4] = clock.m
      [1,5] = ctime.m
      [1,6] = date.m
      [1,7] = datenum.m
      [1,8] = datestr.m
      [1,9] = datetick.m
      [1,10] = datevec.m
      [1,11] = eomday.m
      [1,12] = etime.m
      [1,13] = is_leap_year.m
      [1,14] = now.m
      [1,15] = weekday.m
    }
    mex = {}(0x1)
    oct = {}(0x1)
    mat = {}(0x1)
    mdl = {}(0x1)
    p = {}(0x1)
    classes = {}(0x1)


This leads to very frustrating results if I want to use what to look up the
contents of any directory that has subdirectories, or any directory that
happens to match any part of the path to the octave root.

The current implementation does one of two things for matching the directory
name:
1. if the input DIR does not contain pathsep(), returns the last item on the
user's path that matches DIR, irrespective of where that pathname matches
2. otherwise interpret DIR as being relative to the current working directory,
and error if it does not exist.

This is incorrect in between 1 and 3 ways depending on how well you want to
match MATLAB's behavior:
1. DIR should match the name of the directory being looked up, not earlier in
the path, i.e. it should be anchored at the end of the path being matched, and
should not be allowed to match partial directory names
2. DIR should be able to match locations in the user's path, even if it
contains pathsep; conversely, even if DIR doesn't contain pathsep, it should
match a subdirectory of the current working directory.
3. If multiple directories match, info about all of them should be returned,
rather than the last one.

I'm thinking the implementation would be something like:
1. construct a list of all directories in the path and all directories in the
current directory.
2. split each item in your list on pathsep(). similarly, split DIR on
pathsep().
3. say the split form of DIR contains N items.  remove all but the last N
items from all fields in your list
4. call isequal on each item in the list vs the split form of DIR to find the
ones that match
5. support returning info for multiple directories




    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?39684>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]