Re: [cc65] Common macros for dirent.d_type

On Tue, Jun 26, 2012 at 9:25 AM, Oliver Schmidt <ol.sc@web.de> wrote:

>
> If we would agree on the getcwd() idea than we could extend it and
> claim that any return value from readdir() with _DE_ISDIR() being true
> is _AS-IS_ a valid parameter for chdir() - this implies that chdir()
> works with relative paths. As you may guess by now I implemented it
> that way for the Apple II.
>
> With these things in place one could already implement a cross-target
> directoy tree traversal without fiddling with directory separators and
> alike:
>
> ==========
>
> dodir() {
>  char thisdir[FILENAME_MAX];
>
>  getcwd(thisdir, sizeof(thisdir));
>
>  opendir(thisdir);  // no prefix or postfix or <you name it>
>  while(...) {
>    e = readdir(...);
>    if (_DE_ISDIR(e->d_type)) {
>      chdir(e->d_name);  // no prefix or postfix or <you name it>
>      dodir();  // recursion
>    }
>  }
>  closedir();
>
>  chdir(thisdir);
> }
>
> ==========
>
> If we would agree on this then the "only" thing missing would be to
> set the initial directory to something "outside" the current directory
> on program startup. While I'm open for any discussion I presume that
> our targets (and ideas ;-) are just too different to get something
> cross-target done.
>

As usual, things are more complicated on the CBM platform.  Directories are
not part of CBM-DOS and are extensions to be implemented by individual
drives.  *MOST* devices with directories on the CBM platform follow the
CMD-DOS "standard", but this is not always true.  For example, the current
release version of VICE has a custom file system that does not adhere to
the CMD-DOS methodology.  Groepaz is working to fix this, but the reality
is that older versions of VICE will always have this problem.  Another
major drive system that has this problem is 64HDD which follows a
Microsoft-like notation for navigating directories.  This is why I
implemented a custom pathing mechnism in EasyCLI.  A "standard"
implementation of the directory functions will need to account for all of
these variations and it will be a nightmare to maintain.  We could aim for
the greatest common denominator, which would be the CMD-DOS standard, but
be prepared for XXX program fails when I run it on YYY device.

Although EasyCLI has a custom pathing mechanism it's still far from
comprehensive.  One thing I've contemplated doing is adding an enum for the
directory dos type that is applied to a device struct.  This dos type enum
would drive the behavior of the pathing mechanism and would make the code
cleaner.

To give you an example of how complex it is to change directories on the
CBM platform here's a link to the code for the CD command of EasyCLI.  It's
still too simple as it doesn't handle 64HDD notation.

http://easycli.codeplex.com/SourceControl/changeset/view/92134#2258510

Now, let's make things even MORE complicated and talk about absolute
paths.  On the CBM platform, there's really no such thing as an absolute
path because no one standard handles drive picking.  This was the main
impetus of creating the custom pathing mechanism for EasyCLI.  I've
documented (somewhat) how the pathing mechanism in EasyCLI works.  I would
venture to say that it's the most complete pathing mechanism for the CBM
platform and could be adopted as an alternative to having to set _curunit
before doing POSIX style file IO.

http://easycli.codeplex.com/wikipage?title=Pathing&referringTitle=Documentation




> --
> Payton Byrd
> <http://www.paytonbyrd.com>
> <http://it.toolbox.com/blogs/paytonbyrd>
>

----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.