Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com Date: Thu, 31 Aug 2000 10:51:13 -0400 (EDT) From: Mark Schoenberg 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