Should FileDirectory paths have a dirsep on the end or not?

Tim Rowledge rowledge at interval.com
Mon May 4 01:37:45 UTC 1998


On Sun 03 May, Maloney wrote:

> The intended spec is that sending pathName to an instance of
> FileDirectory (or one of its platform dependent subclasses) should
> return a pathName that does NOT end in a separator character, so
> your directory primitives are correct.
Oh good. I was beginning to wonder if anything else was likely to go wrong.
> 
> We should fix the PWS code to not expect a trailing separator,
> then make FileDirectory class>on: strip off a trailing separator
> if one is supplied.
Definitely. It ought to do more checking for bad characters etc as well.
 
> P.S. Do you have a pointer to the problem methods in PWS?
It was SwikiAction class>setUp: that caused the problem. There is a line
'dir _ FileDirectory on: (ServerAction serverDirectory).
 (dir directoryNames includes: actionName)......'
and if I put a dirsep at the end of the server dirname, the directoryNames
is empty, so obviously the system decides I don't have a suitable directory
with which to work. If I cut the dirsep, that part works, but later code in
the same method assumes the dirsep to be there ie:-
'((FileStream fileNamed: (ServerAction serverDirectory),'swiki',.....'
which is going to make a path like ...foo.barswiki instead of
.....foo.bar.swiki and confuse things!

> I noticed that ServerAction>serverDirectory is assumed to
> return a path ending in a delimiter for convenience, but
> that seems fair since it is used only as a prefix string
> to construct file names.
Unfortunately not so in the setUp: code, hence the problem I had. Wouldn't
it be better to create and use the FileDirectory object anyway, rather than
repetitively building strings into paths without a decent protocol to
handle pathname rules?

tim
-- 
Useful random insult:- Subtle as a well-thrown brick.
Tim Rowledge:  rowledge at interval.com (w)  +1 (650) 856-7230 (w)
 tim at sumeru.stanford.edu (h)  <http://sumeru.stanford.edu/tim>





More information about the Squeak-dev mailing list