Mon 20 Jan 2014 03:02:12 AM UTC, comment #10:
Reading through this bug report history, this bug does indeed look identical to bug #31080. User m-files are not found in a root directory of a Windows filesystem because the root directory does not have a modification timestamp associated with it. There is probably a similar bug with network shares.
Closing as duplicate, please post further comments to bug #31080.
|
Fri 10 Feb 2012 03:25:09 PM UTC, comment #9:
Rik,
my previous comment contained an inaccuracy:
I DO have a debug version of octave-3.4.2 lying around, and it shows the error.
How can I proceed? (how to set a breakpoint where; what variables to inspect; etc).
|
Fri 03 Feb 2012 07:54:12 PM UTC, comment #8:
Here you go:
octave:6> isdir ('F:')
ans = 1
octave:7> isdir ('F:\')
ans = 1
octave:8> isdir ("F:\")
error: unterminated string constant
parse error:
syntax error
>>> isdir ("F:\")
^
octave:8> isdir ("F:\\")
ans = 1
octave:9> isdir ("F:/")
ans = 1
octave:10> isdir ("F:/svn/octave.sf.net")
ans = 1
octave:11>
Unfortunately I have no debug Octave. Tatsuro might have.
The backslash is a problematic character on Windows, as far as Octave goes.
But even while using Octave on Windows, I often use forward slash rather than backslash in path names - it works as good as a backslash (!), as you can see above in prompts 9 & 10.
In my .octaverc file I have forward slashes in all path names (to default dir, to Notepad++ editor, etc).
Perhaps this is a way out? to simply skip "filesep" - I can only guess that the MinGW file I/O libs substitute the proper file separator at the right time.
|
Fri 03 Feb 2012 07:17:49 PM UTC, comment #7:
I think you have discovered something. I tried something similar using the root directory on a Unix box, but everything worked. On UNIX the file separator is '/'. I think the file separator being '\' on Windows, and the fact that this is often a reserved escape character, is probably causing problems.
What does "isdir ('F:\')" return? The single quotes are necessary to prevent the '\' character as being treated as special.
I don't think this problem would be very hard to resolve if you were to just step through the code being executed. Do you have access to a version compiled with support for gdb? If you can compile from source I can help set up the flags for debug compilation correctly and in running gdb.
|
Fri 03 Feb 2012 05:45:20 PM UTC, comment #6:
octave:3> edit scrpt.m
:
...editing script.m
:
octave:4> scrpt
error: `scrpt' undefined near line 4 column 1
octave:4> ls
Volume in drive F is BIGWIN1
Volume Serial Number is 746C-E43B
Directory of f:\
[AthlonXP_WinXP] [tmp] [GPS_Maps] NZ_Uitgaven.xls [Mail_BU]
[Home] scrpt.m [Waternet&WLB] BigWin1
[svn] X3SPOEM_EN.iso [Literatuur] [Garmin]
BIRDS20.ISO [Projecten] [MSPIe] [dfsee]
5 File(s) 1 233 603 926 bytes
12 Dir(s) 1 586 806 784 bytes free
octave:5> file_in_loadpath ("scrpt.m")
ans =
octave:6>
As you can see, ls sees scrpt.m, but file_in_loadpath doesn't.
Could it be related to the trailing backslash in "F:\" ?
|
Fri 03 Feb 2012 05:23:02 PM UTC, comment #5:
I don't have a Windows machine so helping with the debug is difficult. I'd like to understand more about how Octave is not seeing the directory.
After you add a new m-file, say "NEW_FILE.m", to a root directory while still in Octave, what is the result of
I'm trying to understand whether Octave doesn't really see the file, or if the caching mechanism for m-files is somehow filtering it out.
|
Fri 03 Feb 2012 03:43:40 PM UTC, comment #4:
AFAICS this is a duplicate of bug #31080 and -indeed- #33389 (although the latter bug report contains too little informative to find out what is going on).
The issue is that Octave doesn't seem to pick up all changes in "." (current directory) until a restart, if that directory is the root of the drive.
On my home network, Octave 3.6.0 MinGW does pick up and run m-files on network shares, be it in the root or in subdirs.
Once Octave is up and running, and an m-file is added in the root of any drive (network share, thumb drive, local drive), Octave will see it (through "dir" or "ls") but isn't able to run it.
|
Thu 03 Nov 2011 07:31:06 PM UTC, comment #3:
It would be useful if someone could test whether this bug has been resolved. I don't know if you are using Cygwin or MinGW. Instructions for both are at http://wiki.octave.org/wiki.pl?OctaveForWindows. You will need to scroll down to discover a 3.4.3 MinGW version or a 3.4.2 Cygwin version.
|
Thu 03 Nov 2011 06:15:43 PM UTC, comment #2:
After reviewing of the referenced bug I have determined that it is in fact the network share not the fact that it was a removable drive mapped to a virtual disk drive letter via the subst command.
I am running Windows XP and the current windows distribution is 3.2.4. I am guessing that I would need to download the current version and compile it? I will actually be happy to help do this if you are unsure that the bug has been fixed and you need it tested. Otherwise my immediate needs are met. If I knew how to update the windows distribution I would also do that.
|
Thu 03 Nov 2011 04:58:30 AM UTC, comment #1:
This appears to be related to bug #33389. The 3.2.4 release is deprecated and no longer supported. Can the reporter try upgrading to the 3.4.X series?
|
Thu 03 Nov 2011 02:29:55 AM UTC, original submission:
When attempting to run an m-file script from a removable drive with a link to a virtual drive octave responds:
=============================================================
octave-3.2.4.exe:5> rf
error: `rf' undefined near line 5 column 1
octave-3.2.4.exe:5>
=============================================================
but;
=============================================================
octave-3.2.4.exe:5> dir
. cvsproj.configurations elecproj.current
.. cvsproj.current mathproj.current
RECYCLER elecproj.configurations rf.m
octave-3.2.4.exe:6>
=============================================================
If the directory tree is copied to a local drive and the octave directory changed to the directory containing the file rf.m again the file will be found and parsed.
|