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....