Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-owner AT sources DOT redhat DOT com
Date: Thu, 31 Aug 2000 10:51:13 -0400 (EDT)
From: Mark Schoenberg <mark AT lpb DOT niams DOT nih DOT gov>
Message-Id: <200008311451.e7VEpD620652@lpb.niams.nih.gov>
To: cygwin AT sourceware DOT cygnus DOT com
Subject: Backing out of Cygwin-1.1.4
Mime-Version: 1.0
Content-Type: text/plain; charset=X-roman8
Content-Transfer-Encoding: 7bit

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.

     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.

     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.

     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.  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 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.

     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.

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com