Subject: Re: Backing out of Cygwin-1.1.4
From: Chris Faylor <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Thu, 31 Aug 2000 12:12:31 -0400

On Thu, Aug 31, 2000 at 10:51:13AM -0400, Mark Schoenberg wrote:
>Date: Thu, 31 Aug 2000 10:51:13 -0400 (EDT)
>From: Mark Schoenberg <[email-masked]>
>To: [email-masked]
>Subject: Backing out of Cygwin-1.1.4
>
>On  Wed Aug 30 23:29:15 2000, Chris Faylor wrote,
>>On Wed, Aug 30, 2000 at 11:12:11PM -0400, Mark Schoenberg wrote:
>>>
>>>     Does anyone know of a way to back out of cygwin-1.1.4 and return to
>>>cygwin-1.1.2?
>>
>>Can I ask why you'd want to do this?
>>
>>cgf
>>
>
>Ok, here goes:
>"Ten" reasons why I think 1.1.4 is going in the wrong direction.

I've read everything below, and I'm not clear on what direction you think
is evidenced from 1.1.2 to 1.1.4.  It sounds like you may have hit upon
a bug or two or an unexpected side-effect.

This is no reason to assume that everything is going to hell, though.

>     As good as Cygwin is, it will not be anytime soon that it occupies the
>majority of desktops.  My own goal therefore, is to write programs that will
>operate both in the Cygwin environment and without it.  This is extremely
>difficult when the two environments see different filesystems.  It hardly makes
>sense (at least to me), to have Cygwin, which is meant for Windows, to not see
>the same portion of the disk as Windows does.  To port 1.1.4, I had to issue
>half a dozen mount commands.

Why did you have to issue "half a dozen mount commands"?  Cygwin should be
able to properly deal with paths like c:\winnt\system32 if that's what you
want to use.  How is this different from 1.1.2?

>     Significant Unix-like windows programs that preceded Cygwin (emacs and
>some operations within tcsh) think that dir/file is really C:dir/file.  While
>this doesn't make sense in a Unix environment, it is the way these
>Windows-ported programs work at present.

Actually, I would assume that any UNIX or Windows based software would assume
that dir/file referred to dir/file in the current directory.  That should be
the case for cygwin unless dir is a mount point.  This should not have changed
between 1.1.2 and 1.1.4.

>     Two commands within Cygwin that have always difficult to run in both the
>Cygwin and non-Cygwin Windows environment are mkdir() and system().  The former
>is a pain, but at least I got used to programming in an ifdef to put in the
>correct number of arguments when -mno-cygwin was used.

Also, not a 1.1.2 vs. 1.1.4 problem but you do understand that we're emulating
UNIX, right?

>System was a greater pain, but in 1.1.0-1.2.2, all you had to remember
>was that Cygwin-compiled programs required "/dir/com" and -mno-cygwin
>compiled programs required "\\dir\\com".  In 1.1.4, I have been unable
>to figure out what the paradigm is that determines what shell the
>system command runs in.

I don't understand this.  AFAIK, the system command has not changed.  It
should always run /bin/sh, just as before.  If you can provide an
example of something that behaves differently between 1.1.4 and 1.1.2
I'll be happy to investigate it.

>I have gotten different behavior when a cygwin-compiled program which
>uses system() is invoked from a bash prompt, and when it is invoked
>using the system command in a no-cygwin compiled program.

Maybe this is command line quoting?  I tried to make 1.1.4 command-line
quoting more Windows-like but apparently I wasn't successful since I've
seen a couple of bug reports.

>Not having thought about this too deeply, it seems that many of the
>above problems (except the last one) could be solved by installing
>Cygwin in /Cygwin or wherever, and then mounting C:\ on /,
>C:\Cygwin\bin on /usr/bin, and C:\Cygwin\lib on /lib.  We would then
>just have to symbolically link /usr/bin to /bin until the Unix/Linux
>community agrees on where to put executables.  We might also have to
>find a home for cygwin.bat, cygwin.ico, and maybe home/, but that
>shouldn't be too difficult.

Again, these are not 1.1.2 vs. 1.1.4 issues, AFAICT.  However, if you
want to do this on your system, you really should go ahead and do this.
If it bothers you that running 'setup.exe' may cause problems with
this layout, I'd suggest writing a fairly simple shell script to
put things to your liking after you've run setup.exe.

Or, you can even grab the setup sources and make whatever changes you
think are appropriate.  DJ is a reasonable person and he may just
agree with you if you submit changes.

cgf

--
Want to unsubscribe from this list?
Send a message to [email-masked]