(ok 2.11) Stray space in Config.class.php

Logged In: YES
user_id=210714
Originator: NO

I tried phpMyAdmin-2.10.0.2-all-languages.zip. Downloaded to a XP station, used PowerArchiver 6.0.5 to extract, I can see the blank line.

With 7-zip 4.42 on the same Windows machine, same problem

I used the same zip file, downloaded to a Linux station, used unzip and I don't see the blank line!

In all cases, the file as examined by a dump utility, ends with
? > \n

How did you extract the file?

Logged In: YES
user_id=326580
Originator: NO

a blank line at the end is in every file

mixed line endings?

i have no clue

do you have output buffering enabled or disabled?

i have downloaded phpMyAdmin-2.10.0.2-all-languages.zip, extracted Win XP (ZIP-Folder) - cannot see any suspicious:

--
?>

--
0A 3F 3E 0A
--

Logged In: YES
user_id=1383652
Originator: NO

in QA_2_10svn the file ends with
--
0A 3F 3E 0D 0A
--
i always thought that php doesn't care, no?

Logged In: YES
user_id=210714
Originator: NO

This is weird, because when seen on my Linux system, QA_2_10/phpMyAdmin/libraries/Config.class.php only ends with 0A, no 0D there!

Logged In: YES
user_id=1742017
Originator: YES

I extracted it using the native Windows Zip viewer built into explorer. Viewing the original, unmodified file, it does indeed end with 0A. Removing the 0A solved the problem.

Here are some details on the my version of Windows and PHP from phpinfo()

Windows NT SERVER143 5.2 build 3790
Build Date Jul 31 2006 23:20:48
Server API ISAPI
Virtual Directory Support enabled
Configuration File (php.ini) Path C:\WINNT\php.ini
PHP API 20020918
PHP Extension 20020429
Zend Extension 20050606
Debug Build no

I'm sure I have output buffering disabled as that is the default state and I haven't modified it. Buffering would probably solve the problem as well, but it seems the cleaner fix is removing the stray char from the config file.

Looking at phpinfo again..
output_buffering no value no value
output_handler no value no value
I usually only buffer the output on a script by script basis when I'm outputting PDFs or some other mimetype that requires monkeying with the headers or when the output takes a while to process.

Logged In: YES
user_id=1383652
Originator: NO

there are three files in my QA_2_10svn/libraries/ folder
with the modification date of 2007-03-03 :

/* $Id: config.default.php 10040 2007-03-01 15:36:20Z lem9 $ */
/* $Id: Config.class.php 10033 2007-02-28 02:03:15Z lem9 $ */
/* $Id: common.lib.php 10050 2007-03-02 16:07:54Z cybot_tm $ */

all with 0D 0A as linefeeds (not only at the file end) - working very well (at least on my w2k box :-)

but there is *no* trailing empty line in Config.class.php.

----
btw.,
i remember some users in the forum reporting that just switching to a different
downloadfile (i.e from english to all-lang) fixed their problems.

Logged In: YES
user_id=326580
Originator: NO

can you test if this happens with a newer PHP Version too?

by default *one* empty line after ?> does not cause this problem - as we have an empty line in every file

Logged In: YES
user_id=210714
Originator: NO

Besides, I don't know how to remove this 0A using vim!

Logged In: YES
user_id=326580
Originator: NO

@windkiel: your file ends with '0A 3F 3E 0D 0A' ?

cannot confirm

how do you checkout?
how do you display this hex code?

probably your tools do some line ending conversion?

Logged In: YES
user_id=326580
Originator: NO

just a note: line endings depend on the system which does the checkout, so testing with checkout will not help, only testing with file from download

http://svnbook.red-bean.com/en/1.1/ch07s02.html#svn-ch-7-sect-2.3.5

Logged In: YES
user_id=1383652
Originator: NO

@Sebastian:
>your file ends with '0A 3F 3E 0D 0A' ?
indeed, i get the files using "tortoise-svn" and never touch them afterwards
(except using xcopy /M the files to my test bench)
i examined them with a hexeditor (read only mode).

but this was only for the record - php is happy with both versions
(at least here ;)

Logged In: YES
user_id=210714
Originator: NO

I think the best we can do with this is add a FAQ entry.

Logged In: YES
user_id=326580
Originator: NO

isn't there already something about 'cannot send header'?

Logged In: YES
user_id=210714
Originator: NO

Could be FAQ 1.4 but it's for CGI, not ISAPI as this reporter tells us.

Of course, there is the general FAQ 2.1, maybe we could add something about Config.class.php (if we can reproduce)

Logged In: YES
user_id=210714
Originator: NO

FAQ 2.1 modified.