On Friday, March 11, 2005 4:22 PM [EST], René Berber wrote: > Brian Bruns wrote: > >> Its Cygwin, so I'll have to diagnose this with my user, since I'm >> not seeing these problems on my end. > > That explains everything: Cygwin version 1.5.13-1 (the latest) > changed the way it reports exit codes to Windows. > > Inside a Cygwin shell everything is normal (in your case the shell > intercepts the 128 and shows a text message which is the usual way > under Unix) but for Windows processes things changed, now exit > codes are multiplied by 256 and core dumps or other problems are > included in the exit code, which (at OS level) is composed of two > parts, <exit code>:<reason> (that's two bytes, usually reason is 0 > so exit code 1 is integer 256, and so on). > > I had to change cgFilterMessages (a CommunigatePro filter) when > this Cygwin change started. If you use clamdwatch.pl under anything > that is not a Cygwin shell you'll have to change the way exit codes > are handled (actually you have to change clamdwatch.pl anyway since > Cygwin's perl doesn't handle the line that sets the temporary file > mod).
The issue with return codes in 1.5.13 was fixed in a 1.5.14 snapshot which is what this user is using. I know all about the return code issue, and was ready to fork the Cygwin source code to fix it if they didn't fix it themselves. With the latest snapshots, everything is returning the right codes again So, I still have the issue where I need to find out what is causing the dumps in ClamAV. Back to square one. I have noone else reporting this issue currently. Latest cygwin snapshots are here if you need the latest DLL: http://www.cygwin.com/snapshots/ -- Brian Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org _______________________________________________ http://lurker.clamav.net/list/clamav-users.html
