Anton Ertl wrote:
Elko Tchernev wrote:
While changing laptops, I installed the latest Win32
self-installing Gforth 0.6.2, and my programs promptly stopped loading,
giving file I/O errors. (Under Win XP Pro). As I've used the previous
0.6.2 self-install with no problems, I had it on my old drive, and when
I replaced the new cygwin1.dll (1,114K, 2004-08-01) with the old one
(949K, 2003-08-30), everything was fine again. The symptom is that
INCLUDED cannot load any file that has directory specifiers in the name.
If I say S" test1.f" INCLUDED, and the file is in the current
directory, it works, but if the command is
S" /elko/work/forth/new-oof/test1.f" INCLUDED, it fails. (It fails with
both dir separators, / and \, while INCLUDE works with the DOS standard
\ separator only).
There is a change in Cygwin1.dll in how it deals with file names.
Essentially, as soon as there is a "\" in the file name, it is now
treated as a DOS/Windows filename, not a Unix one; the "\" may come
from prepending a path component.
Is there a significant reason to use the new cygwin1.dll as opposed
to the old one? I don't see anything wrong with the old one so far, but
maybe there's some hidden issue?
The old cygwin1.dll did not work correctly for W98 and WME, so there
is no reason for you to switch. However, the new directory behaviour
is not considered a bug by the Cygwin maintainers, and is going to
stay (and you will get it with the next Gforth release).
Well, if it is not a bug in cygwin, then it is definitely a bug in
Gforth. An it IS a bug, because it prevents including files with fully
properly specified names. I am not 100% sure, but I think it comes from
the fact that absolut-path? in paths.fs does not consider \ to be an
absolute path prefix (which it is, in Win/DOS). See what happens as a
result of this:
---------------------------------------------------------------------
Gforth 0.6.2, Copyright (C) 1995-2003 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `bye' to exit
s" \elko\work\forth\new-oof\2b-run.f" included redefined >order
in file included from *the terminal*:1
\elko\work\forth\new-oof\2b-run.f:3: File I/O exception
uses evolutionary-programming
^^^^^^^^^^^^^^^^^^^^^^^^
Backtrace:
$4B7AB20 throw
$4B9E1DC included
$4B9E5C4 #included
$4B9DB4C execute
$4B7DC08
$4B9DD94 execute
ofile count type
/usr/local/share/gforth/0.6.2/\elko\work\forth\primitin.f ok
s" \elko\work\forth\new-oof\2b-run.f" absolut-path? . 0 ok
s" /elko/work/forth/new-oof/2b-run.f" absolut-path? . -1 ok
----------------------------------------------------------------------
Obviously, Gforth prepends crap to the beginning of a fully specified
filename. And notice that it has the wrong slashes for this version of
cygwin, so even if it needed to prepend, it wouldn't work. What I don't
understand is why this happens on the second include. (Inside 2b-run.f
there is another INCLUDED with just a filename, in the current
directory, and that works well - Gforth properly prepends
\elko\work\forth\new-oof, and even though it adds the wrong slash - /,
cygwin swallows the resulting mixed name
\elko\work\forth\new-oof/resources.f without a problem.
I would suggest changing absolut-path? to recognize '\ as a valid
full-path specifier.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
