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.