Date: Wed, 13 Jan 1999 11:33:24 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Laszlo Molnar <laszlo DOT molnar AT eth DOT ericsson DOT se>
cc: djgpp-workers AT delorie DOT com
Subject: Re: djgpp 2.02 + perl + glob
In-Reply-To: <19990112174934.W29345@duna54>
Message-ID: <Pine.SUN.3.91.990113113254.27917A-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp-workers AT delorie DOT com


On Tue, 12 Jan 1999, Laszlo Molnar wrote:

> If a new glob() request arrives and I
> allocate (ie. open) another handle, its file pointer won't be set to 0
> because of dup.

As DJ told you, the fsext code doesn't move the handle.  Since your
handler services the call, DOS never sees any references to that
handle.  Thus, as far as DOS is concerned, the file pointer has never
moved anywere, it stays put at offset zero.

Please explain how do you track the file handle position, and how
using `dup' instead of `_open' affects this.

> I think this is a general problem, because when a file handle is
> allocated (opened) I would expect its file pointer set to 0.

The DOS file handle is connected to the NUL device.  The notion of the
file handle position doesn't make any sense for devices, even if some
calls are passed to DOS (which they aren't in your case).  So I really
don't understand the problem.