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

• Ah, after reading the history of Item1699 I've found out that TWiki:Main.HaraldJoerg is the reporter. I've changed the text accordingly.

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