heredoc and array problems

[Jeff]

I have this:

$content = <<<TD

$D['section']

TD;

that fails silently and stops php even though errors are turned on

This works:

$content = <<<TD

{$D['section']}

TD;

Now, I just stumbled on that "fix" and it took me a loooong time to
figure out where the problems laid.

What's going on here?

This isn't much help:

http://us3.php.net/manual/en/languag...syntax.heredoc

Jeff

[Michael Fesser]

..oO(Jeff)

>I have this:

$content = <<<TD

$D['section']

TD;

that fails silently and stops php even though errors are turned on

Is display_errors turned on in your php.ini? The above will cause a
parse error. If you use ini_set() to enable display_errors, you won't
see any error message, because the script is not executed.

Micha

[macca]

You need to look up Interpolation.

Heredoc follows similar interpolation capabilities as echoing with
double quotes.

When you echo an array variable such as $D['section'] in SINGLE QUOTES
you need to concatenate it as single quotes means a string literal
like so:

echo 'I have to escape '.$D['section'].' to output correctly';

When you echo an array variable such as $D['section'] in DOUBLE QUOTES
you do not need to concatenate the array variable (although you can if
you wish) as double quoted strings are INTERPOLATED (or converted)
prior to being written to output.

However, to include an array variable inside an interpolated (double
quoted) string you would leave out the single quotes (which is
perfectly legal syntax) like so:

echo "I don't have to escape $D[section] to output correctly but don't
need the single quotes either!";

The same is true for HEREDOC.

Thus:

$D['section'] = "hello";

echo $content = <<<TD

$D[section]

TD;

would print "hello".

Using curly braces {} is more for outputting variables where the
continuation of the string would make it difficult to interpolate it
properly such as part of a word. Basicly curly braces say: {this is a
variable}

e.g.

$var = 'Talk';

echo "I am $varing";

would not work because $varing is not a defined variable.

echo "I am {$var}ing";

would output "I am Talking";
Hope this helps. :-)

[Jeff]

Michael Fesser wrote:

.oO(Jeff)

>I have this:

$content = <<<TD

$D['section']

TD;

that fails silently and stops php even though errors are turned on

Is display_errors turned on in your php.ini?

I have this at the script top:

ini_set('display_errors','1');
ini_set('display_startup_errors','1');
error_reporting (E_ALL);

Jeff

The above will cause a

parse error. If you use ini_set() to enable display_errors, you won't
see any error message, because the script is not executed.

Micha

[Jeff]

macca wrote:

You need to look up Interpolation.

Heredoc follows similar interpolation capabilities as echoing with
double quotes.

When you echo an array variable such as $D['section'] in SINGLE QUOTES
you need to concatenate it as single quotes means a string literal
like so:

echo 'I have to escape '.$D['section'].' to output correctly';

When you echo an array variable such as $D['section'] in DOUBLE QUOTES
you do not need to concatenate the array variable (although you can if
you wish) as double quoted strings are INTERPOLATED (or converted)
prior to being written to output.

OK, I understand that now. Perls heredocs don't do that.

>
However, to include an array variable inside an interpolated (double
quoted) string you would leave out the single quotes (which is
perfectly legal syntax) like so:

echo "I don't have to escape $D[section] to output correctly but don't
need the single quotes either!";

I see that if I do this:

$D[section] = 'some_var';

I get this:
Use of undefined constant section - assumed 'section' in..

So the implied interpolation works only (without notice) inside strings.

Which is a shame as it looks like perl to me without the quotes!

>
The same is true for HEREDOC.

Thus:

$D['section'] = "hello";

echo $content = <<<TD

$D[section]

TD;

would print "hello".

Thanks, I've got it under control now!

Jeff

>
Using curly braces {} is more for outputting variables where the
continuation of the string would make it difficult to interpolate it
properly such as part of a word. Basicly curly braces say: {this is a
variable}

e.g.

$var = 'Talk';

echo "I am $varing";

would not work because $varing is not a defined variable.

