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

Missed to add "/php.exe" to the auto-discovered path.

Tests also start to run this way - however, they seem to break after 17 secs.

Thanks to DamZ for pointing out this nonsense. ;)

The last submitted patch failed testing.

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

The last submitted patch failed testing.

Wasn't able to test this yet, because, somehow, my PDO extension vanished from my CLI, so... ugh.

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.

At least the Windows part is RTBC. It still doesn't properly run any tests, but at least it finds PHP and is able to list all tests. I can execute a test group, a single test class, or all tests, but everything is executed in 0.00 secs. My first reaction, of course, was: woah, awesome! How fast is that?! Then I found out that it's really too fast. :-D Though not sure, why.

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.)