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

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

[Matt Swift]

Cygwin package gzip 1.3.3 made the change (from 1.3.2) that /bin/gzip
is a symlink to /bin/gunzip instead of the other way around.  This
change breaks NTEmacs 20.7 and 21.1 on Win2k.  To reproduce, try
evaluating

    (call-process "gzip" nil '(t t) nil "--version")

and Emacs will either freeze until you issue multiple C-g's or Win2k
will popup an "illegal instruction" error dialog.

The common and useful package jka-compr.el (when loaded) by default
invokes `call-process' on "gzip" to uncompress as well as compress
files, rather than "gunzip".

You get similar errors if you invoke `call-process' on any of the
symlinks in /cygwin/bin (e.g., awk.exe -> gawk.exe).

Initial workaround:

        cp /bin/gunzip.exe /usr/local/bin/gzip.exe

(assuming /usr/local/bin is in the PATH (NTEmacs's `exec-path' before
/bin).  Could also change a jka-compr variable to use "gunzip" instead
of "gzip", but that seems less robust (other Emacs-Lisp code probably
calls "gzip" too).

I wasted more than an hour tracking down this bug (not a bug in Cygwin
per se, really, but a change that caused a bug with software very
commonly used with Cygwin).  I didn't look hard, but I found no
comment in the gzip 1.3.3 sources indicating why the change was made
in the symlinks.  Please don't change things that are not broken!



--
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/

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

[Robert Collins]

Sounds to me like NTEmacs is broken, and should be able to interpret
symlinks if it wants to interoperate with cygwin.

Heck, it could even link with cygwin and get that for free!

Rob

----- Original Message -----
From: "Matt Swift" <swift@alum.mit.edu>
To: <cygwin@cygwin.com>
Sent: Monday, July 15, 2002 3:36 PM
Subject: gzip.exe as symlink breaks NTEmacs's jka-compr.el


>
> Cygwin package gzip 1.3.3 made the change (from 1.3.2) that /bin/gzip
> is a symlink to /bin/gunzip instead of the other way around.  This
> change breaks NTEmacs 20.7 and 21.1 on Win2k.  To reproduce, try
> evaluating
>
>     (call-process "gzip" nil '(t t) nil "--version")
>
> and Emacs will either freeze until you issue multiple C-g's or Win2k
> will popup an "illegal instruction" error dialog.
>
> The common and useful package jka-compr.el (when loaded) by default
> invokes `call-process' on "gzip" to uncompress as well as compress
> files, rather than "gunzip".
>
> You get similar errors if you invoke `call-process' on any of the
> symlinks in /cygwin/bin (e.g., awk.exe -> gawk.exe).
>
> Initial workaround:
>
>         cp /bin/gunzip.exe /usr/local/bin/gzip.exe
>
> (assuming /usr/local/bin is in the PATH (NTEmacs's `exec-path' before
> /bin).  Could also change a jka-compr variable to use "gunzip" instead
> of "gzip", but that seems less robust (other Emacs-Lisp code probably
> calls "gzip" too).
>
> I wasted more than an hour tracking down this bug (not a bug in Cygwin
> per se, really, but a change that caused a bug with software very
> commonly used with Cygwin).  I didn't look hard, but I found no
> comment in the gzip 1.3.3 sources indicating why the change was made
> in the symlinks.  Please don't change things that are not broken!
>
>
>
> --
> 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/
>
>


--
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/

Re: gzip.exe as symlink...

[Max Bowsher]

Never mind emacs - surely it makes more sense for gzip to be the real file, and
gunzip to be the symlink? Isn't that what most people would automatically
assume?


Max.


--
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/

Re: gzip.exe as symlink...

[Robert Collins]

----- Original Message -----
From: "Max Bowsher" <maxb@ukf.net>
To: <cygwin@cygwin.com>
Sent: Monday, July 15, 2002 7:26 PM
Subject: Re: gzip.exe as symlink...


> Never mind emacs - surely it makes more sense for gzip to be the real
file, and
> gunzip to be the symlink? Isn't that what most people would automatically
> assume?

I'd never thought about it - why would anyone care which is the real file?

Rob


--
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/

Re: gzip.exe as symlink...

[Jon Cast]

Robert Collins <robert.collins@syncretize.net> wrote:
<snip>
> I'd never thought about it - why would anyone care which is the real
> file?

If they have to use any program not linked with cygwin1.dll.

> Rob

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/

Re: gzip.exe as symlink...

[Nicholas Wourms]

--- Jon Cast <jcast@ou.edu> wrote:
> Robert Collins <robert.collins@syncretize.net> wrote:
> <snip>
> > I'd never thought about it - why would anyone care which is the real
> > file?
> 
> If they have to use any program not linked with cygwin1.dll.
> 
> > Rob
> 
You should be using vi & bash, then you wouldn't have all these "issues".

'Nuff said

Cheers,
Nicholas

P.S. - I couldn't resist :-P

__________________________________________________
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com

--
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/

RE: gzip.exe as symlink...

[Robert Collins]

> -----Original Message-----
> From: cygwin-owner@cygwin.com 
> [mailto:cygwin-owner@cygwin.com] On Behalf Of Jon Cast
> Sent: Tuesday, 16 July 2002 4:22 AM
> To: cygwin@cygwin.com
> Subject: Re: gzip.exe as symlink...
> 
> 
> Robert Collins <robert.collins@syncretize.net> wrote:
> <snip>
> > I'd never thought about it - why would anyone care which is the real
> > file?
> 
> If they have to use any program not linked with cygwin1.dll.

Then they presumably have the luxry of telling it what .exe to run. 

Rob


--
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/

Re: gzip.exe as symlink...

[Max Bowsher]

Robert Collins wrote:
> ----- Original Message -----
> From: "Max Bowsher" maxb@ukf.net
>
>> Never mind emacs - surely it makes more sense for gzip to be the
>> real file, and gunzip to be the symlink? Isn't that what most people
>> would automatically assume?
>
> I'd never thought about it - why would anyone care which is the real
> file?

Ah - you want a reason :-). Dunno, it just felt better.

But David Robinow came up with a good one - if gzip.exe is a symlink, then there
is no way to invoke gzip in compression mode from a non cygwin program. OK, its
not that important, but since the fix is trivial...

Max.


--
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/

Re: gzip.exe as symlink...

[Dario Alcocer]

On Mon, Jul 15, 2002 at 10:26:53AM +0100, Max Bowsher wrote:
> Never mind emacs - surely it makes more sense for gzip to be the real file, and
> gunzip to be the symlink? Isn't that what most people would automatically
> assume?

Yes.  I'd say that this qualifies as packaging bug.

OTOH, I agree with Rob that the NTemacs package in question is
probably broken also.

-- 
Dario Alcocer -- Sr. Software Developer, Helix Digital Inc.
alcocer@helixdigital.com -- http://www.helixdigital.com

--
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/

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

[Jon Cast]

Robert Collins <robert.collins@syncretize.net> wrote:
> Sounds to me like NTEmacs is broken, and should be able to interpret
> symlinks if it wants to interoperate with cygwin.

NTEmacs is a native Windows program, so I don't think inter-operating
with Cygwin specifically is a terribly high priority for NTEmacs.
People who want an Emacs that works with Cygwin can contribute to a
Cygwin port :)

> Heck, it could even link with cygwin and get that for free!

As commonly heard on this list, patches gratefully accepted :)

> Rob

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/

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

[Gerrit P. Haase]

Hallo Robert,

Am Montag, 15. Juli 2002 um 07:39 schriebst du:

> Sounds to me like NTEmacs is broken, and should be able to interpret
> symlinks if it wants to interoperate with cygwin.

No, it is a bug in Windows.  You cannot run symlinks (of course a Windows
style symlink) out of a cmd shell.  I got problems once with awk.exe
which is a symlink to gawk.exe.  He reports this 'bug' in Windows2K
really clear and you guys flamed him for that?

Why not repackage at least gzip and make the two files in question at
least hardlinks instead of symlinks?

IIRC I stumbled over this Windows bug on W2K when building a native
Windows version of openssl which needs awk.  I guess it is no problem
on NT4 and maybe W2K is the only platform where it doesn't work .


> Heck, it could even link with cygwin and get that for free!

> Rob

> ----- Original Message -----
> From: "Matt Swift" <swift@alum.mit.edu>
> To: <cygwin@cygwin.com>
> Sent: Monday, July 15, 2002 3:36 PM
> Subject: gzip.exe as symlink breaks NTEmacs's jka-compr.el


>>
>> Cygwin package gzip 1.3.3 made the change (from 1.3.2) that /bin/gzip
>> is a symlink to /bin/gunzip instead of the other way around.  This
>> change breaks NTEmacs 20.7 and 21.1 on Win2k.  To reproduce, try
>> evaluating
>>
>>     (call-process "gzip" nil '(t t) nil "--version")
>>
>> and Emacs will either freeze until you issue multiple C-g's or Win2k
>> will popup an "illegal instruction" error dialog.
>>
>> The common and useful package jka-compr.el (when loaded) by default
>> invokes `call-process' on "gzip" to uncompress as well as compress
>> files, rather than "gunzip".
>>
>> You get similar errors if you invoke `call-process' on any of the
>> symlinks in /cygwin/bin (e.g., awk.exe -> gawk.exe).
>>
>> Initial workaround:
>>
>>         cp /bin/gunzip.exe /usr/local/bin/gzip.exe
>>
>> (assuming /usr/local/bin is in the PATH (NTEmacs's `exec-path' before
>> /bin).  Could also change a jka-compr variable to use "gunzip" instead
>> of "gzip", but that seems less robust (other Emacs-Lisp code probably
>> calls "gzip" too).
>>
>> I wasted more than an hour tracking down this bug (not a bug in Cygwin
>> per se, really, but a change that caused a bug with software very
>> commonly used with Cygwin).  I didn't look hard, but I found no
>> comment in the gzip 1.3.3 sources indicating why the change was made
>> in the symlinks.  Please don't change things that are not broken!

-- 
=^..^=


--
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/

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

[Matt Swift]

>> "R" == Robert wrote:

    R> Sounds to me like NTEmacs is broken, and should be able to interpret
    R> symlinks if it wants to interoperate with cygwin.

    R> Heck, it could even link with cygwin and get that for free!

    R> Rob

Porting Emacs to Cygwin is no small job.  Meanwhile, many need to use
NTEmacs with Cygwin with as much efficiency as is available.

I see that the Cygwin sources have been changed back to gunzip being a
symlink.

What about a hard link?  It seems to be the best of both worlds.  No
more disk space and no problems with symlnks.  I've tried it and it
works well so far.

--
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/

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

[David Starks-Browning]

On Tuesday 16 Jul 02, Matt Swift writes:
> Porting Emacs to Cygwin is no small job.  Meanwhile, many need to use
> NTEmacs with Cygwin with as much efficiency as is available.
> 
> I see that the Cygwin sources have been changed back to gunzip being a
> symlink.
> 
> What about a hard link?  It seems to be the best of both worlds.  No
> more disk space and no problems with symlnks.  I've tried it and it
> works well so far.

I do not believe that is possible on Win9x.

IMO, a separate copy of the file is the friendliest choice for Windows
apps like GNU Emacs.  But it's up to the gzip maintainer.  If the gzip
maintainer chooses not to do this, GNU Emacs users will have to work
around it somehow.  Full stop.

Regards,
David
(NTEmacs user)


--
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/

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

[Nicholas Wourms]

--- David Starks-Browning <starksb@ebi.ac.uk> wrote:
> On Tuesday 16 Jul 02, Matt Swift writes:
> > Porting Emacs to Cygwin is no small job.  Meanwhile, many need to use
> > NTEmacs with Cygwin with as much efficiency as is available.
> > 
> > I see that the Cygwin sources have been changed back to gunzip being a
> > symlink.
> > 
> > What about a hard link?  It seems to be the best of both worlds.  No
> > more disk space and no problems with symlnks.  I've tried it and it
> > works well so far.
> 
> I do not believe that is possible on Win9x.
> 
> IMO, a separate copy of the file is the friendliest choice for Windows
> apps like GNU Emacs.  But it's up to the gzip maintainer.  If the gzip
> maintainer chooses not to do this, GNU Emacs users will have to work
> around it somehow.  Full stop.
> 

You are right, WinME/9X doesn't support "hard links", nor does NT with
FAT/FAT32 formatted drives.

Geeze, try this:
rm -f /bin/gzip.exe; cp -f /bin/gunzip.exe /bin/gzip.exe

Now was that hard?  No.

Cheers,
Nicholas

__________________________________________________
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com

--
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/

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

[Randall R Schulz]

Matt,

Hard links don't exist on FAT file system volumes.

I may have missed something (please forgive me for not re-reading the 
thread), but why is a non-Cygwin program (NTEmacs) relying on a Cygwin 
tool? Surely it can be configured to use the correct one, right? If NTEmacs 
doesn't include it's own gzip / gunzip, then editing a compressed file 
wouldn't even be possible without Cygwin installed, so it seems incumbent 
upon NTEmacs to deal with the challenges of doing so in their most generic 
form. There is, for example, the "readlink" command that resolves a Cygwin 
symbolic link.

Randall Schulz
Mountain View, CA USA


At 08:30 2002-07-16, Matt Swift wrote:
>...
>
>I see that the Cygwin sources have been changed back to gunzip being a
>symlink.
>
>What about a hard link?  It seems to be the best of both worlds.  No
>more disk space and no problems with symlnks.  I've tried it and it
>works well so far.


--
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/

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

[Jon Cast]

Randall R Schulz <rrschulz@cris.com> wrote:
<snip>
> I may have missed something (please forgive me for not re-reading
> the thread), but why is a non-Cygwin program (NTEmacs) relying on a
> Cygwin tool?

Because Emacs is a Unix program.  It's been evolved to deliver very
nearly to full power of the Unix environment, and as such uses /many/
Unix tools.  Many of those tools are not easily available on Windows,
but if Emacs finds a copy of them, it'll use them anyway.  This is a
feature, not a bug.

> Surely it can be configured to use the correct one, right?

If there's a Windows gzip installed, you can customize Emacs to use
it.  But why install two gzips?

> If NTEmacs doesn't include it's own gzip / gunzip, then editing a
> compressed file wouldn't even be possible without Cygwin installed,

s/Cygwin/gzip/.  Of course you can't edit

> so it seems incumbent upon NTEmacs to deal with the challenges of
> doing so in their most generic form.

Why does Emacs have to work around this conceit that all the world
should be a Cygwin program, when /making gzip work from Emacs/ is so
much easier?  Consider: Cygwin is a Unix emulation environment, right?
So if every program was a Cygwin program, every program would be a
Unix program, and we could all use Unix.  Cygwin exists because some
people have to use Windows programs.  Ergo, Cygwin cannot pretend
Windows programs do not exist.

> There is, for example, the "readlink" command that resolves a Cygwin
> symbolic link.

> 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/

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

[Randall R Schulz]

Jon,

I'm impressed by Emacs and I think Lisp is a fantastic programming 
language--one which I've had the pleasure to use. And I wish I knew how to 
use Emacs, but alas, I'm a humble Vi user.

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. If Emacs does not work well in the environment in which it finds 
itself, is it the fault of that environment? I think not.

As has often been said here (by the principals, not me): Cygwin is not Unix.

Randall Schulz
Mountain View, CA USA


At 18:18 2002-07-16, you wrote:
>Randall R Schulz <rrschulz@cris.com> wrote:
><snip>
> > I may have missed something (please forgive me for not re-reading
> > the thread), but why is a non-Cygwin program (NTEmacs) relying on a
> > Cygwin tool?
>
>Because Emacs is a Unix program.  It's been evolved to deliver very
>nearly to full power of the Unix environment, and as such uses /many/
>Unix tools.  Many of those tools are not easily available on Windows,
>but if Emacs finds a copy of them, it'll use them anyway.  This is a
>feature, not a bug.
>
> > Surely it can be configured to use the correct one, right?
>
>If there's a Windows gzip installed, you can customize Emacs to use
>it.  But why install two gzips?
>
> > If NTEmacs doesn't include it's own gzip / gunzip, then editing a
> > compressed file wouldn't even be possible without Cygwin installed,
>
>s/Cygwin/gzip/.  Of course you can't edit
>
> > so it seems incumbent upon NTEmacs to deal with the challenges of
> > doing so in their most generic form.
>
>Why does Emacs have to work around this conceit that all the world
>should be a Cygwin program, when /making gzip work from Emacs/ is so
>much easier?  Consider: Cygwin is a Unix emulation environment, right?
>So if every program was a Cygwin program, every program would be a
>Unix program, and we could all use Unix.  Cygwin exists because some
>people have to use Windows programs.  Ergo, Cygwin cannot pretend
>Windows programs do not exist.
>
> > There is, for example, the "readlink" command that resolves a Cygwin
> > symbolic link.
>
> > 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/

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

[Jon Cast]

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/

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

[Randall R Schulz]

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/

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

[Robert Collins]

----- Original Message -----
From: "Randall R Schulz" <rrschulz@cris.com>
To: "Jon Cast" <jcast@ou.edu>

> 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.

It's not the ln smarts that are needed, its the cygwin1.dll hard link
smarts. I'd happily accept a patch to the cygfile:// handler in setup to
perform hard links rather thank copies. Of course, the package maintainers
will suddenly all need to build on NTFS as well, and with hardlinks to boot,
before anything changes.

Rob


--
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/

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

[Randall R Schulz]

Rob,

At 19:33 2002-07-16, you wrote:

>----- Original Message -----
>From: "Randall R Schulz" <rrschulz@cris.com>
>To: "Jon Cast" <jcast@ou.edu>
>
> > 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.
>
>It's not the ln smarts that are needed, its the cygwin1.dll hard link
>smarts. I'd happily accept a patch to the cygfile:// handler in setup to
>perform hard links rather thank copies. Of course, the package maintainers
>will suddenly all need to build on NTFS as well, and with hardlinks to boot,
>before anything changes.

It occurred to me that Cygwin1.dll might be making the copy on FAT file 
systems, but that didn't seem to make much sense, since the "hard link 
fails on FAT" case seems awfully close to the "cross-dev link fails" case 
that a conventional Unix "ln" already has to deal with.

"Real Users Use NTFS" (sm)


>Rob


Randall Schulz
Mountain View, CA USA


--
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/

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

[Robert Collins]

----- Original Message -----
From: "Randall R Schulz" <rrschulz@cris.com>
To: "Robert Collins" <robert.collins@syncretize.net>; <cygwin@cygwin.com>

> >It's not the ln smarts that are needed, its the cygwin1.dll hard link
> >smarts. I'd happily accept a patch to the cygfile:// handler in setup to
> >perform hard links rather thank copies. Of course, the package
maintainers
> >will suddenly all need to build on NTFS as well, and with hardlinks to
boot,
> >before anything changes.
>
> It occurred to me that Cygwin1.dll might be making the copy on FAT file
> systems, but that didn't seem to make much sense, since the "hard link
> fails on FAT" case seems awfully close to the "cross-dev link fails" case
> that a conventional Unix "ln" already has to deal with.

Huh? Cygwin1.dll doesn't make a copy on FAT - it fails as you have just
noted.. Setup.exe's cygfile:// handler makes copies.

Rob


--
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/

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

[Randall R Schulz]

At 20:12 2002-07-16, Robert Collins wrote:

>----- Original Message -----
>From: "Randall R Schulz" <rrschulz@cris.com>
>To: "Robert Collins" <robert.collins@syncretize.net>; <cygwin@cygwin.com>
>
> > >It's not the ln smarts that are needed, its the cygwin1.dll hard link
> > >smarts. I'd happily accept a patch to the cygfile:// handler in setup to
> > >perform hard links rather thank copies. Of course, the package maintainers
> > >will suddenly all need to build on NTFS as well, and with hardlinks to 
> boot,
> > >before anything changes.
> >
> > It occurred to me that Cygwin1.dll might be making the copy on FAT file
> > systems, but that didn't seem to make much sense, since the "hard link
> > fails on FAT" case seems awfully close to the "cross-dev link fails" case
> > that a conventional Unix "ln" already has to deal with.
>
>Huh? Cygwin1.dll doesn't make a copy on FAT - it fails as you have just
>noted.. Setup.exe's cygfile:// handler makes copies.
>
>Rob


Rob,

That's what I thought. But when you wrote:

>>>It's not the ln smarts that are needed, its the cygwin1.dll hard link 
>>>smarts.

I thought you were saying that the special case for copying when a hard 
link is requested on a FAT volume was handled in Cygwin1.dll, not in "ln" 
as I'd assumed.

Randall


--
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/

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

[Christopher Faylor]

>> It occurred to me that Cygwin1.dll might be making the copy on FAT file
>> systems, but that didn't seem to make much sense, since the "hard link
>> fails on FAT" case seems awfully close to the "cross-dev link fails" case
>> that a conventional Unix "ln" already has to deal with.
>
>Huh? Cygwin1.dll doesn't make a copy on FAT - it fails as you have just
>noted.. Setup.exe's cygfile:// handler makes copies.

Actually, the Cygwin link() function does make a copy on a FAT partition:

extern "C" int
_link (const char *a, const char *b)
{
.
.
.
docopy:
  /* do this with a copy */
  if (CopyFileA (real_a, real_b, 1))
    res = 0;
  else
    __seterrno ();
.
.
.

cgf

--
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/

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

[Robert Collins]

I really gotta stop reading between the lines, and get the cygwin source on
this PC. I thought Randall had tried ln on a FAT partition and had it fail.

Ah well.

Rob

----- Original Message -----
From: "Christopher Faylor" <cgf@redhat.com>
To: <cygwin@cygwin.com>
Sent: Wednesday, July 17, 2002 1:36 PM
Subject: Re: gzip.exe as symlink breaks NTEmacs's jka-compr.el


> >> It occurred to me that Cygwin1.dll might be making the copy on FAT file
> >> systems, but that didn't seem to make much sense, since the "hard link
> >> fails on FAT" case seems awfully close to the "cross-dev link fails"
case
> >> that a conventional Unix "ln" already has to deal with.
> >
> >Huh? Cygwin1.dll doesn't make a copy on FAT - it fails as you have just
> >noted.. Setup.exe's cygfile:// handler makes copies.
>
> Actually, the Cygwin link() function does make a copy on a FAT partition:
>
> extern "C" int
> _link (const char *a, const char *b)
> {
> .
> .
> .
> docopy:
>   /* do this with a copy */
>   if (CopyFileA (real_a, real_b, 1))
>     res = 0;
>   else
>     __seterrno ();
> .
> .
> .
>
> cgf
>
> --
> 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/
>
>


--
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/

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

[Jon Cast]

Randall R Schulz <rrschulz@cris.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/

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

[Randall R Schulz]

Jon,

At 19:44 2002-07-16, Jon Cast wrote:
>Randall R Schulz <rrschulz@cris.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.

No. Symlinks are indirections or pointers. The symlink is a distinct kind 
of file system entity and is always distinguishable from the original. With 
hard links each one is completely co-equal with the others and there's no 
such thing as the "real" file vs. the link. The latter is what I mean by 
"alias." This distinction between symlinks and hard links is equally 
applicable to Unix as it is to Cygwin, even though Cygwin symlinks are 
(nowadays) built upon Windows shortcuts.

The reason the problem doesn't occur on Linux, Unix or AIX (etc.) is that 
there is no environment or context in which an exec of a symlink fails 
(assuming, that is, that the symlink's target exists and is really 
executable). This is not true under Windows, where Windows itself will not 
follow a shortcut when carrying out it's equivalent of the "exec" system call.


> > 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):
>
> >... [ long list of /bin symlink targets deleted ] ...
>
>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.

That is a viable alternative, and it is compact and universal, but it would 
make Cygwin building or packaging even more of a horse of a different color 
than it it already is.

There's a directly analogous shell script that does essentially the same 
thing, too:

-==--==--==--==--==-
#!/bin/sh

exec /bin/gzip "$@"
-==--==--==--==--==-


> > 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.

Well, we used to regularly see complaints on the list about excessive disk 
consumption when the default install was all packages. Now that it's not, 
those complaints have been replaced with complaints of packages or programs 
being missing (when in fact the "missing" packages or programs simply were 
not installed).


>Jon Cast


Randall Schulz


--
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/

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

[Jon Cast]

Randall R Schulz <rrschulz@cris.com> wrote:
> Jon,
<snip>
> >I *think* I follow.  Of course, on Unix, symlinks /are/ aliases, so
> >the problem doesn't arise.

> No. Symlinks are indirections or pointers. The symlink is a distinct
> kind of file system entity and is always distinguishable from the
> original. With hard links each one is completely co-equal with the
> others and there's no such thing as the "real" file vs. the
> link. The latter is what I mean by "alias." This distinction between
> symlinks and hard links is equally applicable to Unix as it is to
> Cygwin, even though Cygwin symlinks are (nowadays) built upon
> Windows shortcuts.

This seems to be an issue of semantics: what does ``alias'' mean (see
below).

> The reason the problem doesn't occur on Linux, Unix or AIX (etc.) is
> that there is no environment or context in which an exec of a
> symlink fails (assuming, that is, that the symlink's target exists
> and is really executable). This is not true under Windows, where
> Windows itself will not follow a shortcut when carrying out it's
> equivalent of the "exec" system call.

Right.  On Unix, all of the system calls that succeed on a regular
(hard-linked) file succeed on a symlink and de-reference it.  So,
programs that aren't looking for symlinks won't notice them.  Not
technically an alias, but close enough.  Of course, on Windows major
system calls (CreateFile, CreateProcess, etc.) don't de-reference
Cygwin symlinks.  So, they're as good pseudo-aliases on Cygwin as on
Unix, but not on Windows.

<snip>
> >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.

> That is a viable alternative, and it is compact and universal, but
> it would make Cygwin building or packaging even more of a horse of a
> different color than it it already is.

Right.  I think you could argue supporting CreateProcess is the same
sort of job as supporting text mounts: tedious but worth-while.

> There's a directly analogous shell script that does essentially the
> same thing, too:

> -==--==--==--==--==-
> #!/bin/sh
>
> exec /bin/gzip "$@"
> -==--==--==--==--==-

It's not ``essentially'' the same thing.  First, it's incorrect, even
on Cygwin.  The reason for symlinking gzip (at least) is so that gzip
will check argv[0], find out it's "gunzip", and de-compress by
default.  So any symlink replacement needs to pass "gunzip" or some
such as argv[0].  The correct way to do this in shell is:

#! /bin/sh

exec -a "$0" /bin/gzip "$@"

However, it won't solve the problem at hand, which is supporting
CreateProcess: I don't think CreateProcess understand #!s :)

> > > 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.

> Well, we used to regularly see complaints on the list about
> excessive disk consumption when the default install was all
> packages. Now that it's not, those complaints have been replaced
> with complaints of packages or programs being missing (when in fact
> the "missing" packages or programs simply were not installed).

You can't satisfy everyone on a list like this, especially when half
the posters seem to think they've a right to be satisfied :) By ``a
concern'' I meant ``the Cygwin maintainers care about this''.

> >Jon Cast

> Randall Schulz

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/

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

[Nicholas Wourms]

--- Jon Cast <jcast@ou.edu> wrote:
> Randall R Schulz <rrschulz@cris.com> wrote:
> <snip>
> > I may have missed something (please forgive me for not re-reading
> > the thread), but why is a non-Cygwin program (NTEmacs) relying on a
> > Cygwin tool?
> 
> Because Emacs is a Unix program.  It's been evolved to deliver very
> nearly to full power of the Unix environment, and as such uses /many/
> Unix tools.  Many of those tools are not easily available on Windows,
> but if Emacs finds a copy of them, it'll use them anyway.  This is a
> feature, not a bug.
> 
> > Surely it can be configured to use the correct one, right?
> 
> If there's a Windows gzip installed, you can customize Emacs to use
> it.  But why install two gzips?
> 
> > If NTEmacs doesn't include it's own gzip / gunzip, then editing a
> > compressed file wouldn't even be possible without Cygwin installed,
> 
> s/Cygwin/gzip/.  Of course you can't edit
> 
> > so it seems incumbent upon NTEmacs to deal with the challenges of
> > doing so in their most generic form.
> 
> Why does Emacs have to work around this conceit that all the world
> should be a Cygwin program, when /making gzip work from Emacs/ is so
> much easier?  Consider: Cygwin is a Unix emulation environment, right?
> So if every program was a Cygwin program, every program would be a
> Unix program, and we could all use Unix.  Cygwin exists because some
> people have to use Windows programs.  Ergo, Cygwin cannot pretend
> Windows programs do not exist.

Shoo you Emacs troll, we've heard enough of your rhetoric...

__________________________________________________
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com

--
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/

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

[Jon Cast]

Nicholas Wourms <nwourms@yahoo.com> wrote:
<snip>
> Shoo you Emacs troll, we've heard enough of your rhetoric...

Shoo you VI troll, we've heard enough of your rhetoric...

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/

RE: gzip.exe as symlink...

[Robinow, David]

> From: Nicholas Wourms [mailto:nwourms@yahoo.com]
> Subject: Re: gzip.exe as symlink...
> --- Jon Cast <jcast@ou.edu> wrote:
> > Robert Collins <robert.collins@syncretize.net> wrote:
> > <snip>
> > > I'd never thought about it - why would anyone care which is the real
> > > file?
> > 
> > If they have to use any program not linked with cygwin1.dll.
> You should be using vi & bash, then you wouldn't have all 
> these "issues".
 bash has nothing to do with this issue.  Use of "vi" will have the same
issue as "emacs". i.e., unless you use a cygwin version it will not
recognize cygwin links.  Some people like to use NTEmacs because it has some
features not available in cygwin XEmacs.  I don't know if there's an NTvi
with features not present in cygwin vi -- I've never used vi.  In fact I've
never met anybody who's used vi more than casually, although I hear it's
popular in some circles.
 In any case there's no need to learn an obscure editor just to read
compressed files.   (setq jka-compr-use-shell t)  will force the compression
code to use a shell (defaults to "sh") instead of "call-process". Use of a
cygwin shell is of course required.
 One could also dispense with the use of links altogether. gzip.exe is only
60K.

--
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/

RE: gzip.exe as symlink...

[Nicholas Wourms]

--- "Robinow, David" <drobinow@dayton.adroit.com> wrote:
> > From: Nicholas Wourms [mailto:nwourms@yahoo.com]
> > Subject: Re: gzip.exe as symlink...
> > --- Jon Cast <jcast@ou.edu> wrote:
> > > Robert Collins <robert.collins@syncretize.net> wrote:
> > > <snip>
> > > > I'd never thought about it - why would anyone care which is the
> real
> > > > file?
> > > 
> > > If they have to use any program not linked with cygwin1.dll.
> > You should be using vi & bash, then you wouldn't have all 
> > these "issues".
>  bash has nothing to do with this issue.  Use of "vi" will have the same
> issue as "emacs". i.e., unless you use a cygwin version it will not
> recognize cygwin links.  Some people like to use NTEmacs because it has
> some
> features not available in cygwin XEmacs.  I don't know if there's an
> NTvi
> with features not present in cygwin vi -- I've never used vi.  In fact
> I've
> never met anybody who's used vi more than casually, although I hear it's
> popular in some circles.
>  In any case there's no need to learn an obscure editor just to read
> compressed files.   (setq jka-compr-use-shell t)  will force the
> compression
> code to use a shell (defaults to "sh") instead of "call-process". Use of
> a
> cygwin shell is of course required.
>  One could also dispense with the use of links altogether. gzip.exe is
> only
> 60K.

Sigh, as usual the emacs camp always misses the point.  You use a shell
for file operations and you use an editor for editing.  Why is there any
need to muddle the two?  Vi is simple and elegant, whereas emacs is
well...  rather bloated and not very elegant.  Would you use a chainsaw to
cut a diamond?  I think not...

Cheers,
Nicholas


__________________________________________________
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com

--
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/

Re: gzip.exe as symlink...

[Jon Cast]

Nicholas Wourms <nwourms@yahoo.com> wrote:
<snip>
> Sigh, as usual the emacs camp always misses the point.

``As usual ... always''.  Not simple or elegant.  Not relevant, but
neither are your comments.

> You use a shell for file operations

So `vi foo.gz' works why?

> and you use an editor for editing.

Right.  Not a viitor.  Not an emacsitor.  Those aren't even words!

> Why is there any need to muddle the two?  Vi is simple and elegant,

And is an actual editor.

> whereas emacs is well...

Not an editor.  It's a desktop environment under the delusion it's an
editor.  It's still a better editor (no ugly i/a/e/etc. just to type
in text) and desktop environment (M-x customize is the best thing I've
seen) than anything else out there.

> rather bloated

For a desktop environment?

> and not very elegant.

How can something be more elegant than Lisp?

> Would you use a chainsaw to cut a diamond?  I think not...

No.  But I wouldn't precariously balance said diamond between my
fore-finger and tongue, either.  I'd use a real tool to hold it.

> Cheers,
> Nicholas

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/

files and directories distinction:

[Aldi Kraja]

Hi,
How I can set the env to see directories with some / at the end of it. 
Right now everything files and directories look the same (under cygwin) 
when I apply a dir or an ls -l.

TIA,
Aldi

-- 




--
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/

Re: files and directories distinction:

[Randall R Schulz]

Aldi,

I don't know about "dir," which is a Windows / DOS-ism, but any Unix / 
POSIX / Gnu "ls" command, including Cygwin's, will flag file system 
entities in its output when given the -F option. Directory names get a 
trailing slash, executables a star (asterisk), symbolic links an at-sign (@).

I am unaware of any environment variable that activates this option, 
however. I use this option often enough that I have aliases that supply it 
for me. For example:

alias lf='ls -F'
alias ll='ls -lF'


This is nothing Cygwin-specific, of course.

Randall Schulz
Mountain View, CA USA


At 17:41 2002-07-16, Aldi Kraja wrote:
>Hi,
>How I can set the env to see directories with some / at the end of it. 
>Right now everything files and directories look the same (under cygwin) 
>when I apply a dir or an ls -l.
>
>TIA,
>Aldi


--
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/

Re: files and directories distinction:

[Jon Cast]

Randall R Schulz <rrschulz@cris.com> wrote:
> Aldi,

> I don't know about "dir," which is a Windows / DOS-ism,

Actually, from GNU/Linux:

$ which dir
/usr/bin/dir

`dir' is a GNU program which is equivalent to `ls -C -b'.  I don't
know whether he meant the dir in command.com or GNU dir, but `dir' is
not just a DOS-ism.  (Sorry, I'm just feeling feisty today.)

<snip>

> 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/

Re: Mozilla 1.3 built on cygwin?

[Jeff.Hodges]

> Just outta' curiosity, beyond the satisfaction of accomplishing it,; charset=us-ascii
> what would be gained?

I wasn't sure what would be gained or the various ramifications. wanted to get 
hints about them, which this thread has done.


JeffH



--
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/