PHP globstar?

Hello,

I have no idea if this is a bug or typo or neither, but with Xerte 3.3 (and our 3.0) I noticed that both 'config.php' and 'plugins.php' use the PHP 'glob' function with pathnames that contain '**'. For example. in (v3.3) config.php at line 180 it says:

I'm assuming that, like the Bash 'globstar' option, the '**' will be treated as '*', but is this a typo?



John.

Hi John,

As far as I am aware, ** in glob() pattern is used to cross directory boundaries... What this means in the example above is that since we have 3 different types of XOT templates, rather than do 3 globs and merge to match paths

(###### above can be either Nottingham, Rss, multipersp, mediaInteractions sub template types)

you can simply use

and it will find all current and future *.info files

John

Hi,

I was looking at the PHP manual for 'glob' [1] and could see no reference to '**' as being supported. Other users had written specific functions to perform the recursion, hence why I was asking why '**' was there instead of just '*' (since it seems that only one level of recursion is being used).

[1] [url=http://http://php.net/manual/en/function.glob.php] php.net/manual/en/function.glob.php [/url]

John.

If you look at the PHP manual you'll see the first line is

The glob() function searches for all the pathnames matching pattern according to the rules used by the libc glob() function

As far as I can see in the PHP glob page all the recursive examples are using /**/ or **/** to return something slightly more than what the built in functionality provides but for example you will see

being called and then looking at the glob_recursive function we have

where you see that the $pattern of $s."**/**" is being passed straight into glob() in the first statement

John

TBH i'd have to tip my hat to David Goodwin ( github.com/DavidGoodwin ) for coming up with that line...

github.com/thexerteproject/xerteonlineto...4ef9/config.php#L180

I would never have thought of doing that and would have done the slightly amateurish thing of multiple looping through the three different branches.

Every day is a school day...

John Smith schreef : If you look at the PHP manual you'll see the first line is

The glob() function searches for all the pathnames matching pattern according to the rules used by the libc glob() function

But, as far as I am aware, glibc doesn't support '**' natively.

As far as I can see in the PHP glob page all the recursive examples are using /**/ or **/** to return something slightly more than what the built in functionality provides but for example you will see

Code:

$ar=glob_recursive($s."**/**");

being called and then looking at the glob_recursive function we have

Code:

function glob_recursive($pattern, $flags = 0){ // forked from https://github.com/rodurma/PHP-Functions/ // blob/master/glob_recursive.php $files = glob($pattern, $flags); .....

where you see that the $pattern of $s."**/**" is being passed straight into glob() in the first statement

True, but you need to look further at the glob_recursive function and see that the next part then traverses recursively the directories. That first glob call (in effect) just gets any matching names at the top-level or 1 sub-directory down (depending on the pattern).

Looking at the xerte directory on our web server I can see that there are several '*.info' files (13 in all), some of which are several sub-directories down. Using a simple PHP script at the top-level:
this should return all of those files if '**' recurses the sub-directories. The output though is blank. I suspect because PHP (probably like glibc) is treating '**' as '*', and there are no '*.info' files present in any sub-directory one level down. If I change the pattern to as specified in the config file, then it shows most of the '*.info' files present. If I change this to I get the same output.
As far as I can tell '**' is not supported, and does not natively recurse directories. The code in config.php works because the required parts of the pathname are present in the pattern (i.e. 'modules/' and 'templates/').

Overall it's a minor point, and as far as I can see makes no difference to the xerte code.


John.