echo "I am {$var}ing";

would output "I am Talking";
Hope this helps. :-)

[Jerry Stuckle]

Jeff wrote:

Michael Fesser wrote:

>.oO(Jeff)

>>I have this:

$content = <<<TD

$D['section']

TD;

that fails silently and stops php even though errors are turned on

Is display_errors turned on in your php.ini?

I have this at the script top:

ini_set('display_errors','1');
ini_set('display_startup_errors','1');
error_reporting (E_ALL);

Jeff

The above will cause a

>parse error. If you use ini_set() to enable display_errors, you won't
see any error message, because the script is not executed.

Micha

As Micha said - it needs to be in your php.ini file (or .htaccess), NOT
IN YOUR SCRIPT.

When you have a syntax error, NOTHING in the script - including the
ini_set(), is executed.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Jeff]

Jerry Stuckle wrote:

Jeff wrote:

>Michael Fesser wrote:

>>.oO(Jeff)

I have this:

$content = <<<TD

$D['section']

TD;

that fails silently and stops php even though errors are turned on

Is display_errors turned on in your php.ini?

I have this at the script top:

ini_set('display_errors','1');
ini_set('display_startup_errors','1');
error_reporting (E_ALL);

Jeff

The above will cause a

>>parse error. If you use ini_set() to enable display_errors, you won't
see any error message, because the script is not executed.

Micha

As Micha said - it needs to be in your php.ini file (or .htaccess), NOT
IN YOUR SCRIPT.

Hmm, this seems awkward to me as wouldn't it then turn on error
reporting in all scripts? Or should I just set: display_startup_errors
to true in php.ini?

I haven't dug out php.ini yet, I see there seems to be two copies
somewhere off /etc, I believe. One is a backup?

How does the .htaccess bit work?

>
When you have a syntax error, NOTHING in the script - including the
ini_set(), is executed.

Well, I believe I accidentally found a way around this without knowing
what I was doing:

<?php

ini_set('display_startup_errors','1');

include 'script_to_test.php';

?>

I tend to keep my core code in a separate file anyways and the calling
page is just a shell with a few customizations. That's my style
anyways... I didn't do that in the problem case though!

Jeff

>

[Michael Fesser]

..oO(Jeff)

>Jerry Stuckle wrote:

>>
As Micha said - it needs to be in your php.ini file (or .htaccess), NOT
IN YOUR SCRIPT.

Hmm, this seems awkward to me as wouldn't it then turn on error
reporting in all scripts?

Correct. On a development machine that's how it's supposed to be. Of
course on a production servers errors should never be shown, but written
to a logfile instead, because they might contain sensitive informations
which you surely don't want to see in the hands of a malicious user.

>Or should I just set: display_startup_errors
to true in php.ini?

Enable all errors and set error_reporting to its highest level.

I haven't dug out php.ini yet, I see there seems to be two copies
somewhere off /etc, I believe. One is a backup?

Check phpinfo() which ini file is in use.

It might also depend on which PHP version you installed and on which
platform. By default the installer comes with multiple different ini
files (three IIRC), but if for example you compile your own PHP from the
sources, you might end up with another ini file in a totally different
location (this happens here on my Debian/Linux box for example).

>How does the .htaccess bit work?

If PHP is installed as a server module, you can use some directives in
an .htaccess file to control various PHP settings. See the manual for
details.

http://www.php.net/manual/en/configuration.changes.php

>When you have a syntax error, NOTHING in the script - including the
ini_set(), is executed.

Well, I believe I accidentally found a way around this without knowing
what I was doing:

<?php

ini_set('display_startup_errors','1');

include 'script_to_test.php';

?>

This works indeed, because the first script is parsed and executed
correctly. The parse error happens in the include file, which will then
kill the interpreter.

>I tend to keep my core code in a separate file anyways and the calling
page is just a shell with a few customizations. That's my style
anyways...

With some more testing scenarios and stricter rules this would be called
a "unit test".

Micha