Thanks, Bert.  There was a missing period in your example, which I 
fixed, but with this fix, I can't read books on Macs anymore!  The 
filename now has a leading ":" <sigh>

I'll dig further and see if I can fix this.  Thanks!
   Mark

At 6:32 PM +0100 1/20/00, Bert Freudenberg wrote:
>On Wed, 19 Jan 2000, Mark Guzdial wrote:
>
> > I'm producing BookMorphs for my lectures this term, and my
> > Linux-using students say that they can't read them. They say that
> > they try to load the book from the FileList, and they do get the
> > control buttons across the top, but no page.  When they click "next
> > page" they get told that the file does not exist.  Are any other
> > Linux-users having similar problems with BookMorphs?
> >
> > The bookmorphs are zipped at http://coweb.cc.gatech.edu/cs2340/7  if
> > you're looking for some examples to try.
>
>Hi Mark,
>
>that's a serious bug, though it seems unrelated to the operating system. I
>just looked into this and when debugging I managed to hang my Squeak which
>never happens otherwise.
>
>The root of the problem are file urls. The book loads fine, but the page
>looks for an url "file://var/Squeak/2.7/markbook/ch2-p1-tour1.sp", which
>is wrong, it should be file:/var/ ... Anyway, the resulting file path is
>"var/Squeak/2.7/markbook/ch2-p1-tour1.sp" which is wrong since the leading
>slash is missing. The default directory is "/var/Squeak/2.7". This leads
>to the absolute file
>"/var/Squeak/2.7/var/Squeak/2.7/markbook/ch2-p1-tour1.sp" since it is
>treated as relative path.
>
><btw>
>  It is a a popular fallacy to take "something://" as the beginning
>  (uninteresting) part of an URL. "something:" specifies a scheme,
>  "//something" specifies an authority, and "/something" the path.
>
>	see http://www.faqs.org/rfcs/rfc2396.html
>
>  For file urls, this means that file:/path is okay as is
>  file://localhost/path. Netscape does accept both as well as except
>  file:///path, but in file://something  "something" is looked up as host.
>  A relative file would be file:relpath.
></btw>
>
>Okay, I digged a little deeper into this.
>
>The bug is in FileUrl>>pathForDirectory which ignores the isAbsolute inst
>var. The reason why it still works on a Mac seems to be
>MacFileDir>>fullPathFor: aPath - it simply does not check if aPath is
>absolute or relative, whereas the Win / Unix variants do. I'd consider the
>Mac behaviour a kludge that covers other inconsistencies.
>
>Anyway, here's a FIX. I'm not sure if this works on Mac/Windows. There
>should be a way to generate an absolute filepath from its components.
>
>-------------------------
>!FileUrl methodsFor: 'access' stamp: 'bf 1/20/2000 18:17'!
>pathForDirectory
>  "Path using local file system's delimiter.  $\ or $:"
>
>  ^ String streamContents: [ :s |
>    isAbsolute ifTrue:[ s nextPut: FileDirectory pathNameDelimiter]
>    1 to: self path size - 1 do: [ :ii |
>      s nextPutAll: (path at: ii); nextPut: FileDirectory pathNameDelimiter
>       ] ]! !
>-------------------------
>
>But still, several methods wrongly generate file:// urls (like
>FileDirectory>>url, FileStream>>url, FileUrl>>totext). These should be
>corrected.
>
>  -Bert-

--------------------------
Mark Guzdial : Georgia Tech : College of Computing : Atlanta, GA 30332-0280
(404) 894-5618 : Fax (404) 894-0673 : guzdial at cc.gatech.edu
http://www.cc.gatech.edu/gvu/people/Faculty/Mark.Guzdial.html