bugGNU Octave - Bugs: bug #49184, working directory removed from...

 
 

bug #49184: working directory removed from path after changing to a pathdef directory

Submitter:  Hartmut <hardy>
Submitted:  Sun 25 Sep 2016 11:17:02 PM UTC
   
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Regression
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * 4.2.0-rc2 Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 27 Sep 2016 07:43:08 PM UTC, comment #7: 

I'm surprised we hadn't been bitten by this bug earlier.  Octave was clearly not doing the correct thing.

I changed load_path::dir_info::update to copy information about a directory from its cache, but not to overwrite the relative dir_name with the absolute name (which happens to be what Octave uses as an index field for the cache).

See cset http://hg.savannah.gnu.org/hgweb/octave/rev/e0a1e8803d8c.

Rik <rik5>
Group administrator
Tue 27 Sep 2016 12:04:34 AM UTC, comment #6: 

Ok, I've narrowed it down to the function load_path::dir_info::update, to give you a starting point

http://hg.savannah.gnu.org/hgweb/octave/file/d16d38338077/libinterp/corefcn/load-path.cc#l56

When this bug occurs, this function has changed the dir_info's dir_name to be the absolute directory, because it was found in the cache of absolute directories. I'm guessing a special case is needed in there to make sure that "." is left alone.

Mike Miller <mtmiller>
Group Member
Mon 26 Sep 2016 11:33:21 PM UTC, comment #5: 

I'm working on finishing up a bug fix for rose.m, and then I'll take a look at this.

Rik <rik5>
Group administrator
Mon 26 Sep 2016 10:47:29 PM UTC, comment #4: 

And another addition. This bug appears to have been present in the load path code for a while, but was hidden by another bug in make_absolute_filename.

The changeset I quoted fixed make_absolute_filename so that works like this:


In Octave 3.6.4 through 4.0.3:
>> cd /tmp
>> make_absolute_filename .
ans = /tmp/

In Octave 4.2:
>> cd /tmp
>> make_absolute_filename .
ans = /tmp


This fix revealed the bug that was always present in load-path.cc, which can be shown going back to 3.6.4 with the following code (it must be / because of the trailing slash behavior I showed above):


>> addpath /
>> rmpath /
>> cd /
>> cd
>> path


After this command sequence, the load path will no longer contain the "." entry.

Mike Miller <mtmiller>
Group Member
Mon 26 Sep 2016 09:58:00 PM UTC, comment #3: 

One further clarification: when the current directory is changed to a directory that exists elsewhere on the load path, the entry that was previously "." is transformed into the full path of the working directory. The user is thus left with two duplicates of a given directory on the load path, and the "." entry is gone.

Example:


>> s = strsplit (path, pathsep); s(1)
ans =
{
  [1,1] = .
}
>> addpath /tmp
>> s = strsplit (path, pathsep); s(1:2)
ans =
{
  [1,1] = .
  [1,2] = /tmp
}
>> cd /tmp
>> s = strsplit (path, pathsep); s(1:2)
ans =
{
  [1,1] = /tmp
  [1,2] = /tmp
}
>> cd
>> s = strsplit (path, pathsep); s(1:2)
ans =
{
  [1,1] = /tmp
  [1,2] = /tmp
}
>> addpath .
>> s = strsplit (path, pathsep); s(1:3)
ans =
{
  [1,1] = .
  [1,2] = /tmp
  [1,3] = /tmp
}
>>


I am guessing that the change that causes this has to do with when the string "." is transformed into the absolute path of the current directory, and the way the load path is using the absolute names of path entries. It probably needs some special handling now to ensure that the "." entry is not lost or transformed inadvertently, but I haven't found where this needs to be done yet.

Mike Miller <mtmiller>
Group Member
Mon 26 Sep 2016 08:41:54 PM UTC, comment #2: 

I bisected this problem to the following cset (adding Rik in cc):

http://hg.savannah.gnu.org/hgweb/octave/rev/8df31c24dce3

I used the following simple command to test whether Octave was affected at each revision to narrow down to this change


$ ./run-octave --eval 'cd scripts; any (strcmp (strsplit (path, pathsep), "."))'


After this change, the "." directory is removed from the load path after changing the working directory to one that is in the default startup path.

Mike Miller <mtmiller>
Group Member
Mon 26 Sep 2016 06:40:26 PM UTC, comment #1: 

I can reproduce this bug in one less step.

Simply create a script in the current directory, like


>> type good_script
good_script is the user-defined function defined from: /home/mike/good_script.m

a = 12;


Then change the working directory to one of the directories that are in the default path (pathdef). The working directory "." gets removed from path at this point. Changing back to my home directory does not re-add it.


>> pwd
ans = /home/mike
>> s = strsplit (path, pathsep); s{1}
ans = .
>> cd /opt/gnu/octave/share/octave/4.2.0-rc2/m
>> cd
>> pwd
ans = /home/mike
>> s = strsplit (path, pathsep); s{1}
ans = /opt/gnu/octave/share/octave/4.2.0-rc2/m


Mike Miller <mtmiller>
Group Member
Sun 25 Sep 2016 11:17:02 PM UTC, original submission:  

I have observed this with the current Octave 4.2.0-rc2 version under Linux (self compiled on Ubuntu 14.04) as well as under Windows 7 (official exe installer from alpha.gnu.org).

Here is how to reproduce the behavior under Linux:

  • Generate the following m-file script in any folder of your home directory (I gave it the name buggy_script.m):


cd "/opt/octave-4.2.0-rc2/scripts"
clear b
a = b

  • Maybe change the folder name in the script to match your current installation of Octave 4.2.0-rc2
  • Load the script into the GUI editor
  • Press the run button in the GUI editor, and click "yes" on the following "do you want to change your working directory" button.
    • result: "error: 'b' undefined near line 3 column 7"
  • Press the run button AGAIN in the GUI editor.
    • result: "error: 'buggy_script_linux' undefined near line 1 column 1"


At the end, the relevant script file IS in the current working directory. Doing a simple "ls" command from the Octave CLI will show you it's there. But you won't be able to run it any more from the GUI editor. You cannot even start this script by typing its name into the Octave command line any more.

To this seems as if the logic of the current working directory gets distorted by this. This is a regression, because it works fine under Octave 4.0.3.

The corresponding script to make this bug "work" under Windows is for example:

cd "opt/octave-4.2.0-rc2/share/octave/4.2.0-rc2/m"
clear b
a = b


Hartmut <hardy>

 

(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

Digest:
   bug dependencies.

 

Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by mtmiller
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by hardy (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 9 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-09-27 rik5 StatusConfirmed Fixed
        Open/ClosedOpen Closed
    2016-09-27 mtmiller Dependencies- bugs #49191 is dependent
    2016-09-26 mtmiller Carbon-Copy- Added rik5
    2016-09-26 mtmiller Carbon-CopyRemoved rik -
    2016-09-26 mtmiller Carbon-Copy- Added rik
    2016-09-26 mtmiller CategoryNone Interpreter
        StatusNone Confirmed
        Summaryworking directory logic seems sometimes distorted working directory removed from path after changing to a pathdef directory

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code