On Fri, May 30, 2003 at 06:56:08AM -0700, Greg Fenton wrote:
> Before I crawl into code and start hacking, I thought I'd post a
> problem I've run into and see if it is currently being addressed.
> 
> I have build swish-e from CVS on Windows using Cygwin.  The good news
> is that it Just Works:
> 
> 1. ./configure
> 2. make
> 
> (I'm sure "make install" would work too, but I haven't needed to yet).

make install installs a lot more parts of swish-e into places one would 
expect...[1]

> The problem I run into is when I try to spider a site.  My swish.conf
> contains:
> 
>    IndexDir ../prog-bin/spider.pl
> 
> When I run swish-e under Cygwin, I get:
> 
>    Indexing Data Source: "External-Program"
>    Indexing "./spider.pl"
>    .spider.pl: not found
> 
> The problem seems, from my brief browse of the code, to be in extprog.c
> line 161:
> 
>   /* -------------------------------------- */
>   #ifdef _WIN32
> 
>       make_windows_path( cmd );
> 
>   #endif
>   /* -------------------------------------- */
> 
> I'm pretty sure that what is happening is that "./spider.pl" is getting
> converted to ".\spider.pl", which interpreted by the Cygwin environment
> (a true BASH shell) becomes ".spider.pl" [\s is simply an "s"].
> 
> I'm happy to provide a patch, but before I do I want to find out if:
>  (a) I'm on the right path,
>  (b) is anyone actively working on this particular code and
>  (c) does anyone have a solution other than adding more to the #ifdef

We try and use forward slashes everywhere inside Swish-e, and for 
commands that use the shell we call make_windows_path() to flip the 
slash into a backslash.

The PATH_SEPARATOR variable char is not passed in as a define on 
compile, so that could be used instead.  That was just added to the 
build system.

I haven't looked but maybe the make_windows_path() could be renamed and 
then call it in all cases and replace any "/" with PATH_SEPARATOR.

I'm sure there's a better way to handle paths on multiplatform builds.

A quick

   fgrep "'/'" *.c
   fgrep '"/"' *.c 

shows potential problems with paths.


-- 
Bill Moseley
moseley@hank.org