Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Message-ID: <425372AF.7070208@x-ray.at>
Date: Wed, 06 Apr 2005 07:25:03 +0200
From: Reini Urban <rurban AT x-ray DOT at>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:1.7.5) Gecko/20041217
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: Unusual new look to symlinks to executables
References: <040520052315 DOT 15459 DOT 42531C000005BAFE00003C6322069984990A050E040D0C079D0A AT comcast DOT net>
In-Reply-To: <040520052315.15459.42531C000005BAFE00003C6322069984990A050E040D0C079D0A@comcast.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes

Eric Blake schrieb:
...
> Below is the table of how I think ln(1) ought to behave (I'm open to
> suggestions if others think differently).  Where ln(1) does not actually behave
> this way, I am open to help in patching coreutils to provide the desired
> functionality.  Hopefully my webmail interface didn't screw up this table too
> badly.
> 
>        existing:	a	a.exe	both	neither
> ln    a     b		1	4	4	0
> ln    a.exe b		0	2	2	0
> ln    a     b.exe	3	4	4	0
> ln    a.exe b.exe	0	4	4	0
> ln -s a     b		5	6	5	7
> ln -s a.exe b		9	8	8	9
> ln -s a     b.exe	10	11	10	12
> ln -s a.exe b.exe	14	13	13	14
> 
> results:
> 0.  error
> 1.  b is hardlink to a
> 2.  b is hardlink to a.exe
> 3.  b.exe is hardlink to a
> 4.  b.exe is hardlink to a.exe
> 5.  b is symlink, readlink b gives a, resolves to a
> 6.  b is symlink, readlink b gives a, resolves to a.exe
> 7.  b is symlink, readlink b gives a, dangling link
> 8.  b is symlink, readlink b gives a.exe, resolves to a.exe
> 9.  b is symlink, readlink b gives a.exe, dangling link
> 10. b.exe is symlink, readlink b.exe gives a, resolves to a
> 11. b.exe is symlink, readlink b.exe gives a, resolves to a.exe
> 12. b.exe is symlink, readlink b.exe gives a, dangling link
> 13. b.exe is symlink, readlink b.exe gives a.exe, resolves to a.exe
> 14. b.exe is symlink, readlink b.exe gives a.exe, dangling link
> 
> I guess one final question is whether cygwin's readlink(2) should be allowed to
> append .exe if that's what the symlink currently resolves to, or if it should
> always return exactly what is contained in the link.  My table above assumes
> that readlink(2) does not auto-append .exe when resolving a symlink.
> 
> --
> Eric Blake
> (coreutils maintainer)

Eric,
Just a big thank you, that you are doing a really great job!

-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban
http://phpwiki.org

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/