Since the split up of
TWikiVariables Item1699:
I get a couple of the following when viewing TWikiVariables:
| 22 Feb 2006 - 22:53 | exec failed: Argument list too long
at .../DEVELOP/lib/TWiki/Sandbox.pm line 317.
HJ
Can you debug some more please? How many Var* topics are there in your install, for example?
CC
This is very odd,
I
definitely can't remember having reported this.
There seems some misunderstanding or someone misusing my name (although I can't imagine why

).
Anyway, I have recently checked out the actual SVN 8925 and there is no problem with
TWikiVariables. I have 84 files starting with
Var
in my
data/TWiki
directory. Did not compare this with the number of
TWikiVariables yet, but that could match. So maybe this can be discarded.
FJ
Sorry
FJ
- I forgot to add my signature to
Item1699.
The fix for
Item1699 sort of "removed" the error messages for
TWikiVariables, but I can still reproduce it with a search over my TWiki web.
The problem is a re-incarnation of
TWiki:Codev.ArgumentListIsTooLongForSearch
(I found the reference when tracing through
RcsFile.pm
): TWiki is building a topic list and feeds this as argument to
fgrep
, chunked to 512 topics each. In my svn installation I happen to have a rather long installation path for the base dir (
/home/haj/public_html/_svn_Dakar/DEVELOP/
). The list of 512 files exceeds 36000 Bytes, on which my OS (cygwin) seems to croak. It isn't a hard death: The argument list is silently truncated, one wouldn't see the problem from viewing the page alone.
If I change line 341 in
RcsFile.pm
:
Index: lib/TWiki/Store/RcsFile.pm
===================================================================
--- lib/TWiki/Store/RcsFile.pm (revision 8925)
+++ lib/TWiki/Store/RcsFile.pm (working copy)
@@ -338,7 +338,7 @@
my $sDir = $TWiki::cfg{DataDir}.'/'.$this->{web}.'/';
my $seen = {};
# process topics in sets, fix for Codev.ArgumentListIsTooLongForSearch
- my $maxTopicsInSet = 512; # max number of topics for a grep call
+ my $maxTopicsInSet = 400; # max number of topics for a grep call
my @take = @$topics;
my @set = splice( @take, 0, $maxTopicsInSet );
my $sandbox = $this->{session}->{sandbox};
...then the error moves away.
This of course is related to my somewhat lengthy path for DEVELOP (it does
not
happen on my "productive" TWiki at
/home/haj/public_html/TWiki
), and may be
related to my test platform (cygwin).
The only problem I am seeing here is the silent failure: The error is thrown by the
forked child process, which apparently (again a cygwin artefact?) does not lead to a failure
of the parent process. A user doesn't see that there may be some hits missing.
Since ISP installations of TWiki can have pretty long installation paths, I'd like this
to be checked on some other platforms - if the typical ISP platforms (Linux, BSD)
can live with oversize argument list, this item can probably be discarded.
--
TWiki:Main.HaraldJoerg
This doesn't appear on any other platform because they use the safe pipes method of command invocation, so parameters are passed in an array and the shell command buffer is never involved. I guess it's going to be a problem on any system that has to fall back to emulated, or even no, safe pipes. it's really hard to think of a solution; the compromise is: shorter command lines -> more commands -> slower, versus truncated command lines on some platforms. I think we just have to accept this as a problem with any platform that uses the shell.
Discarding.
CC