Mailing-List:	contact cygwin-apps-help AT cygwin DOT com; run by ezmlm
Sender:	cygwin-apps-owner AT cygwin DOT com
List-Subscribe:	<mailto:cygwin-apps-subscribe AT cygwin DOT com>
List-Archive:	<http://sources.redhat.com/ml/cygwin-apps/>
List-Post:	<mailto:cygwin-apps AT cygwin DOT com>
List-Help:	<mailto:cygwin-apps-help AT cygwin DOT com>, <http://sources.redhat.com/lists.html#faqs>
Mail-Followup-To:	cygwin-apps AT cygwin DOT com
Delivered-To:	mailing list cygwin-apps AT cygwin DOT com
Date:	Thu, 30 May 2002 19:25:25 +0200
From:	John Marshall <johnm AT falch DOT net>
To:	Ton van Overbeek <tvoverbe AT cistron DOT nl>
Cc:	cygwin-apps AT cygwin DOT com, carl_sorensen AT byu DOT edu
Subject:	Re: Setup 2.218.2.9 fails to read setup.ini file from prc-tools mirror
Message-ID:	<20020530172525.GA3593@kahikatea.falch.net>
References:	<3CF65413 DOT A77DACD1 AT cistron DOT nl>
Mime-Version:	1.0
In-Reply-To:	<3CF65413.A77DACD1@cistron.nl>
User-Agent:	Mutt/1.3.27i

On Thu, May 30, 2002 at 06:32:19PM +0200, Ton van Overbeek wrote:
> From the definitions in iniparse.y it is clear that the sdesc and
> ldesc arguments have to be put in quotes in order to be recognized as
> a single token.
[...]
> One thing which maybe could cause problems is the accomodation of the
> md5 checksum support in setup.ini.

All of that, but the errors occur right at the start of the file, in the
headers part.  So problems down in the packages part can't be it, because
they haven't been parsed yet.

I've been reading more about what $undefined means to bison (I think it
means the lexer returned something that isn't listed in %token in
iniparse.y).  With that in mind, I've nuked the comments from the top of
the file just in case, but I really don't think it should make a
difference.

> An other thing which might be going on is that after the download
> from setup.ini from sourceforge (via http) the file does not get
> properly closed, and/or does not get the right permissions to be opened
> again for reading by the parser. All these permission problems do
> not exist on Win9x.

Hmmm... this seems like a possibility.  The only reports of this have
been on Windows 2000 and XP.  (An error-induced EOF would probably look
like $undefined in the header part.)

    John

- Raw text -