Re: Re: PHP 4.0 Bug #9387 Updated: Doc String Quoting Problem

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 Perl": The terminating string must appear by itself (unquoted and with no surrounding whitespace) on the terminating line. From man csh (on Solaris): <<word 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): <<[-]word 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, and 3) shell input is read up to the first line that literally matches the resulting word, or to an EOF. - Andrew -- Every great idea appears crazy to start with.