Dominik Vogt wrote:
> On Wed, Apr 17, 2002 at 07:29:25PM -0600, Gregg Dameron wrote:
> > Running 2.4.5 on Solaris.
> >
> > It seems that as a PipeRead script increases in size, fvwm2 struggles to
> > read and execute it. The maximum seems to be 1024 bytes, measured by
> > the string output in debug mode that begins:
> >
> > <<DEBUG>> about to attempt '<script here>'.
> >
> > Larger than that, and things get strange. Reading in the file
> > containing the PipeRead may give an error such as:
> >
> > <<DEBUG>> Module switch -1, about to exec: '<truncated PipeRead script>'
> >
> > <<DEBUG>> Module switch -1, about to exec: '<characters after truncation
> > point>'
> > <<ERROR>> No such command '<characters after truncation point>'
> >
> > Or, at runtime, Bourne may report an unexpected end-of-file, or other
> > syntax error, where none exists.
> >
> > I haven't studied the source code in detail, but in read.c, I see:
> >
> > char line[1024];
> >
> > More than a coincidence?
>
> In fvwm, a single command line can not be longer than 1022
> characters (1024 minus 1 for the string end minus 1 for the
> trailing newline).
>
> > I suppose one workaround is to Exec a separate script and FvwmCommand
> > the output, but I'm anxious to optimize performance.
>
> No, the limit is everywhere, not just in piperead. If that's too
> small, the limit can be increased, but I wonder how you manage to
> generate single commands that are bigger than 1k.
I would vote in favor of an increase. It's easy for a PipeRead script to
grow quickly, when you consider Bourne looping and branching constructs (for,
if, case), all of which count toward the limit. There's a PipeRead in the
distribution (system.fvwm2rc-sample-95) that exceeds 500 bytes before
parameter expansion. The "for i in ... ; do" statement alone is over 230
bytes. Once I saw that sample, I jumped to the conclusion that arbitrarily
long PipeReads were not only supported, but tacitly recommended.
Admittedly, a contributing factor is my coding style - I prefer longer shell
variable names and newlines with indentation, all of which count toward the
limit (and certainly can be trimmed).
Perhaps the size limit should be mentioned in the man page (or did I miss
it?).
> > Any help is
> > appreciated. I guess my preference would be dynamic memory allocation
> > supporting arbitrarily large PipeReads.
> >
> > BTW, I noticed that the "about to exec" debug messages chop off the last
> > character of the line read in. In read.c:
> >
> > if (debugging)
> > fvwm_msg(DBG,"ReadSubFunc","Module switch %d, about to exec:
> > '%.*s'",
> > Module,strlen(tline)-1,tline);
> >
> > Perhaps the "-1" shouldn't be there?
>
> It's the trailing newline that gets cut off.
Hmm. Here's a sample of what I get:
[FVWM.1][ReadSubFunc]: <<DEBUG>> Module switch -1, about to exec:
'DestroyFunc ChangeAppsMa'
[FVWM.1][ReadSubFunc]: <<DEBUG>> Module switch -1, about to exec: 'AddToFunc
ChangeAppsMa'
[FVWM.1][ReadSubFunc]: <<DEBUG>> Module switch -1, about to exec: '+ I
KillModule FvwmTaskBa'
[FVWM.1][ReadSubFunc]: <<DEBUG>> Module switch -1, about to exec: '+ I
KillModule FvwmWinLis'
[FVWM.1][ReadSubFunc]: <<DEBUG>> Module switch -1, about to exec: '+ I
KillModule FvwmIconMa'
[FVWM.1][ReadSubFunc]: <<DEBUG>> Module switch -1, about to exec: '+ I
KillModule FvwmIconBo'
[FVWM.1][ReadSubFunc]: <<DEBUG>> Module switch -1, about to exec: '+ I Exec
echo "AddToFunc StartFunction I $0" > $FVWM_USERDIR/.start-apps-ma'
[FVWM.1][ReadSubFunc]: <<DEBUG>> Module switch -1, about to exec: '+ I $'
It doesn't happen this way on yours and others' systems?
As always, thank you for the quick response.
Gregg Dameron
--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majordomo_at_fvwm.org.
To report problems, send mail to fvwm-owner_at_fvwm.org.
Received on Thu Apr 18 2002 - 12:01:01 BST