trailing whitespace after ?> in php files

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

trailing whitespace after ?> in php files

Nick Lo
I'm a Vim convert of a few months now so I'm still in the getting it
together stage. One of the things that I've not even been able to
Google successfully is a solution to stopping whitespace after the
final ?> in PHP files.

PHP programmers will know any such space can result in "headers already
sent" errors. In Vim I can be looking at a file that looks like:

...blah php code
}
?>
~
~
~
~

but when opened in another text editor (in this case often SubEthaEdit)
there is clearly an extra line after the ?>.

My current workflow is having to include opening files in SubEthaEdit
and deleting this extra line before uploading to the hosting server and
I'd obviously like to not have to do so.

In my previous text editor (jEdit) I had a setting that stripped
trailing whitespaces on saving so I'm wondering if there is any such
setting for Vim.

I'm using version 6.3 (precompiled for Mac OS X 10.2)

Thanks,

Nick

Reply | Threaded
Open this post in threaded view
|

Re: trailing whitespace after ?> in php files

A.J.Mechelynck
----- Original Message -----
From: "Nick Lo" <[hidden email]>
To: <[hidden email]>
Sent: Wednesday, September 21, 2005 5:51 AM
Subject: trailing whitespace after ?> in php files


> I'm a Vim convert of a few months now so I'm still in the getting it
> together stage. One of the things that I've not even been able to Google
> successfully is a solution to stopping whitespace after the final ?> in
> PHP files.
>
> PHP programmers will know any such space can result in "headers already
> sent" errors. In Vim I can be looking at a file that looks like:
>
> ...blah php code
> }
> ?>
> ~
> ~
> ~
> ~
>
> but when opened in another text editor (in this case often SubEthaEdit)
> there is clearly an extra line after the ?>.
>
> My current workflow is having to include opening files in SubEthaEdit and
> deleting this extra line before uploading to the hosting server and I'd
> obviously like to not have to do so.
>
> In my previous text editor (jEdit) I had a setting that stripped trailing
> whitespaces on saving so I'm wondering if there is any such setting for
> Vim.
>
> I'm using version 6.3 (precompiled for Mac OS X 10.2)
>
> Thanks,
>
> Nick

If another editor shows an extra line, it may be that that other editor is
adding an extra empty line after _everything_ just to cater to the fact that
some misbehaving editors would routinely forget to end the last line of
their text with a proper end-of-line. Vim is a "well-behaved" editor, and
when editing text it outputs an end-of-line after every line, even the last
one. This prevents, among other things, running the last line line of one
file into the first line of the next one when files are concatenated.

It _is_ possible to write files without a proper EOL on the last line with
Vim, but that is not considered "proper" behaviour; it can lead to problems
in some cases. Use it at your own risk; the trick is to set 'binary' ON and
'eol' OFF.

To check for whitespace characters between the last "visible" character on a
line and the end of that line, you may set 'list' on (which will show the
end-of-line as a blue $ by default; you may set it to something else, e.g.,
to set it to the Pilcrow mark, use

    set list listchars=tab:\ \ ,eol:?

To remove any end-of-line whitespace, use the following substitution:

    :1,$s/\s*$//

:1,$        from first to last line
    s/        substitute
    \s*       zero or more whitespace characters
                (as many as possible)
    $        followed by an end-of-line
    //        by nothing


Best regards,
Tony.


Reply | Threaded
Open this post in threaded view
|

Re: trailing whitespace after ?> in php files

Nick Lo
Hi Tony,

> If another editor shows an extra line, it may be that that other
> editor is adding an extra empty line after _everything_ just to cater
> to the fact that some misbehaving editors would routinely forget to
> end the last line of their text with a proper end-of-line. Vim is a
> "well-behaved" editor, and when editing text it outputs an end-of-line
> after every line, even the last one. This prevents, among other
> things, running the last line line of one file into the first line of
> the next one when files are concatenated.

Actually, I "discovered" it after having ftp'd files (via the ftp
application Transmit) and getting the "headers already sent" errors on
calling the files. I only started having to recruit another text editor
in to actually see the trailing whitespace and delete it.

I'm actually editing a file right now in Vim that looks like

330 ?>
~
~
~

...but if I open it in SubEthaEdit, BBEdit Lite (and even OS X's own
TextEdit) it shows:

330 ?>
331

...deleting that extra line (331) is what I'm having to do each time.

In fact just as a test I deleted the line in BBEdit Lite then reopened
the file: no extra line. Then I opened it in Vim and changing nothing I
saved it again. I then reopened the file in BBEdit Lite and the extra
line is back so it seems to be being "added" when I :w from Vim.

Thanks,

Nick

Reply | Threaded
Open this post in threaded view
|

Re: trailing whitespace after ?> in php files

A.J.Mechelynck
----- Original Message -----
From: "Nick Lo" <[hidden email]>
To: <[hidden email]>
Sent: Wednesday, September 21, 2005 8:05 AM
Subject: Re: trailing whitespace after ?> in php files


> Hi Tony,
>
>> If another editor shows an extra line, it may be that that other editor
>> is adding an extra empty line after _everything_ just to cater to the
>> fact that some misbehaving editors would routinely forget to end the last
>> line of their text with a proper end-of-line. Vim is a "well-behaved"
>> editor, and when editing text it outputs an end-of-line after every line,
>> even the last one. This prevents, among other things, running the last
>> line line of one file into the first line of the next one when files are
>> concatenated.
>
> Actually, I "discovered" it after having ftp'd files (via the ftp
> application Transmit) and getting the "headers already sent" errors on
> calling the files. I only started having to recruit another text editor in
> to actually see the trailing whitespace and delete it.
>
> I'm actually editing a file right now in Vim that looks like
>
> 330 ?>
> ~
> ~
> ~
>
> ...but if I open it in SubEthaEdit, BBEdit Lite (and even OS X's own
> TextEdit) it shows:
>
> 330 ?>
> 331
>
> ...deleting that extra line (331) is what I'm having to do each time.
>
> In fact just as a test I deleted the line in BBEdit Lite then reopened the
> file: no extra line. Then I opened it in Vim and changing nothing I saved
> it again. I then reopened the file in BBEdit Lite and the extra line is
> back so it seems to be being "added" when I :w from Vim.
>
> Thanks,
>
> Nick

Well, you may try the trick which I mentioned in the part you snipped
(":setlocal binary noeol") but if I were you I would not do it
indiscriminately for every file, only for those meant for those braindead
applications which will choke on properly-ended files.

Best regards,
Tony.


Reply | Threaded
Open this post in threaded view
|

Re: trailing whitespace after ?> in php files

Nick Lo
Hi Tony,

> Well, you may try the trick which I mentioned in the part you snipped
> (":setlocal binary noeol") but if I were you I would not do it
> indiscriminately for every file, only for those meant for those
> braindead applications which will choke on properly-ended files.

Putting that setting in a php.vim file in .vim/ftplugin seems to set it
fine for php files so thanks for the advice. Incidentally what type of
issues would indiscriminate use produce?

Thanks,

Nick

Reply | Threaded
Open this post in threaded view
|

Re: trailing whitespace after ?> in php files

A.J.Mechelynck
----- Original Message -----
From: "Nick Lo" <[hidden email]>
To: <[hidden email]>
Sent: Wednesday, September 21, 2005 11:50 AM
Subject: Re: trailing whitespace after ?> in php files


> Hi Tony,
>
>> Well, you may try the trick which I mentioned in the part you snipped
>> (":setlocal binary noeol") but if I were you I would not do it
>> indiscriminately for every file, only for those meant for those braindead
>> applications which will choke on properly-ended files.
>
> Putting that setting in a php.vim file in .vim/ftplugin seems to set it
> fine for php files so thanks for the advice. Incidentally what type of
> issues would indiscriminate use produce?
>
> Thanks,
>
> Nick

The example that comes to mind first is, when using

(Unix/Linux)
    cat file1 file2 > file3

or (Dos/Windows)
    copy file1+file2 file3

if the last line of file1 has no end-of-line, it might become a single line
with the first line of file2.

Similarly for an include file in a program: the last line of the include
file, if it lacks an end-of-line, might be run in with the next line in the
program, unless the compiler or interpreter takes special care to add an
additional end-of-line at the end of the included file.

