Subject: Re: sysinst source niggles.... run_prog, logging/scripting rework?
To: Chris G. Demetriou <cgd@netbsd.org>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
List: tech-install
Date: 07/01/1999 09:32:15
>Cool!

Okay, thats a positive vote. (i dont understand why it got edited away
from this in the first place, but whatever.)

Cool!

>One of these things is not like the others...  8-)

Thats waseliberate. va_run_prog() is static in run.c.  Callers should
use one of the mnemonically_named variants.  vrunprog(), maybe?


>In what cases is run_prog_or_die() used (or the 'fatal' run_prog()
>flag currently used)?  It seems to me that, in general, dying is a
>very bad thing, and should be avoided.

Yes, its a bad thing. Its used in mv_within_target_or_die().  Some MD
files use inline versions of the body of that funciton (which is a
bug).  It's at the level of doing, e.g., `rm -f <file>' failing.  I'd
say all those calls should all be redone with a `show message and
abort back to main menu'.

For now, i was simply trying to identify the inapproriate uses.

More worrisome is that so many of the calls to run_prog* dont check
for any return status at all. (thats why we added the original named
variants: to track auditing).  I dont see any gain at all in setting
up a subwindow for, say, an `rm -f <temp file>') -- specially if the
caller isnt checking the return status....