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

 
 

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

Submitted by:  Hartmut <hardy>
Submitted on:  Sun 25 Sep 2016 11:17:02 PM UTC  
 
Category: InterpreterSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Regression
Status: FixedAssigned to: None
Originator Name: Open/Closed: Closed
Release: 4.2.0-rc2Operating System: Any

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)

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>
Project 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>
Project Administrator
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>
Project 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:

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):

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

Mike Miller <mtmiller>
Project Administrator
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:

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>
Project Administrator
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

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>
Project Administrator
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

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.

Mike Miller <mtmiller>
Project Administrator
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):
  • 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:

Hartmut <hardy>

 

(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

Digest:
   bug dependencies.

 

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

    Date Changed By Updated Field Previous Value => Replaced By
    Tue 27 Sep 2016 07:43:08 PM UTCrik5StatusConfirmed=>Fixed
      Open/ClosedOpen=>Closed
    Tue 27 Sep 2016 05:45:01 PM UTCmtmillerDependencies-=>bugs #49191 is dependent
    Mon 26 Sep 2016 08:43:04 PM UTCmtmillerCarbon-Copy-=>Added rik5
    Mon 26 Sep 2016 08:42:30 PM UTCmtmillerCarbon-CopyRemoved rik=>-
    Mon 26 Sep 2016 08:41:54 PM UTCmtmillerCarbon-Copy-=>Added rik
    Mon 26 Sep 2016 06:40:26 PM UTCmtmillerCategoryNone=>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.1-cleanup1