Make run-tests.sh find PHP on Windows & Linux

See: #335122: Test clean HEAD after every commit and http://pastebin.ca/1258476

The script used to work without --php for me then the auto-detect was added and it messed it up. I checked it out and $_SERVER contains SUDO_COMMAND, not $_ENV so I added a case for that, although it can also be in ENV.

Merged with previous patch and changed title.

Mmmm....

There are quite a few bugs in 'run-tests.sh' related to its "shell interaction".

I prepared a patch yesterday, to make it work on Unix-like systems, but it's only now that I see you too have been investing some efforts in this (My fault, I'm mostly off-line and not aware of what's going on here...).

I don't want to extend this patch's scope (it will cause delay in committing it), so I'll wait till it gets in and then I'll open a new issue. (Unless the maintainer (boombatower?) instructs me otherwise.)

I checked it out and $_SERVER contains SUDO_COMMAND, not $_ENV so I added a case for that, although it can also be in ENV.

Could you please investigate this issue? Is your $_ENV empty?

I consider this to be a bug, also make it clear this should get in. No reasons why I should have to specify my php location when it is in standard location, run path, etc.

As for #9:
My $_ENV is empty and $_SERVER is loaded.

I don't want to extend this patch's scope (it will cause delay in committing it), so I'll wait till it gets in and then I'll open a new issue.

On the other hand, this issue purports to deal with Linux too, so it seems I'm on-topic in pointing out further bugs in this "Make run-tests.sh find PHP" mechanism (and escpecially since boombatower touches this same code in his patch):

1. When the script is run directly as an executable (./run-tests.sh, or ./script/run-test.sh), the code for figuring out the location of the PHP interpreter fails. No indication to error is given and to the user it seems that everything runs fine.

   To fix this, code of the form elseif (!empty($_ENV['_'])) sould be changed to elseif (!empty($_ENV['_']) && (strstr($_ENV['_'], $args['script']) === FALSE)). Ditto for list($php, ) = explode(' ', $_ENV['SUDO_COMMAND'], 2).

   Alternatively, we shouldn't give the false impression direct execution is possible.

2. A "shebang" line is missing. What's the point in giving the script a ".sh" extension, and shipping it with the executable bit set, and having the help text say "Usage: run-tests.sh [OPTIONS] {tests}", if this setup doesn't work?
3. This:

   $command = "$php ./scripts/{$args['script']} --url {$args['url']}";

   should be changed to:

   $command = "$php ./scripts/{$args['script']} --url " . escapeshellarg($args['url']);

   Or else, when not explicitly providing a --url parameter, mysterious things happen because the starved `--url' eats up the next word (which happens to be '--php', so this bug is on-topic here).

4. The help text insinuates you should run this script "from the root directory of your Drupal installation", but this isn't necessary because the script does chdir() to there. (This is also on-topic here, because this misleading data serves as red herring to the administratior who is going to investigate the `--php' issue when the script borks on him).
5. The ", or root" should be removed from the help text.

BTW, what's wrong with the following solution?

To completely remove the auto-detecting stuff. $php will be set by default to 'php'. If the user wants some other interpreter (or, if the php interpreter isn't in $PATH), she'll specify it explicitly with "--php /path/to/some/other/php".

That's how it was...I much prefer that as anyone with a normal config will be able to just use "php". For the life of me I have no idea why it was changed.

BTW, what's wrong with the following solution?

To completely remove the auto-detecting stuff.

I found the issue that introduced this auto-detecting feature and I see people want it, so removing it isn't an option.

Most of my negative feelings towards run-tests.sh stem from trying to execute it directly (e.g. ./run-tests.sh), but I see that it was never meant to be invoked this way. I'll later open a new issue to address this "documentation" problem.

So I'm reverting the status to what it was before I came here: "reviewed & tested by the community".

I wouldn't mind to remove the auto-detect feature. Maybe we can use an environment variable that people can set if they are sick and tired of specifying --php. That is how Java does it. People can either specify the classpath or set $CLASSPATH.

The main problem with auto-detect...is (at the moment) it breaks on more peoples machines then without. So either "fix" with patch, or I think #15 is best.

Maybe we can use an environment variable that people can set if they are sick and tired of specifying --php.

I was thinking about a variable that could contain any option, e.g. $ export RUNTESTS_OPTS='--color --php /path/to/php', but tokenizing this string isn't very easy because /path/to/php may contain spaces.

So here's a version that uses .ini file(s) instead.

(I'm marking this 'needs review' although I myself gave the code a very superficial check. sorry.)

#17: run-tests-remove-auto-detect.diff queued for re-testing.

Hi there,

I was struggling running the simpletests wit the run-test.sh script.
There are already several known issues. My patch should fix some of them.

Issues:
- Detecting php binary as described here: http://drupal.org/node/331580 this issue ;)
I've added a detection method for windows. But I'm sure it wont work for all environments

- Escaping command as described here: http://drupal.org/node/628498
I've fixed the escaping stuff - even spaces in path's are supported now. Most important part is to start the command with "cmd /C"

Enhancements:
- JUnit output file format - code from here: http://www.computerminds.co.uk/hudson-and-simpletest
I've ported the code to DP7 - and it runs with hudson like a charm :)

Feedback is highly welcome.

So long,
Peter

Trigger autotests

And another try - somewhere along the way it has to work :|
;)

More than a year later the story continuous :P
The only thing left of the patch seems to be the way how to find the php executable on windows. All the other stuff is fixed as fas as I can see after some smoke-tests.
Rerolled patch attached.

Just closed out a related issuse as a duplicate #628498: run-tests.sh: escape shell arguments and improve documentation.