delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1994/04/22/15:25:57

From: rri!potter AT vtserf DOT cc DOT vt DOT edu (Mark Allen Potter)
Subject: Re: make problem (probably go32 prob)
To: ericb AT lsid DOT hp DOT com (Eric Backus)
Date: Fri, 22 Apr 1994 14:07:27 -0400 (EDT)
Cc: djgpp AT sun DOT soe DOT clarkson DOT edu (DJ G++ Mailing List )
Reply-To: rri!potter AT vtserf DOT cc DOT vt DOT edu

> > Just bumped into another make problem, however this one is probably
> > actually a problem with go32.  It is best illistrated with the
> > following make file:
> > 
> > 	t1:
> > 		c:/djgpp/bin/echo This is a test
> > 
> > 	t2:
> > 		c:/djgpp/bin/echo "This is a test"
> 
> ...
> 
> > Anyone have any ideas on the cause of the problem.
> > My quick look at the go32 code revealed that it system()'s if there
> > is and redirection in the command ("<>|"), otherwise it spawnlp()'s
> > (if that fails it falls through to the system() call).
> 
> I'm not sure what go32 code you're referring to. 

I was referring to the code in exphdlr.c turbo_assist() case 7.  This code is
sensitive to the < > or | character being withing the command to execute.
However (silly me wasn't thinking), this code is executed in real mode, and has
nothing to do with a go32 program envoking another go32 program.  That code (I
assume) would be mostly in protected mode (libsrc) with a possible assist in
real, though such assist would not involve system() or spawn*() functions.  Now
with your comments an a look at the make source, I see that this isn't the
problem at all.

> However, make itself
> has to decide whether to use the shell (command.com in this case) when
> it executes a line from the makefile.  Make looks for any characters
> that require a shell to interpret, which includes quote characters,
> wildcards, redirection, and so on.  If it sees these characters, make
> will use a shell to execute the command, otherwise make will execute
> it directly.

Since I made the silly assumption that it was go32 that decided if (and how) to
envoke another go32 program, I didn't look at the make source.  Now that I look
at the make source I do see the trapping of the special characters ("<>|). 

[I also note that it does the same for the internal dos commands (expected).
However I noticed that "if" is in the table twice and "loadhigh", "lh", and
"truename" are not.  Use of "loadhigh" and "lh" could get one in trouble, and
"truename" is currently an undocumented command.  Of cource if we add these,
what about the 4DOS (or other alternate shell) internal commands.]

When make finds one of these it actually writes a batch file to execute the
command:
	@echo off
	{command}
	if errorlevel 1 del {flagfile}
I notice that it makes no attempt to change /'s to \'s in the command.  However
I can see that this might not be as simple as first seams.  Say the command was
"dir/w *.c" which is a correct formed dos command becomes "dir\w *.c".  Should
be do able (if first token is in sh_cmds, don't convert, else convert upto
first white space).

Anyways, thanks for the pointer.  I didn't realize make would be making such
distions

Anyways, thanks for the pointer.  I didn't realize make would be making such
decisions.
					Potter
					rri!potter AT vtserf DOT cc DOT vt DOT edu



- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019