• Do not register here on develop.twiki.org, login with your twiki.org account.
• Use View topic Item7848 for generic doc work for TWiki-6.1.1. Use View topic Item7851 for doc work on extensions that are not part of a release. More... Close
• Anything you create or change in standard webs (Main, TWiki, Sandbox etc) will be automatically reverted on every SVN update.
Does this site look broken?. Use the LitterTray web for test cases.

Item3517: configure no longer warns against non-existing store settings

Item Form Data

AppliesTo: Component: Priority: CurrentState: WaitingFor: TargetRelease ReleasedIn
Engine   Normal Closed   patch 4.1.1

Edit Form Data

Summary:
Reported By:
Codebase:
Applies To:
Component:
Priority:
Current State:
Waiting For:
Target Release:
Released In:
 

Detail

After setting up a new instance of TWiki 4.1.0 on a server that I already had been successfully using 4.0, it seems that the Changes feature is having a problem.

If I load TWiki 4.1.0 and go into the Sandbox and make a few new topics, they do not show up on the Changes page.

Looking at the warn log, I see the following:

| 27 Jan 2007 - 11:38 | exec failed: Inappropriate ioctl for device at /home/httpd/domains/test.com/twiki/lib/TWiki/Sandbox.pm line 389.

| 27 Jan 2007 - 11:47 | exec failed: Inappropriate ioctl for device at /home/httpd/domains/test.com/twiki/lib/TWiki/Sandbox.pm line 389.

Entries occur whenever I click on the Changes link on the left sidebar. It also happens when I click on Groups.

I tested and this happens for all webs. I also tested on another server completely, and the same issue happened.

Any ideas? Seems like maybe there is a bug here.

-- TWiki:Main/JasonLuttgens - 27 Jan 2007

After throwing in some extra debugging code, it appears as though a failure is occurring on trying to execute "/bin/egrep". This binary does not exist on my system in that path (FreeBSD 6.1). It's in /usr/bin. Did something change between 4.0 and 4.1 as far as checking for the proper path on various binaries that are needed? My configure script does not show any errors.

-- JasonLuttgens - 27 Jan 2007

In 4.0.5 configure would indeed write a warning if a store setting did not point to a valid file.

In 4.1.0 this quite nice feature is gone.

It should be added again. It was a good feature.We had a similar bug report recently Item3465.

I have re-written the summary

-- KennethLavrsen - 27 Jan 2007

I can see that the feature is not removed. It is a simple bug.

/lib/TWiki/Configure/Checkers/EgrepCmd.pm is never run because it is expected to be in /lib/TWiki/Configure/Checkers/RCS

If you just move it there it fails.

-- KennethLavrsen - 28 Jan 2007

OK. I think the same issue exists for fgrep. Seems like thats the only other one.

-- JasonLuttgens - 28 Jan 2007

I am working on this one.

So far I have done this

  • Moved /lib/TWiki/Configure/Checkers/EgrepCmd.pm to /lib/TWiki/Configure/Checkers/RCS/EgrepCmd.pm
  • Change the package line in EgrepCmd.pm to package TWiki::Configure::Checkers::RCS::EgrepCmd;

Now the check is run and it finds the error when the path is to a non-existing program.

But it does not work correctly. I get a real error instead of just the warning in configure.

I have compared the code with the code in 4.0.5 and it all seems the same.

But the problem is in /lib/TWiki/Configure/Checker.pm

At line 153 we have

        my $diffOut = ( `$prog --version 2>&1` || "");
        my $notFound = ( $? == -1 );

Exact same code is in 4.0.5.

But the $? variable gets the value -1 in 4.0.5 and 512 in 4.1.0 ???

And this is why the next code lines fail. Hint needed.

-- KennethLavrsen - 28 Jan 2007

I have been reading up on this. It seems that $? is not always -1 when backtick program is not found. If some process comes in between, and this probably happens now that configure is much more object oriented, the value becomes a composite value. But one thing is for sure. When it succeeds the value is 0. So we just check for non-zero and assume that if it finds a program called egrep this program does not exit with an error. It may be a wrong version of egrep which the next code lines in Checker will try and find.

I am checking in a fix.

-- KennethLavrsen - 28 Jan 2007

Interestingly, if you extract the lines in question from Checker.pm (153 and forward) into a separate Perl script, and replace the code in the branches with something that will work external to TWiki, the code seems to work as expected (no crazy return codes, etc.). I am not sure why this would happen. Possibly a Perl setting somewhere else that we don't see?

-- JasonLuttgens - 28 Jan 2007

Done. Also merged to Patch04x01 for 4.1.1 release

-- KennethLavrsen - 28 Jan 2007

Jason. I did exactly the same. In a small program the return code is -1 and same in the ONE FILE configure we had in 4.0.X. But in 4.1.0 configure has been made modular and OO. And then the difference is probably in the way the backtick gets forked out in practical.

According to the perl docs the $? is composed of the returned error code in the upper 8 bits and the process id in the lower plus some extra bits stuffed in. And I guess these lower bits get set when you are inside a deep object stack. In any case. I think what I just checked in works.

  • Changed tools MANIFEST so the build process works.
  • Changed the code line 153 in /lib/TWiki/Configure/Checker.pm to my $notFound = ( $? != 0 );
  • Moved /lib/TWiki/Configure/Checkers/EgrepCmd.pm to /lib/TWiki/Configure/Checkers/RCS/EgrepCmd.pm
  • Moved /lib/TWiki/Configure/Checkers/FgrepCmd.pm to /lib/TWiki/Configure/Checkers/RCS/FgrepCmd.pm
  • Changed the package line in EgrepCmd.pm to package TWiki::Configure::Checkers::RCS::EgrepCmd;
  • Changed the package line in FgrepCmd.pm to package TWiki::Configure::Checkers::RCS::FgrepCmd;

So it should work and warn well now.

-- KennethLavrsen - 28 Jan 2007

Ok, sounds good. Thanks Ken.

-- JasonLuttgens - 28 Jan 2007

ItemTemplate
Summary configure no longer warns against non-existing store settings
ReportedBy TWiki:Main.JasonLuttgens
Codebase 4.1.0
SVN Range TWiki-4.1.0, Mon, 22 Jan 2007, build 12595
AppliesTo Engine
Component

Priority Normal
CurrentState Closed
WaitingFor

Checkins 12640 12641
TargetRelease patch
ReleasedIn 4.1.1
Edit | Attach | Watch | Print version | History: r15 < r14 < r13 < r12 < r11 | Backlinks | Raw View |  Raw edit | More topic actions
Topic revision: r15 - 2007-02-05 - JasonHill
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback