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:

1. Alternatives are available. (I know there are tools for tracing shell calls under Win32, similar tools should be available for Unix or Perl).
2. It will slow down TWiki.
3. 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