Mail Archives: cygwin/2002/07/16/22:44:08
Randall R Schulz <rrschulz AT cris DOT com> wrote:
> 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).
I *think* I follow. Of course, on Unix, symlinks /are/ aliases, so
the problem doesn't arise.
> 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.
True.
> 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*
Actually, there is an (amortized) smaller way than copying the files.
If the following program is compiled under Cygwin:
#include <unistd.h>
int
main (int argc, char **argv)
{
execv ("/bin/gzip", argv);
}
It should do the same job as a symlink to /bin/gzip under both Cygwin
and Windows. It's slightly less time-and-process efficient, but if
space is a concern it's probably better. I don't have easy access to
a Cygwin box just at the moment, but on GNU/Linux (Redhat 7.3, to be
precise) it's < 3k stripped. A lot more than a symlink (although I
think Windows' filesystem granularity is higher than that anyway), but
less than just about any of the programs you list.
> 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?)
Yes.
> 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.
This is a good idea if space on FAT volumes is not a concern.
> Randall Schulz
> Mountain View, CA USA
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/
- Raw text -