Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
From: "AVT-Wien" <wien AT avt DOT at>
To: <cygwin AT cygwin DOT com>
Subject: Re: More error level issues
Date: Thu, 31 Mar 2005 20:48:05 +0200
Message-ID: <NDBBLEGOCELADMPKABOKAEAEFLAB.wien@avt.at>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Note-from-DJ: This may be spam

Hi,

With cygwin1.dll version 1.5.13 exit codes to Windows (I use W2K and XP) have
changed by a factor of 256 (shift of 8 bits) as mentioned in the 2 messages
cited below. I have processes running under Windows shells that run several
days, doing a lot of steps (both unix tools like gawk, head, sort etc. and gcc
compiled c-programs) fully automatically. Flow control heavily relies on return
codes (%errorlevel% in Windows). The codes were introduced according to the
exit codes of the previous versions of the cygwin-libraries that put into
%errorlevel% exactly what was provided by exit(). With the upgrade to 1.5.13
the exit codes changed by a factor of 256, and since Windows XP uses 16 bit
codes, are now limited to a maximum value of 255.

Before I check and change many hundreds of lines of *.bat files: Will this
return code behaviour change again in the future or can I assume this will
last?

By the way, does anybody around know a workaround - or have an idea - how to
get the exit codes stripped off the 8 least significant bits without changing
the *.bat-files in Windows XP? And eventually even get back values higher than
255?


Thanks a lot,

Wolfgang Rieger


On Wed, 02 Mar 2005 14:11:19 -0800, Brian Dessent wrote:
(Message: http://sourceware.org/ml/cygwin/2005-03/msg00099.html )
> Brian Bruns wrote:
...
> > Your telling me an exit code of 1 inside of cygwin (and Linux for that
> > matter) is supposed to be considered as errorlevel 256 by Windows
> > rather then 1?  I'm sorry if I am not catching on here entirely of why
> > this is.
>
> Under unix, the "process completion status" is an integer, and is the
> value returned by the wait() family of functions.
...
> Anyway, what cgf is saying is that under linux if you call wait() on a
> process that "returns 1", i.e. calls exit(1), the process completion
> status will be 256.  Your shell handles interpretating the completion
> status so that it knows how the process ended, and sets $? to the
> "return value".
>
> Brian

On Wed, 2 Mar 2005 16:17:03 -0500, Christopher Faylor wrote:
(Message: http://sources.redhat.com/ml/cygwin/2005-01/msg01382.html )
> On Sun, Jan 30, 2005 at 03:06:03PM -0500, Brian Bruns wrote:
> >Up until Cygwin 1.5.12, the return code from stuff like clamscan was
> >being passed back to Windows, so programs outside of Cygwin could call
> >the binary and tell weather or not the program found a virus in the
> >file it scanned.
> >
> >Now, in the latest snapshots, that is no longer the case.  See example
> >below using freshclam, but also applies to the other apps:
>
> The odd error return was unintentional but there will be a change in cygwin
> 1.5.13 -- the error return will match what you'd expect for a unix program.
>
> So, this is what you should expect:
>
>   c:\>sh -c 'exit 1'
>   c:\>echo %errorlevel%
>   256
>
> This will be the behavior of the next snapshot.
>
> cgf
>


--
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/