Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-owner AT sources DOT redhat DOT com
From: "Lothan" <lothan AT newsguy DOT com>
To: <cygwin AT cygwin DOT com>
Subject: RE: New symlinks.
Date: Tue, 27 Feb 2001 23:08:00 -0800
Message-ID: <GAENLJIGIGCHDHJMOLPDEEOCCFAA.lothan@newsguy.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-reply-To: <20010227104026.B10525@redhat.com>
Importance: Normal

> From: cygwin-owner AT sources DOT redhat DOT com
> [mailto:cygwin-owner AT sources DOT redhat DOT com]On Behalf Of Christopher Faylor
> Sent: Tuesday, February 27, 2001 7:40 AM
> To: Cygwin
> Subject: Re: New symlinks.
>
>
> On Tue, Feb 27, 2001 at 07:42:05PM +1300, Danny Smith wrote:
> >cgf said:
> >
> >> ...,but I'm not sure that we should ever expose the fact that a
> >> symlink now has a .lnk extension to the user.
> >>
> >>Comments?
> >>cgf
> >
> >Expose yourself to the user, unless you have dirty secrets that might
> >offend.
>
> I'm not sure what qualifies as a dirty secret but the whole principle
> of Cygwin is that it hides things from the user.  You really can't
> make this argument if you're talking about Cygwin.

What kinds of things does Cygwin hide from the user? I mean besides those
internalized in the "kernel" that a normal user wouldn't know about anyway?

> I'm going for the principle of least surprise.
>
> If I do an "ls" and don't see a file with a .lnk extension but I can
> still magically reference one by typing cat foo.lnk, I think that is
> surprising.

I think you just made the argument to show the extension. :-) Currently the
.exe extension is somewhat of a catch 22. If I do an ls -l /bin/awk I see
clearly awk.exe. On the other hand, if I attempt to cp /bin/awk ~/awk, I get
the error that '/bin/awk' and '~/awk' are the same file (even though ~/awk
doesn't exist). If awk.exe exists in the directory, I can't cp awk.exe awk
(no such file or directory). Yet I can cat test.c >awk successfully even
though awk.exe is in the same directory. No, I'm not complaining so don't
take it that way. I'd much rather try to find and fix problems myself,
anyway.

> I *really* don't think that the .lnk extension should show up when
> doing an "ls -l" as was suggested in another post.  That is just an
> open invitation to increasing mailing list traffic: "How do I get rid
> of the .lnk extension when I create symlinks????  It doesn't do this
> on Linux."

I can see this going in several directions and I'm not certain that there is
one correct answer. For example, is the link to gawk.exe shown as awk,
awk.lnk, awk.exe or awk.exe.lnk? One could make the assumption that awk and
awk.lnk are shell scripts since they don't have an .exe extension. By the
same token, if I do an ls -l /bin/awk it should search for and show all
combinations of the above.

I can see far more confusion when someone does an ls -l /bin/awk and sees
awk.exe displayed twice -- one being awk.exe and another a symbolic link
awk.exe(.lnk). I think a logical assumption here is to enforce a rule
stating that you can't create a link using the name of existing file without
the .lnk extension... whether or not the .lnk extension is displayed. The
real question, at least in my opinion, is which file gets executed if I run
/bin/awk and I have both awk.lnk and awk.exe?

Needless to say, there are some complicated issues just in this one aspect
of using the new symbolic links. Even so, I *still* like the idea of using
.lnk files over the current system.

Here's a funny one. If I ln -s /bin/gawk.exe ~/awk I can execute ~/awk...
but if I cp --no-dereference /bin/awk.exe ~/awk[.exe] it won't run (no such
file or directory). Oh well, this is slightly off topic from the current
thread and gives me another excuse to go digging through the code so I can
become more familiar with it.

> I am, as always, more concerned about supporting this feature in
> the long run.  If allowing foo.lnk to be referenced explicitly causes
> even one person confusion, I don't think that it is worth it.  It
> is certainly non-UNIX behavior.

I disagree. I think it is well worth the effort to make this move, but it
sounds like there are some implementation issues that need to be resolved.
For that matter, Windows is non-UNIX behavior but Cygwin seems to manage
fairly gracefully... .exe extensions and all.


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple