On Mar 17 15:55, Corinna Vinschen wrote: > On Mar 17 14:03, Dave Korn wrote: > > I noticed that the output from 'file' has changed recently, e.g.: > > > > /bin $ file -L /bin/ls.exe > > /bin/ls.exe: MS-DOS executable PE for MS Windows (console) Intel 80386 > > 32-bit > > > > Maybe this will help? Or perhaps something similar elsewhere. Libtool > > uses > > file in several ways to help it decide what it's going to build. > > > > > > /bin $ diff -pu libtool.orig libtool > > --- libtool.orig 2009-03-15 23:19:29.500000000 +0000 > > +++ libtool 2009-03-15 23:21:14.906250000 +0000 > > @@ -3273,6 +3273,7 @@ func_win32_libid () > > *executable*) # but shell scripts are "executable" too... > > case $win32_fileres in > > *MS\ Windows\ PE\ Intel*) > > + *PE*\ *MS\ Windows\ *Intel*) > > win32_libid_type="x86 DLL" > > I'm wondering how the original expression was supposed to work even > with older file(1) versions: > > $ file-4.21 /bin/bash > /bin/bash: MS-DOS executable PE for MS Windows (console) Intel 80386 32-bit > > That doesn't match "*MS\ Windows\ PE\ Intel*" as far as I can see.
Either way, do you want me to take this upstream? I'm already writing a mail to the upstream maintainer about the apparent inability to recognize troff files. While I'm at it, I could ask if the string for Win32 executables could be reverted to the old style. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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/
