Unusual new look to symlinks to executables
fergus@bonhard.uklinux.net
fergus@bonhard.uklinux.net
Wed Apr 6 08:00:00 GMT 2005
Thank you for responding so quickly and so fully.
> Also, did you upgrade to cygwin 1.5.14 at the same time?
> It might be a change in the cygwin path handling.
Not at the same time, but it may be that this was the first time I used the
"link-checking script" since upgrading to 1.5.14. Certainly that struck me
as a possible cause for the changed behaviour, but it also appeared to me
that all the altered links were related to coreutils and tetex, which is why
I drew the conclusions that I did.
> By default, ls does not display just a filename and its link contents.
I was using ls -alF but edited the output in my email to just show filename
and link contents.
>> So perhaps it is accidental, and should not have happened?
> It certainly was not intentional.
> It is tricky to get both ln(1) and ls(1) to handle implicit .exe magic
correctly,
> and I may need to release a new coreutils that makes it more consistent in
the future.
Thanks for explaining everything so fully. The reason for using my
link-checking script is that it pipes its output to other scripts, that then
change all symlinks created as Windows +S system files to Windows +R *.lnk
files, for later copying to CD. It was the "change" scripts that were broken
as a consequence of the phenomenon I have described.
It seems to me that it will be unduly optimistic to assume future
consistency in the Cygwin provision -- as in links always being of the form
execlink -> execname.exe -- and that I have been remarkably fortunate to
find such consistency up to now; and that I will need to alter my scripts to
cover the additional possibility execlink -> execname.
Thanks again for all your help.
Fergus
--
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/
More information about the Cygwin
mailing list