Date:	Wed, 27 Jan 1999 15:03:21 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Pierre Muller <muller AT cerbere DOT u-strasbg DOT fr>
cc:	djgpp-workers AT delorie DOT com
Subject:	Re: Question about redir
In-Reply-To:	<3.0.5.32.19990126131543.0083c400@ics.u-strasbg.fr>
Message-ID:	<Pine.SUN.3.91.990127145500.15652A-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com

On Tue, 26 Jan 1999, Pierre Muller wrote:

>   Why doesn't redir.exe  (DJGPP version from src/utils directory)
> expands wildcards for its child program ?

What version of DJGPP are you using?  Is that v2.01?  If not, upgrade to 
v2.02, where several subtle bugs in `redir' were corrected.

>    redir -e log grep unfreed log*
> allways ends up in 
> 
> grep : log* : No such file or director...
> 
>   What is the reason for disabling wilcard expansion in redir ?

`redir' itself shouldn't expand wildcards, it should leave that to the 
program it runs.  `redir' doesn't know (and shouldn't know) what will the 
subsidiary program do with the wildcards.  For example, if the subsidiary 
program itself disables wildcard expansion, expanding them in `redir' 
would be the wrong thing.

In other words, `redir' should invoke the subsidiary program so that the 
argv[] array is *exactly* like it would be if the subsidiary program were 
invoked directly from the command line.

The problem with `redir' before v2.02 was that it invoked the subsidiary 
programs in a way that prevented them (the subsidiary programs) from 
expanding the wildcards themselves.  This is a tricky subject, and very 
complicated to explain (which is one reason why it wasn't fixed until 
recently); for details, download djlsr202.zip, look into redir.c, and 
*then* ask more specific questions if the comments there don't explain 
this mess well enough.

- Raw text -