On Fri, Dec 16, 2011 at 09:58:52AM -0800, Eliot Miranda wrote:
> On Thu, Dec 15, 2011 at 6:18 PM, David T. Lewis <lewis at mail.msen.com> wrote:
> 
> > On Thu, Dec 15, 2011 at 02:19:04PM -0800, Eliot Miranda wrote:
> > > Hi All,
> > >
> > >     just noticed that
> > >
> > >         UnixFileDirectory default directoryExists:
> > UnixFileDirectory default asString, '/.'
> > >
> > > answers false, since directoryNames excludes '.' and '..' (justifiable,
> > and
> > > changing this might break all manner of things). i.e.
> > >
> > > FileDirectory>directoryExists: filenameOrPath
> > > "Answer true if a directory of the given name exists. The given name may
> > be
> > > either a full path name or a local directory within this directory."
> > > "FileDirectory default directoryExists: FileDirectory default pathName"
> > >
> > > | fName dir |
> > > DirectoryClass splitName: filenameOrPath to:
> > > [:filePath :name |
> > > fName := name.
> > > filePath isEmpty
> > > ifTrue: [dir := self]
> > > ifFalse: [dir := self directoryNamed: filePath]].
> > >
> > > ^dir exists and: [
> > > self isCaseSensitive
> > > ifTrue:[dir directoryNames includes: fName]
> > > ifFalse:[dir directoryNames anySatisfy: [:name| name sameAs: fName]]].
> > >
> > >
> > > So how about
> > >
> > > FileDirectory class methods for accessing
> > > currentDirectoryNickname
> > >     ^'.'
> > >
> > > FileDirectory>directoryExists: filenameOrPath
> > > "Answer true if a directory of the given name exists. The given name may
> > be
> > > either a full path name or a local directory within this directory."
> > > "FileDirectory default directoryExists: FileDirectory default pathName"
> > >
> > > | fName dir |
> > > DirectoryClass splitName: filenameOrPath to:
> > > [:filePath :name |
> > > fName := name.
> > > filePath isEmpty
> > > ifTrue: [dir := self]
> > > ifFalse: [dir := self directoryNamed: filePath]].
> > >
> > > ^dir exists
> > > and: [fName = self class currentDirectoryNickname
> > >  or: [self isCaseSensitive
> > > ifTrue:[dir directoryNames includes: fName]
> > > ifFalse:[dir directoryNames anySatisfy: [:name| name sameAs: fName]]]]
> >
> >
> > Then how would we handle this:
> >
> >  UnixFileDirectory default directoryExists: UnixFileDirectory default
> > fullName, '/../../.'
> >
> 
> It works fine.  splitPath:... splits it to e.g.
> '/Users/eliot/Squeak/Squeak4.2/../..' and '.' and so the result its true.
>  Note that /.. = / on Unix, so one can't have too many '..' or '.'
> components.   The issue is what is the last component, and if that is '.'
> or '..' then the code I supplied works.
> 


You are right. I had mistakenly remembered '..' as a bit of shell
syntax, which is incorrect. It's part of the file system and the
code works exactly as you say.



> >
> > Or this:
> >
> >  UnixFileDirectory default directoryExists: '/usr/b?n'
> >
> 
> That works if there is a file called b?n.  Using ? as a wild-card is a
> shell facility, nothing to do with the file system.  So this is a
> non-sequitur.
> 
> 
> >
> > There is a reasonable approximation of unix path handling in the
> > CommandShell package (see class ShellSyntax), but IMO this is too
> > complex and platform-specific for general use. Furthermore, the method
> > comment for #directoryExists: says that the path should specify either
> > a full path name or a local directory within the directory, and '/.'
> > does not meet these criteria. So in my opinion, the current behavior
> > is unexpected for a unix user but it is not incorrect, and changing it
> > to work correctly in a unix-like way is not worth the added complexity.
> >
> 
> But you're forcing user code to handle the unexpected, and that's really
> bad.  Peppering code with Smalltalk platformName = 'unix' or: [Smalltalk
> platformName = 'Mac OS'] is an awful approach.  The file system classes
> should be robust, and the issue above affects Windows as well as unix.

That was exactly the point I was trying to make (rather poorly it seems),
so we are in full agreement.


>  Given that the new code handles your objections rationally I respectfully
> disagree,  It *is* worth the minimal added complexity.

I agree. Sorry for the noise.

Dave