You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2001/03/02 17:36:50 UTC

Fw: Win32/Apache 1.3.17-19 problems

Snipping this down to the core issues, Win32 folks may want to comment here...

From: "William A. Rowe, Jr." <wr...@lnd.spam.not.welcome.net>
Newsgroups: comp.infosystems.www.servers.ms-windows
Sent: Friday, March 02, 2001 8:13 AM
Subject: Re: Apache 1.3.19 problems
>
> Last observation, and this is _critical_.  Nearly _every_ unix based script
> 
>  1. requires or prefers slashes
>  2. may not appreciate d:/path syntax (looks like a network machine name)
>  3. may throw up on names with spaces
> 
> I just noticed you are heavy on cygwin or other faux unix tools.  Here's the problem,
> win32 generally just doesn't live with these.  It does the following:
> 
>  if you execute a shebang program, and don't put "%1"  (include the quotes) following
>  the program, it executes with the long name.  If you put nothing, or include simply %1
>  with no quotes, is uses the short name (so spaces can't confuse the app.)  And the
>  program is executed with backslashes, never slashes, since they sometimes confuse win32.
> 
> A similar thing happens using the registry and ScriptInterpreterSource.
> 
> What about the following?  Pure unix shebang?  You get slashes/long names.  %1?  You get
> a short name.  "%1"?  A long name, both %1 flavors providing backslashes.  Or allow a $1
> for the unix behavior.
> 
> I don't have a full and instant answer, but the missing slashes in the errlog message
> sure suggest they were interpreted as quoting.
> 
> The Win32 port is, and will continue to be, conformed to the WinNT model.  Some things
> may not work correctly on Win9x, and support for unixish apps is not perfect either.
> I'd be happy to look at this so users of 'unconverted' apps can run, but there are no
> guarentees here.  Any which way, a Win32 native app has far more problems with slashed
> file names (try dir c:/winnt for proof.)  So support for the native shell wins over
> trying to be everything to everyone.
> 
> If we show this to be the problem, let's try to work out a semantic that is generally
> easy-to-follow.