Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-Id: <5.1.0.14.2.20020716185624.03113ce8@pop3.cris.com> X-Sender: rrschulz AT pop3 DOT cris DOT com Date: Tue, 16 Jul 2002 19:07:43 -0700 To: Jon Cast From: Randall R Schulz Subject: Re: gzip.exe as symlink breaks NTEmacs's jka-compr.el Cc: cygwin AT cygwin DOT com In-Reply-To: <200207170150.g6H1otZ28318@d-ip-129-15-78-125.cs.ou.edu> References: <5 DOT 1 DOT 0 DOT 14 DOT 2 DOT 20020716182754 DOT 02f3df30 AT pop3 DOT cris DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Jon, I think you're right. There's a fundamental asymmetry created by following the Unix convention of symlinks as aliases (in lieu of universally applicable hard links, which are true aliases). Simply having Cygwin's /bin in your PATH makes it possible to run Cygwin ".exe" files, but not Cygwin symlinks unless it's a Cygwin program that attempts to invoke the alias. I guess the best answer for addressing this asymmetry from the standpoint of simplicity and universality is to simply copy the binary separately to each named program that binary implements. Unfortunately, some of those files are pretty big. Witness these symlink targets from /bin (repeats reflect there being more than one symlink targeting the same binary): -rwxrwxrwx 1 Administ None 3228 Jan 23 00:55 /bin/allcm* -rwxrwxrwx 1 Administ None 2105 May 6 23:35 /bin/bzdiff* -rwxrwxrwx 1 Administ None 1582 May 6 23:35 /bin/bzgrep* -rwxrwxrwx 1 Administ None 1582 May 6 23:35 /bin/bzgrep* -rwxrwxrwx 1 Administ None 1259 May 6 23:35 /bin/bzmore* -rwxrwxrwx 1 Administ None 94208 Dec 26 2001 /bin/ctags.exe* -rwxrwxrwx 1 Administ None 8192 Jun 26 10:49 /bin/db2_archive.exe* -rwxrwxrwx 1 Administ None 9728 Jun 26 10:49 /bin/db2_checkpoint.exe* -rwxrwxrwx 1 Administ None 8704 Jun 26 10:49 /bin/db2_deadlock.exe* -rwxrwxrwx 1 Administ None 9728 Jun 26 10:49 /bin/db2_dump.exe* -rwxrwxrwx 1 Administ None 13312 Jun 26 10:49 /bin/db2_load.exe* -rwxrwxrwx 1 Administ None 8192 Jun 26 10:49 /bin/db2_printlog.exe* -rwxrwxrwx 1 Administ None 7680 Jun 26 10:49 /bin/db2_recover.exe* -rwxrwxrwx 1 Administ None 15872 Jun 26 10:49 /bin/db2_stat.exe* -rwxrwxrwx 1 Administ None 84992 Jan 23 00:56 /bin/dvilj4.exe* -rwxrwxrwx 1 Administ None 84992 Jan 23 00:56 /bin/dvilj4l.exe* -rwxrwxrwx 1 Administ None 68096 Jan 5 2002 /bin/ed.exe* -rwxrwxrwx 1 Administ None 274944 Jan 23 00:56 /bin/etex.exe* -rwxrwxrwx 1 Administ None 274944 Jan 23 00:56 /bin/etex.exe* -rwxrwxrwx 1 Administ None 274944 Jan 23 00:56 /bin/etex.exe* -rwxrwxrwx 1 Administ None 274944 Jan 23 00:56 /bin/etex.exe* -rwxrwxrwx 1 Administ None 145408 May 13 22:05 /bin/flex.exe* -rwxrwxrwx 1 Administ None 169984 Jun 24 2000 /bin/gawk.exe* -rwxrwxrwx 1 Administ None 85504 Mar 20 21:16 /bin/grep.exe* -rwxrwxrwx 1 Administ None 85504 Mar 20 21:16 /bin/grep.exe* -rwxrwxrwx 1 Administ None 59392 Jul 15 08:13 /bin/gzip.exe* -rwxrwxrwx 1 Administ None 59392 Jul 15 08:13 /bin/gzip.exe* -rwxrwxrwx 1 Administ None 411136 Apr 1 2001 /bin/irc-20010101.exe* -rwxrwxrwx 1 Administ None 3306 Jan 23 00:56 /bin/kpsetool* -rwxrwxrwx 1 Administ None 3306 Jan 23 00:56 /bin/kpsetool* -rwxrwxrwx 1 Administ None 1349 May 23 19:22 /bin/libpng12-config* -rwxrwxrwx 1 Administ None 506368 Jul 5 09:00 /bin/mc.exe* -rwxrwxrwx 1 Administ None 506368 Jul 5 09:00 /bin/mc.exe* lrwxrwxrwx 1 Administ None 13 Jul 9 07:55 /bin/mcedit -> mc* lrwxrwxrwx 1 Administ None 13 Jul 9 07:55 /bin/mcedit -> mc* -rwxrwxrwx 1 Administ None 3584 Jul 5 09:00 /bin/mcmfmt.exe* -rwxrwxrwx 1 Administ None 3584 Jul 5 09:00 /bin/mcmfmt.exe* -rwxrwxrwx 1 Administ None 9728 Jul 12 21:42 /bin/mcookie.exe* -rwxrwxrwx 1 Administ None 9728 Jul 12 21:42 /bin/mcookie.exe* lrwxrwxrwx 1 Administ None 13 Jul 9 07:55 /bin/mcview -> mc* lrwxrwxrwx 1 Administ None 13 Jul 9 07:55 /bin/mcview -> mc* -rwxrwxrwx 1 Administ None 225792 Jan 23 00:56 /bin/mf.exe* -rwxrwxrwx 1 Administ None 225792 Jan 23 00:56 /bin/mf.exe* -rwxrwxrwx 1 Administ None 78848 Jan 23 00:56 /bin/mft.exe* -rwxrwxrwx 1 Administ None 78848 Jan 23 00:56 /bin/mft.exe* -rwxrwxrwx 1 Administ None 4700 Jan 23 00:47 /bin/mktexlsr* -rwxrwxrwx 1 Administ None 228352 Jan 23 00:56 /bin/mpost.exe* -rwxrwxrwx 1 Administ None 228352 Jan 23 00:56 /bin/mpost.exe* -rwxrwxrwx 1 Administ None 120832 Mar 30 21:57 /bin/ncftpbatch.exe* -rwxrwxrwx 1 Administ None 381952 Jan 23 00:56 /bin/omega.exe* -rwxrwxrwx 1 Administ None 381952 Jan 23 00:56 /bin/omega.exe* -rwxrwxrwx 1 Administ None 381952 Jan 23 00:56 /bin/omega.exe* -rwxrwxrwx 1 Administ None 381952 Jan 23 00:56 /bin/omega.exe* -rwxrwxrwx 1 Administ None 627712 Jan 23 00:56 /bin/pdfetex.exe* -rwxrwxrwx 1 Administ None 627712 Jan 23 00:56 /bin/pdfetex.exe* -rwxrwxrwx 1 Administ None 627712 Jan 23 00:56 /bin/pdfetex.exe* -rwxrwxrwx 1 Administ None 627712 Jan 23 00:56 /bin/pdfetex.exe* -rwxrwxrwx 1 Administ None 591872 Jan 23 00:56 /bin/pdftex.exe* -rwxrwxrwx 1 Administ None 591872 Jan 23 00:56 /bin/pdftex.exe* -rwxrwxrwx 1 Administ None 591872 Jan 23 00:56 /bin/pdftex.exe* -rwxrwxrwx 1 Administ None 591872 Jan 23 00:56 /bin/pdftex.exe* -rwxrwxrwx 1 Administ None 2708992 Jun 10 05:13 /bin/postgres.exe* -rwxrwxrwx 1 Administ None 3072 Jun 25 08:01 /bin/python2.2.exe* -rwxrwxrwx 1 Administ None 9728 Nov 28 2001 /bin/shutdown.exe* -rwxrwxrwx 1 Administ None 9728 Nov 28 2001 /bin/shutdown.exe* -rwxrwxrwx 1 Administ None 9728 Nov 28 2001 /bin/shutdown.exe* -rwxrwxrwx 1 Administ None 231424 Jul 4 02:31 /bin/ssh.exe* -rwxrwxrwx 1 Administ None 241664 Jan 23 00:56 /bin/tex.exe* -rwxrwxrwx 1 Administ None 241664 Jan 23 00:56 /bin/tex.exe* -rwxrwxrwx 1 Administ None 241664 Jan 23 00:56 /bin/tex.exe* I know that if one just uses the "ln" command (no "-s" option) on a FAT volume you get a copy. If Cygwin packages used hard links for program aliases (does the TAR format support hard links?) and Setup.exe was given the same smarts as the "ln" command, you'd get space-wasting copies on FAT volumes and fast, space-efficient hard links on NTFS. Randall Schulz Mountain View, CA USA At 18:50 2002-07-16, Jon Cast wrote: >Randall R Schulz wrote: > > Jon, > > > > > However, I believe that if there's a conceit being displayed here, > > it's yours. You seem to think that because a Cygwin command comes > > within the realm of all that Emacs surveys, the Cygwin tool should > > adapt to service Emacs. > >Sorry if I gave that impression. Certainly I don't think Cygwin tools >should always adapt however far is necessary to work with Emacs. > > > If Emacs does not work well in the environment in which it finds > > itself, is it the fault of that environment? I think not. > >I respectfully disagree that Emacs is ``not work[ing] will in the >environment in which it finds itself''. The ``environment'' here is >Windows. gzip, at the time the complaint was made, did not work well >in that environment. Emacs does not work well in that environment. >M$ Word does not work well in that environment. Nothing does --- >Windows is fundamentally broken. There is no completely correct >behavior in many cases, such as this one. However, there is less >broken behavior. Sometimes there's an easy fix to make something work >better. Sometimes there's a hard fix to make something work better. >If they're equally correct (as in this case), I think we should always >go with the easy fix, rather than saying ``Cygwin programs are always >right, Emacs is always wrong, fix Emacs'' or ``Emacs is always right, >Cygwin programs are always wrong, fix Cygwin''. > > > As has often been said here (by the principals, not me): Cygwin is > > not Unix. > >Because Cygwin cannot fix the fundamental brokenness of Windows. >Neither can Emacs. But both can be made better. > >Jon Cast -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/