This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Pending patches for generic build script


>-----Original Message-----
>From: Igor Pechtchanski
>Sent: Thursday, February 12, 2004 2:17 PM
>To: cygwin-apps<at>cygwin.com
>Subject: RE: Pending patches for generic build script
>
>Rafael,
>
>Please try to set up your mailer to not quote raw e-mail addresses in your
>replies.  Thanks.  More below.

Oops, will pay attention next time, sorry.

>
>On Thu, 12 Feb 2004, Rafael Kitover wrote:
>
>> >-----Original Message-----
>> >From: Igor Pechtchanski
>> >Sent: Wednesday, February 11, 2004 8:07 AM
>> >To: Yaakov Selkowitz
>> >Cc: cygwin-apps<at>cygwin<dot>com
>> >Subject: Re: Pending patches for generic build script
>> >
>> >locally, mostly to eliminate things that I'm already in the process of
>> >applying, such as the '; \' -> '&& \' transformation, and I'd rather not
>> >go through that again unless I have to.  If the patch is the same, just
>> >send a ChangeLog, please (more comments below).
>>
>> About the whole ;\ and &&\ ugliness, can we just have a "set +e" at the
>> top of the script, use sane single-command-per-line syntax and be done
>> with it? Will someone please think of the children?
>
>No.  This is for the same reason I'm not going to check in some of
>Yaakov's changes that replace the "find...; true" construct with just
>"find...".  Some commands (including find) return bogus values sometimes,
>and we don't want the script to stop for no reason.  I suspect that having
>"set +e; find...; set -e" will be even uglier than the current && syntax.
>At least the way it is now, you can see that the commands obviously depend
>on the others' results.

Well, the idea came to me from debian system scripts, which for the most part
are written with set +e at the top, including init scripts, postinstall
scripts, etc.. For commands that can return false but are not a fatal error,
this construct works:

false || true

As a bonus, this construct documents that this particular line can return a
false value.

-- 
Rafael


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]