X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
From: "bdeck" <bdeck AT lycos DOT co DOT uk>
Newsgroups: comp.os.msdos.djgpp
Subject: DJGPP pipe troubles
Date: Tue, 2 Dec 2003 12:17:56 +0100
Organization: Flow Communications AU
Lines: 56
Message-ID: <bqgoma$jle$1@au-nws-0001.flow.com.au>
NNTP-Posting-Host: int.flowcom.com.au
X-Trace: au-nws-0001.flow.com.au 1070327306 20142 202.129.64.242 (2 Dec 2003 01:08:26 GMT)
X-Complaints-To: usenet AT au-nws-0001 DOT flow DOT com DOT au
NNTP-Posting-Date: Tue, 2 Dec 2003 01:08:26 +0000 (UTC)
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

Hello,

Perhaps a solution can be found for a problem:
I notice certian DJGPP executables create temporary files in $DJDIR/tmp like
'dj100000'. PythonD is one of them, in fact. These files get deleted
automatically when the process ends. However, if the process that created
the tempfile also spawned another process (via 'system' call), this tempfile
does not get deleted until the external execuatable is also closed. The
problem is that all DJGPP pipes ABORT until that process is closed, too, and
the tempfile is deleted automatically by the system:

Some examples:
D:\>bash
bash.exe: cannot make pipe for command substitution: No such file or
directory (ENOENT)
bash:-bdeck# exit
<this is a crash>

D:\>pythond
**Pth** INIT: Cannot create internal pipe: No such file or directory
(ENOENT)
Abort!
Exiting due to signal SIGABRT
Raised at eip=001c00cd
eax=0032be40 ebx=00000120 ecx=00254530 edx=00000000 esi=0032f540
edi=0032f544
ebp=0032bef8 esp=0032be30 program=D:\USR\DJGPP\BIN\PYTHON\PYTHOND.EXE
cs: sel=01a7  base=02010000  limit=0032ffff
ds: sel=01af  base=02010000  limit=0032ffff
es: sel=01af  base=02010000  limit=0032ffff
fs: sel=017f  base=00013480  limit=0000ffff
gs: sel=01bf  base=00000000  limit=0010ffff
ss: sel=01af  base=02010000  limit=0032ffff
App stack: [0032c074..002ac074]  Exceptn stack: [002ab0f4..002a91b4]

Call frame traceback EIPs:
  0x001c0014
...

Of course, this is only a problem under Windows systems, where a DOS
executable might be used to start up an external Windows process. What I
don't understand is why the DOS program can't clean up its tempfile
immediately. The fact that an external system call is still running in
Windows environment should be irrelevant to DJGPP, or?

I have a feeling that this may have to do with how NTVDM runs piped commands
internally, because the OS is also unable to remove this 'dj100000' file
until the spawned process ends. Is there a way to divorce this attachment in
code?

Thanks
Ben