This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gzip.exe as symlink breaks NTEmacs's jka-compr.el

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 <rrschulz@cris.com> wrote:
> Jon,

<snip>

> 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/
Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]