On 2/7/2014 06:53, David Stacey wrote:
On 07/02/2014 09:49, Corinna Vinschen wrote:
On Feb 6 14:43, Warren Young wrote:
I know a guy who currently has all of
Cygwin downloaded and ready to re-install, to test this.:)
Try this: strings -f/bin/*.exe/bin/*.dll | grep getgrent
Let me save you the trouble of reinstalling it
Thank you!
> Results attached.
The cppcheck, cygqscintilla*.dll and nedit results are bogus. (i.e. They
contain these strings for other reasons.) Here's a better check that
doesn't give false positives:
$ cat <<END > checkfile
#!/bin/sh
if egrep -q '_getgrent(32|64)' "$1" ; then echo $1 ; fi
END
$ find /bin -name \*.exe -exec ./checkfile {} \;
cygperl*.dll includes the functions only because it wraps them. I
assume Perl's configuration script is smart enough to cope if they're
missing.
I assume the shells (bash, mc, and tcsh) also have alternate code paths
for systems where these functions don't exist.
ytree's use of these functions is obvious. I don't know that I'd bet on
it having an alternate code path, though.
I have no guess why socat needs these functions, but given that it was
recently updated, I will guess the socat devs aren't interested in
moving to more modern APIs. Programs like this, where user management
isn't any kind of real focus, are where you expect to find old, easy
APIs used in preference to more modern, more complicated APIs.
cygwin1.dll is obvious. :)
Emacs...why am I not surprised that it uses these old functions?
Vim does not, therefore Vim is the superior text editor. (I kid.)
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
