gzip.exe as symlink breaks NTEmacs's jka-compr.el
Randall R Schulz
rrschulz@cris.com
Tue Jul 16 20:12:00 GMT 2002
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/
More information about the Cygwin
mailing list