In general, in a text file, "one line" is normally defined as optional text,
followed by exactly one end-of-line sequence. The end-of-line sequence is
normally 0x0A (line feed) on Unix, 0x0C (carriage return) on Mac, 0x0C 0x0A
(CR+LF) on Dos/Windows. Vim or WordPad, but not Notepad, will also accept LF
alone as an end-of-line on Windows. Since binary files are usually not
organised in lines, Vim takes extra care to keep a binary file unchanged
even if it doesn't end with an end-of-line.

Best regards,
Tony.


Reply | Threaded
Open this post in threaded view
|

Re: trailing whitespace after ?> in php files

Gareth Oakes-2
Hi,

 >> Putting that setting in a php.vim file in .vim/ftplugin seems to set
 >> it fine for php files so thanks for the advice. Incidentally what type
 >> of issues would indiscriminate use produce?
[..snip..]
 >
 > Similarly for an include file in a program: the last line of the
include
 > file, if it lacks an end-of-line, might be run in with the next line in
 > the program, unless the compiler or interpreter takes special care to
 > add an additional end-of-line at the end of the included file.

That's correct, we've had problems with some more exotic preprocessors
which won't "intelligently" glue the included file into the source file.
This can cause some very bizarre errors, eg.

FILE1:
#include "test.h"
void main() {
   printf("Boo!");
}

FILE2:
NO_END-OF-LINE_HERE

RESULT:
NO_END-OF-LINE_HEREvoid main() {
   printf("Boo!");
}

IMHO, ensuring the last line of a text file ends with a CR/LF character
sequence is polite and well-mannered behaviour.  OTOH, I can see the
case where you may want to suppress this behaviour with some sort of toggle.

-G
Reply | Threaded
Open this post in threaded view
|

Re: trailing whitespace after ?> in php files

Paul-433
In reply to this post by A.J.Mechelynck
I keep meaning to write a bit about the growing practise of not including EOL
at the end of a line and why newer editors behave this way, but Tony has done a
good job of explaining the 'proper' format of a text file. I was going to ask
comp.editors as well.

I want to know why these editors do this. They seem to treat the return/enter
key as 'insert EOL and take me to the next line' instead of 'take me to the
next line' and letting the editor handle the insertion of the EOL. Instead,
they only put EOLs in the file when and only when return/enter is pressed.
There is no ASCII code for EOL - how would a keyboard know whether to send a
code for \n or \r\n? It is up to the editor to insert the system's EOL
characters.

Because of this, they also display lines incorrectly. I have noticed it with
the editors in ZDE, Eclipse, and Scite. It only serves to create confusion when
they misinterpret an EOL as 'start a new line', and actually start to display
another line as if it already existed. This is very visible if you create a
'proper' text file (you'll have to use a well-behaved text editor like vim for
this) and open it in one of the above editors. It will display an extra line
below the real last line of the file. You see something like this:

--- cut ---
1 first line
2 middle line
3 last line
4
--- cut ---

There are actually three lines in the text file and you can confirm this with
'wc -l <file>'.

There is a lot of confusion with people who don't understand the concept of EOL
and what these editors are doing. For example, I have people at work who use
ZDE and when they open a text file created by me (vim), they go bonkers because
they think I've put an extra blank line at the bottom of my scripts. There have
been problems in the past with people really putting unnecessary blank lines at
the bottom of scripts, and of course this lead to the premature headers errors.
Naturally, they think I'm doing the same, because they don't realise that their
editor is displaying the file incorrectly.

I have one especially annoying colleague who has even written into our 'coding
guidelines' recommending people not use vim because "it puts in extra
characters that you don't ask for".

There is a half-arsed compromise, though. Simply don't put the ?> tag at the
end of your PHP file. This is probably a good idea in multi-user environments
where you have other people writing scripts whom might not write a PHP file
properly. Personally, it's always in the back of my mind that "the script is
left open, I need closure" without that tag, even though I know it's safer
without it.

As a side note, the PHP parser takes into account any trailing EOL after a
closing tag, so whether there is one after it or not is irrelevant. The problem
is when there is more than one.

