scovetta / yasca

Yet Another Source Code Analyzer
184 stars 61 forks source link

spl_autoload on case sensitive file systems #2

Open trustdarkness opened 10 years ago

trustdarkness commented 10 years ago

There appears to be a known issue that the php developers won't fix regarding spl_autoload on case sensitive filesystems:

https://bugs.php.net/bug.php?id=49625

This prevents yasca from working on linux. With some changing of cases in filenames and traditional imports, yasca works fine, but I'm not sure if you prefer a different solution. I've posted a tarball of my hacked up working version here:

http://trustdarkness.com/Downloads/yasca_linux_hack.tar.gz

if you'd like to see/test. I'd be happy to test this or other fixes on linux and/or start a fork for a version that works out of the box on linux and tracks changes in your main branch.

Its a great tool... kudos -- Also, you should know that most google searches for yasca pull up info and links to 2.x versions -- it would be great to see these updated.

ghost commented 10 years ago

Hi,

and thanks for posting this hack. Had the same problem running yasca 3.0 on a linux system.

431307092 commented 8 years ago

Hi,

While running this hack program, it prompts below errors.

Warning: Unsupported encoding [UTF-8] in /home/gxy/tools/yasca_linux_hack/yasca/plugins/pixy/plugin.php on line 2

Fatal error: Cannot access property Yasca\Plugins\BuiltIn\Deprecated\Threading\JAVA::$fileClasses in /home/gxy/tools/yasca_linux_hack/yasca/plugin.php on line 56

Would you please give me some suggestions?

Thanks..

trustdarkness commented 8 years ago

I'm trying to track this down, but I don't really know a ton about how the underlying code works. Would love to hear from scovetta about whether he's interested in supporting linux moving forward.

There seems to now be an issue where the private class member fileClasses in Plugin.php is not accessible to plugins that inherit from the class. I can make the fileClasses member public which makes that particular error go away, but then $filepath is empty once it gets inside getResultIterator in an instantiated plugin.

As an example: in getResultIterator called by Yasca/Plugins/BuiltIn/Bug/RedirectWithoutExit/ASP.php $filepath exists directly inside the call (the print statement prints what I expect), but not inside the callback function at the end:

DEBUG Selected Plugins Loaded ./Yasca/Core/DefaultIterator.phpDEBUG Checking file /startsurvey.asp ./Yasca/Core/Encoding.php./Yasca/Result.php./Yasca/Core/Options.phpIn ASP iterator: /home/mt/src/svn/XXX.asp ERROR Scan aborted

Fatal error: Uncaught exception 'ErrorException' with message 'Undefined variable: filepath' in /home/mt/src/git/yasca2/Yasca/Plugins/BuiltIn/Bug/RedirectWithoutExit/ASP.php:25

public function getResultIterator($fileContents, $filepath){
    print("In ASP iterator: ".$filepath);
    return (new \Yasca\Core\IteratorBuilder)
    ->from($fileContents)
    ->whereRegex('`\bResponse\.Redirect\s*\(`iu')
    ->where(static function($u, $key) use ($fileContents){
            return (new \Yasca\Core\IteratorBuilder)
            ->from($fileContents)
            ->slice($key, 2)
            ->whereRegex('`\bResponse\.End\s*\(`iu')
            ->any() !== true;
        })
        ->select(function($current, $key){
            return $this->newResult()->setOptions([
                    'lineNumber' => $key + 1,
                    'filename' => "$filepath",
            ]);
        });
}

}