Suggestion: Can we please have it so that all system calls go through a single subroutine?
Hence, where you currently have:
if( $theSearchVal ) {
# do grep search
chdir( "$sDir" );
$cmd =~ /(.*)/;
$cmd = $1; # untaint variable (NOTE: Needs a better check!)
$tempVal = `$cmd`;
and:
$tmp =~ /(.*)/;
$tmp = $1; # now safe, so untaint variable
return `$tmp`;
}
replace these with something like:
if( $theSearchVal ) {
# do grep search
chdir( "$sDir" );
$cmd =~ /(.*)/;
$cmd = $1; # untaint variable (NOTE: Needs a better check!)
$tempVal = logExec($cmd);
and:
$tmp =~ /(.*)/;
$tmp = $1; # now safe, so untaint variable
return logExec($tmp);
}
The reason I would want this is that it makes tracing much easier, especially when trying to sort things out on a different platform where the underlying binaries (such as ls) might be misbehaving.
I use the following implementation:
sub logExec
{
my($cmd) = @_;
$doLogTopicExec = $doLogTopicSave; # FIXME - make a global variable in wikicfg.pm
$doLogTopicExecResult = $doLogTopicSave; # FIXME - make a global variable in wikicfg.pm
if( $doLogTopicExec ) {
writeLog( "exec", '$webName.$topic', "exec $cmd" ); # FIXME pickup the vars
}
$cmd .= " 2>&1"; # FIXME - only on needed on NT?
my $res = `$cmd`;
if( $doLogTopicExecResult ) {
writeLog( "execresult", '$webName.$topic', "$res" ); # FIXME pickup the vars
}
return $res;
}
Instances of `cmd`:
- 1 change in wikisearch.pm
- 12 changes in wikistore.pm
Thanks,
M.
--
MartinCleaver - 24 Feb 2001
This is something that needs to be done along with the code cleanup that is currently going on.
--
PeterThoeny - 24 Feb 2001
Hmm... layering in general is not a bad idea. However, I'm not sure that it's worth the effort in this case:
- Alternatives are available. (I know there are tools for tracing shell calls under Win32, similar tools should be available for Unix or Perl).
- It will slow down TWiki.
- Never change a running system
--
JoachimDurchholz - 26 Feb 2001
Hmm. Can you tell me what you would use on NT? I'd use truss on UNIX.
--
MartinCleaver - 02 Mar 2001
E.g. see
http://www.sysinternals.com
, which (among other things) carries filemon. This will give you all file read (and I reckon this includes calling other programs).
Note that I haven't tested it yet (you need admin privileges on an NT box to use it, and I don't have these here).
I'm pretty sure that other tools exist.
Has the Perl interpreter no way of intercepting system() and ``?
--
JoachimDurchholz - 06 Mar 2001
FWIW, I too would like to see this implemented ASAP! Not only does it centralize external calls, it opens the door in the future for abstracting the external programs: e.g. easing conversion to another storage system if desired. It also makes it easier to debug things that have gone wrong!
--
DavidLeBlanc - 20 Mar 2001
Check out
http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/twiki/lib/TWiki/Store/Attic/RCS.pm?rev=1.1.2.3&content-type=text/x-cvsweb-markup&cvsroot=twiki
Particularily:
sub myticks
{
my $tmp = shift;
my $pid;
my @output;
die "cannot fork: $!" unless defined ($pid = open(PIPE, "-|"));
if ($pid == 0) {
exec($tmp) or die "can't exec $tmp: $!";
} else {
@output = <PIPE>;
close PIPE; # $? contains status
}
return @output if ( wantarray );
return undef unless(defined wantarray);
return join( '', @output );
}
We can wrap stack traces and grabbing both STDOUT and STDERR all into one nice package. Its not a biggy for me though at the moment because I'm trying to find a clean/nice API for TWiki::Store::*.
Anyway even things like lsCmd and grepCmd need to be replaced by something generic and native perl. This for two reasons, i) performance and ii) TWiki::Store::DBI when I get around to it.
--
NicholasLee - 20 Mar 2001
This has been implemented in
DakarRelease. All system calls go through the TWiki::Sandbox module.
--
RafaelAlvarez - 15 Mar 2006