Re: [Axiom-developer] Re: directory/truename transition

[Camm Maguire]

Greetings!

"Bill Page" <address@hidden> writes:

> On 03 Jul 2007 23:25:17 -0400, Camm Maguire wrote:
> > ...
> > This is all quite depressing.  It appears the clspec is quite
> > deficient in this regard.  Hence, I think the proper goal for GCL is
> > to be as close to posix and "intuition" in this regard while still
> > passing the spec.
> >
> 
> +1 for supporting posix.
> 
> > The whole goal was 1) to support pathnames with spaces, ala mingw, and
> > 2) to provide some natural means within the spec for distinguishing a
> > directory from a file.  clisp seems appropriate for this, but does not
> > allow one to overlay delete-file et. al. for directories.  This does
> > seem a good tradeoff on reflection, as any general overlay is going to
> > run afoul of all sorts of problems trying to #'open a directory and
> > #'read therefrom.  If this perspective is the right one, all the spec
> > functions but #'directory should work only on files, and GCL should
> > provide functions in 'si to do the directory manipulations outside the
> > spec.
> >
> 
> Yes.
> 
> > As they are outside the spec, is there any reason not to implement
> > these where possible with #'system?  The bourne shell is likely at
> > least as portable as GCL is.  I was worried about the following
> > directory implementation:
> >
> >         sprintf(command, "shopt -s dotglob; "
> >                          "IFS='' j=\"%s\"; for i in $j ; do ! [ -e \"$i\" ] 
> > || %c [ -d \"$i\" ] || echo \"$i\" ; done", filename, ch);
> >
> > but I think it likely that this will even work on mingw.
> >
> 
> Well, that depends on what you mean by "work". At the present time gcl
> builds on MSYS/mingw as a *native* Windows application. MSYS/mingw is
> only required to build gcl from source. Standard native windows does
> not have any of these unix-oriented #system tools. Doing what you
> suggest would result in gcl only working from within the MSYS/mingw
> shell.
> 
> Of course there is also the issue of gcc on Windows which is needed
> when compiling. In the case of installing a native Windows Axiom, the
> install program includes the bare minimum mingw gcc components in a
> separate directory along with Axiom. Installation of mingw is not a
> prerequisite.
> 

How big is the mingw-ex-gcc?  Is it unreasonable to include the full
environment in the installer?  Even macosx has bash.

Speaking of which, does anyone know how to make the mingw installer
for the next GCL release?

> Although it requires a little more knowledge of Windows internals, I
> strongly recommend that gcl on windows continue to call the windows
> API instead of relying on external support for posix/unix commands in
> a particular shell that is not native to Windows. For similar reasons
> I also would not recommend trying to utilize the Windows non-posix
> command interpreter for this purpose.
> 

I'm happy to go along with this, though I'm not sure what benefit the
user would see other than a little less disk space usage.  I can only
justify minimal time learning anything windows specific for this
purpose, but of course will eagerly accept all offers of assistance in
this regard. 

Now perhaps there is just a lower level api to which I could write
that would transparently be portable.  E.g. implementing directory via
readdir and opendir.  Re-implementing all the shell pattern matching
from scratch is certainly doable, but there should be some clear
benefit visible that would justify the work.  Its hard for me to see
at the moment.

Please see related post regarding an extra-spec posix support function
proposal. 

Take care,


> Regards,
> Bill Page.
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah