On Tue, 3 Jul 2007, Bill Page wrote: | > 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.
Note however that mingw/msys support for paths with embeeded space is very limited -- this is not a suggestion that it should not be done in GCL; rather it is a warning about what is be assumed. | 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. The Haskell distribution for windows ships with a build of gcc. This is a general problem/nuisance on windows platforms for programs that generate C codes and assumes availability of a C compiler. -- Gaby _______________________________________________ Axiom-developer mailing list Axiom-developer@nongnu.org http://lists.nongnu.org/mailman/listinfo/axiom-developer