Lars Torben Wilson wrote:
> Jeff Lacy writes:
> > It is a 'good' coding practice (with many people) to indent everything (that
> > should be indented, like if's). You can't do a doc quoting inside of an if
> > and still maintain 'good' coding practices. That is a bug, in my opinion,
> > because you ought to be able to do both perfectly. I understand why the
> > developers did what they did, but maybe a compromise could be reached? I
> > don't know what that would be, but maybe escaping any stop words before the
> > actual stop word with quotes or ticks or something.
Note that this is standard behaviour for here-docs. From "Programming
The terminating string must appear by itself (unquoted and with
no surrounding whitespace) on the terminating line.
>From man csh (on Solaris):
Read the standard input, up to a line that is identi-
cal with word, and place the resulting lines ...
However the bourne shell and bash have an extended version that does allow
indenting of code. From man bash:
If the redirection operator is <<-, then all leading tab
characters are stripped from input lines and the line con-
taining delimiter. This allows here-documents within shell
scripts to be indented in a natural fashion.
and man sh (Solaris):
After parameter and command substitution is done on
word, the shell input is read up to the first line
that literally matches the resulting word, or to an
EOF. If, however, - is appended to <<:
1) leading tabs are stripped from word before the shell
input is read (but after parameter and command substi-
tution is done on word),
2) leading tabs are stripped from the shell input as it
is read and before each line is compared with word,
3) shell input is read up to the first line that
literally matches the resulting word, or to an EOF.
Every great idea appears crazy to start with.
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]