I have noticed that Redhat's default emacs configuration (FC3 at least) also
opens text files in binary mode by default, resulting in a missing EOL on the
last line of a newly created text file.

I'd like to know if I have the wrong idea about anything, but the question
remains: what is the reason for these editors behaving this way?

--

.
Reply | Threaded
Open this post in threaded view
|

OT: History of trailing CR/LF (Was: trailing whitespace after ?> in php files)

A.J.Mechelynck
----- Original Message -----
From: "Vigil" <[hidden email]>
To: "Vim Mailing List" <[hidden email]>
Sent: Wednesday, September 21, 2005 2:09 PM
Subject: Re: trailing whitespace after ?> in php files


>I keep meaning to write a bit about the growing practise of not including
>EOL at the end of a line and why newer editors behave this way, but Tony
>has done a good job of explaining the 'proper' format of a text file. I was
>going to ask comp.editors as well.
[...]

I'm not sure it's "newer" editors. Some Dos/Windows editors have done this
for as far as I can remember.

The origin of the ASCII control codes is with papertape and teletypewriters:
when sending a telex, I would prepare it by typing it and punching a 5-track
paper tape in the process, then establish the connection and run the paper
tape at max speed (a few characters per second).

At the end of each line, several keys (each generating one papertape
"frame") had to be pressed:

CR (carriage return) = move the print head back to the left margin
LF (line feed) = advance the paper by one line
DEL (rubout), three times = all ones, do nothing: used to punch over an
error, or (in this case) to allow the teletypewriter enough idle time to
move the printhead and paper to the start of the next line without
corrupting the (printed) message.

At the end of a message, a CR plus several LFs would move the printhead
"home" and eject the paper (those telex machines used continuous print rolls
with no head-of-form position so they didn't know about the FF -- form
feed -- used on later models to move the paper to the next shearing fold in
zig-zag paper).


When computers came around (I'm skipping several years here), they first
used teletypewriters as output devices, then screens whose basic way of
functioning was (and still is, at the "console" command line) that of a
"glass teletype". When _personal_ computers came around, then depending on
the way the shell was written, the prompt (%PROMPT% or $PS1) may be printed
with a starting CR/LF: if it wasn't, then a program whose last message
didn't end with a linefeed (or a 'cat' or TYPE of a file not ending in an
EOL) would have the prompt printed on the same line as the message, like
this:

This is a message with no backslash-nC:\PATH\TO\WHEREVER\>type test.txt
this is a two-line file; its last line
hasn't got an end-of-lineC:\PATH\TO\WHEREVER\>


Best regards,
Tony


Reply | Threaded
Open this post in threaded view
|

Re: trailing whitespace after ?> in php files

Matthew Winn
In reply to this post by Paul-433
On Wed, Sep 21, 2005 at 01:09:12PM +0100, Vigil wrote:
> I want to know why these editors do this. They seem to treat the
> return/enter key as 'insert EOL and take me to the next line' instead of
> 'take me to the next line' and letting the editor handle the insertion of
> the EOL. Instead, they only put EOLs in the file when and only when
> return/enter is pressed. There is no ASCII code for EOL - how would a
> keyboard know whether to send a code for \n or \r\n? It is up to the editor
> to insert the system's EOL characters.
[snip]
> I'd like to know if I have the wrong idea about anything, but the question
> remains: what is the reason for these editors behaving this way?

The problem is that they view end-of-line as a line separator, not a
line terminator, so they do the same sort of thing as they'd do with
commas in a line of comma-delimited data: they omit the last one.
That's not what the end-of-line character is for.  It's not just text
editors that make that mistake: some protocol standards documents
wrongly refer to lines being "separated" by newlines, yet reading the
grammar shows that they really mean "terminated".

Another example of a program that needs an end-of-line at the end of
every line of a file is Oracle's SQL*Plus.  If you try to execute a SQL
or PL/SQL script that doesn't have a newline on the end of the final
line then SQL*Plus will report that the final line has been truncated.
Seeing data with no terminating linefeed and getting an unexpected
end-of-file in the middle of a line, it assumes that there's been an
interruption in the data transmission and emits a warning.

--
Matthew Winn ([hidden email])