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/
