Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Gentoo User (http://www.linux-archive.org/gentoo-user/)
-   -   reading php file code in text editor (http://www.linux-archive.org/gentoo-user/389754-reading-php-file-code-text-editor.html)

Mick 06-23-2010 06:18 AM

reading php file code in text editor
 
I am looking at some php files which are causing parsing errors in Drupal, like:
=============================================
Warning: Unexpected character in input: ' in
/var/www/htdocs/sites/all/themes/fusion/fusion_core/template.php on
line 178
Warning: Unexpected character in input: ' in
/var/www/htdocs/sites/all/themes/fusion/fusion_core/template.php on
line 178
Warning: Unexpected character in input: ' in
/var/www/htdocs/sites/all/themes/fusion/fusion_core/template.php on
line 178
=============================================
and so on.

When I view the file using a text editor I see a number of lines which
are shown as binary characters ... should it be like this?
=============================================
$dimensions = !empty($node->height) && !empty($node->width) &&
!empty($node->length); // Hide dimensions if empty
$vars['fusion_uc_dimensions'] = ($dimensions) ?
drupal_render($node->content['dimensions']) : ';
if ($vars['fusion_uc_dimensions'] == ') {
unset($node->content['dimensions']);
}
$list_price = !empty($node->list_price) && $node->list_price > 0;
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@
=============================================

Another file that also gives the same parse error ends like this:
=============================================
if ($enabled_themes == 0) {
drupal_set_message(t('Skinr has detected that none of your
themes are enabled. This is likely related the Drupal bug: <a
href="http://drupal.org/node/305653">Themes disabled during
update</a>. Please re-enable your theme to continue using Skinr.'),
'warning', FALSE);
}

// Only add submit handler once.
eval('$element =& $form'. $form_settings['submit_handler_attach^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
=============================================
Is this caused by some php escape character error in these files, am I
missing some USE flag on my php package, or is there something else
wrong?

BTW, what I'd rather fix is the error reported on the last lines,
although I am interested as to why php files show this binary string
at the end.
--
Regards,
Mick

Mick 06-23-2010 07:15 AM

reading php file code in text editor
 
On 23 June 2010 07:18, Mick <michaelkintzios@gmail.com> wrote:
> I am looking at some php files which are causing parsing errors in Drupal, like:
> =============================================
> Warning: Unexpected character in input: ' in
> /var/www/htdocs/sites/all/themes/fusion/fusion_core/template.php on
> line 178
> Warning: Unexpected character in input: ' in
> /var/www/htdocs/sites/all/themes/fusion/fusion_core/template.php on
> line 178
> Warning: Unexpected character in input: ' in
> /var/www/htdocs/sites/all/themes/fusion/fusion_core/template.php on
> line 178
> =============================================
> and so on.
>
> When I view the file using a text editor I see a number of lines which
> are shown as binary characters ... should it be like this?
> =============================================
> * *$dimensions = !empty($node->height) && !empty($node->width) &&
> !empty($node->length); * * * * * * * * // Hide dimensions if empty
> * *$vars['fusion_uc_dimensions'] = ($dimensions) ?
> drupal_render($node->content['dimensions']) : ';
> * *if ($vars['fusion_uc_dimensions'] == ') {
> * * *unset($node->content['dimensions']);
> * *}
> * *$list_price = !empty($node->list_price) && $node->list_price > 0;
> * * ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@
> =============================================
>
> Another file that also gives the same parse error ends like this:
> =============================================
> * * *if ($enabled_themes == 0) {
> * * * *drupal_set_message(t('Skinr has detected that none of your
> themes are enabled. This is likely related the Drupal bug: <a
> href="http://drupal.org/node/305653">Themes disabled during
> update</a>. Please re-enable your theme to continue using Skinr.'),
> 'warning', FALSE);
> * * *}
>
> * * *// Only add submit handler once.
> * * *eval('$element =& $form'. $form_settings['submit_handler_attach^@^@^@^@^@
> ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
> =============================================
> Is this caused by some php escape character error in these files, am I
> missing some USE flag on my php package, or is there something else
> wrong?
>
> BTW, what I'd rather fix is the error reported on the last lines,
> although I am interested as to why php files show this binary string
> at the end.

I forgot, this are my flags on php

Installed versions: 5.2.13(5)(15:29:45 27/03/10)(apache2 berkdb
bzip2 cli crypt ctype gdbm iconv ldap mysql ncurses nls pcre readline
reflection session spell spl ssl truetype unicode xml zlib -adabas
-bcmath -birdstep -calendar -cdb -cgi -cjk -concurrentmodphp -curl
-curlwrappers -db2 -dbase -dbmaker -debug -discard-path -doc -empress
-empress-bcs -esoob -exif -fastbuild -fdftk -filter -firebird
-flatfile -force-cgi-redirect -frontbase -ftp -gd -gd-external -gmp
-hash -imap -inifile -interbase -iodbc -ipv6 -java-external -json
-kerberos -kolab -ldap-sasl -libedit -mcve -mhash -msql -mssql -mysqli
-oci8 -oci8-instant-client -odbc -pcntl -pdo -pic -posix -postgres
-qdbm -recode -sapdb -sharedext -sharedmem -simplexml -snmp -soap
-sockets -solid -sqlite -suhosin -sybase -sybase-ct -sysvipc -threads
-tidy -tokenizer -wddx -xmlreader -xmlrpc -xmlwriter -xpm -xsl -yaz
-zip)

--
Regards,
Mick

Stroller 06-23-2010 11:24 AM

reading php file code in text editor
 
On 23 Jun 2010, at 07:18, Mick wrote:

I am looking at some php files which are causing parsing errors in
Drupal, like:

=============================================
Warning: Unexpected character in input: ' in
/var/www/htdocs/sites/all/themes/fusion/fusion_core/template.php on
line 178
Warning: Unexpected character in input: ' in
/var/www/htdocs/sites/all/themes/fusion/fusion_core/template.php on
line 178
Warning: Unexpected character in input: ' in
/var/www/htdocs/sites/all/themes/fusion/fusion_core/template.php on
line 178
=============================================
and so on.

When I view the file using a text editor I see a number of lines which
are shown as binary characters ... should it be like this?
=============================================
$dimensions = !empty($node->height) && !empty($node->width) &&
!empty($node->length); // Hide dimensions if empty
$vars['fusion_uc_dimensions'] = ($dimensions) ?
drupal_render($node->content['dimensions']) : ';
if ($vars['fusion_uc_dimensions'] == ') {
unset($node->content['dimensions']);
}
$list_price = !empty($node->list_price) && $node->list_price > 0;

^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@

=============================================


I think it might be most useful if you gave us a complete copy of one
of these files, as an attachment. If they're security-sensitive, send
us just an extract which shows the sample (cut using something like
`head foo | tail > bar`). Where did these files come from? Did you
download a "fusion" theme from the Drupal website?


Stroller.

Mick 06-23-2010 12:22 PM

reading php file code in text editor
 
On 23 June 2010 13:48, <roundyz@hotmail.ru> wrote:
> Stroller wrote:
>
>>> On 23 Jun 2010, at 07:18, Mick wrote:
>>>
>>> > I am looking at some php files which are causing parsing errors in
>>> > Drupal, like:

> @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
> See this line here with all the ^@, delete it, or better yet comment it
> out, and see if it runs the same, it is not part of the php file, so
> maybe it was dumped during a refactoring session or the like.

Thanks guys,

I've tried all sort of 'fixes' like trying to add escape characters,
using closing tags, completely deleting the null symbols and what not,
but loading the page in drupal still causes similar parsing errors
although not always at the last line.

The files in question are attached in this message.

When looking at them with a hex editor I see this:

000027b0 20 7d 0d 0a 20 20 20 20 24 6c 69 73 74 5f 70 72 | }.. $list_pr|
000027c0 69 63 65 20 3d 20 21 65 6d 70 74 79 28 24 6e 6f |ice = !empty($no|
000027d0 64 65 2d 3e 6c 69 73 74 5f 70 72 69 63 65 29 20 |de->list_price) |
000027e0 26 26 20 24 6e 6f 64 65 2d 3e 6c 69 73 74 5f 70 |&& $node->list_p|
000027f0 72 69 63 65 20 3e 20 30 3b 20 20 20 20 20 20 20 |rice > 0; |
00002800 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00006170 00 00 00 00 00 00 00 00 |........|
00006178

It is the last 5 lines that seem to cause the problem. Any idea why
they are shown as binary in text editors (using vim, or less)?

PS. I just looked at earlier (stable) versions of these files here:

http://drupal.org/project/skinr

and here:

http://drupal.org/project/fusion

and they do not have the binary characters at the end - so this could
well be a problem with the development versions. I'll try the stable
versions when I get home and report back.
--
Regards,
Mick

06-23-2010 12:48 PM

reading php file code in text editor
 
Stroller wrote:

>>
>>
>> On 23 Jun 2010, at 07:18, Mick wrote:
>>
>> > I am looking at some php files which are causing parsing errors in
>> > Drupal, like:
>> > =============================================
>> > Warning: Unexpected character in input: ' in
>> > /var/www/htdocs/sites/all/themes/fusion/fusion_core/template.php on
>> > line 178
>> > Warning: Unexpected character in input: ' in
>> > /var/www/htdocs/sites/all/themes/fusion/fusion_core/template.php on
>> > line 178
>> > Warning: Unexpected character in input: ' in
>> > /var/www/htdocs/sites/all/themes/fusion/fusion_core/template.php on
>> > line 178
>> > =============================================
>> > and so on.
>> >
>> > When I view the file using a text editor I see a number of lines which
>> > are shown as binary characters ... should it be like this?
>> > =============================================
>> > $dimensions = !empty($node->height) && !empty($node->width) &&
>> > !empty($node->length); // Hide dimensions if empty
>> > $vars['fusion_uc_dimensions'] = ($dimensions) ?
>> > drupal_render($node->content['dimensions']) : ';
>> > if ($vars['fusion_uc_dimensions'] == ') {
>> > unset($node->content['dimensions']);
>> > }
>> > $list_price = !empty($node->list_price) && $node->list_price > 0;
>> >
>> > ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@

See this line here with all the ^@, delete it, or better yet comment it
out, and see if it runs the same, it is not part of the php file, so
maybe it was dumped during a refactoring session or the like.

regards,

Roundyz

Stroller 06-23-2010 02:08 PM

reading php file code in text editor
 
On 23 Jun 2010, at 13:22, Mick wrote:

...
I've tried all sort of 'fixes' like trying to add escape characters,
using closing tags, completely deleting the null symbols and what not,
but loading the page in drupal still causes similar parsing errors
although not always at the last line.

The files in question are attached in this message.


Well, I can confirm that these file show the same symptoms on vim
here, so it's not totally a bug with your text editor.


First step should perhaps be to report the bug to Drupal themselves.

I get the same garbage using vim here on my Mac, but interestingly not
if I open the file in TextEdit (like Notepad). In vim the files both
seem to terminate in this junk, and it kinda seem like vim doesn't
want to scroll down properly when it encounters it. In TextEdit I do
see a handful of blank spaces at the "end" of template.php, and if I
delete these then reopen in vim, the garbage is gone. I would be glad
to send you copies of both files "fixed", but I suspect the files are
truncated, and that that would leave stuff missing - the ^@^@^@^@^@
has been written over the real content, I think.


Stroller.

06-23-2010 02:26 PM

reading php file code in text editor
 
Mick wrote:

>> On 23 June 2010 13:48, <roundyz@hotmail.ru> wrote:
>> > Stroller wrote:
>> >
>> >>> On 23 Jun 2010, at 07:18, Mick wrote:
>> >>>
>> >>> > I am looking at some php files which are causing parsing errors in
>> >>> > Drupal, like:
>>
>> > @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
>> > See this line here with all the ^@, delete it, or better yet comment it
>> > out, and see if it runs the same, it is not part of the php file, so
>> > maybe it was dumped during a refactoring session or the like.
>>
>> Thanks guys,
>>
>> I've tried all sort of 'fixes' like trying to add escape characters,
>> using closing tags, completely deleting the null symbols and what not,
>> but loading the page in drupal still causes similar parsing errors
>> although not always at the last line.
>>
>> The files in question are attached in this message.
>>
>> When looking at them with a hex editor I see this:
>>
>> 000027b0 20 7d 0d 0a 20 20 20 20 24 6c 69 73 74 5f 70 72 | }.. $list_pr|
>> 000027c0 69 63 65 20 3d 20 21 65 6d 70 74 79 28 24 6e 6f |ice = !empty($no|
>> 000027d0 64 65 2d 3e 6c 69 73 74 5f 70 72 69 63 65 29 20 |de->list_price) |
>> 000027e0 26 26 20 24 6e 6f 64 65 2d 3e 6c 69 73 74 5f 70 |&& $node->list_p|
>> 000027f0 72 69 63 65 20 3e 20 30 3b 20 20 20 20 20 20 20 |rice > 0; |
>> 00002800 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
>> *
>> 00006170 00 00 00 00 00 00 00 00 |........|
>> 00006178
>>
>> It is the last 5 lines that seem to cause the problem. Any idea why
>> they are shown as binary in text editors (using vim, or less)?
>>
>> PS. I just looked at earlier (stable) versions of these files here:
>>
>> http://drupal.org/project/skinr
>>
>> and here:
>>
>> http://drupal.org/project/fusion
>>
>> and they do not have the binary characters at the end - so this could
>> well be a problem with the development versions. I'll try the stable
>> versions when I get home and report back.


You could use split to chop of the last 5 lines....



--
Regards,
Roundyz

Vincent Launchbury 06-23-2010 08:06 PM

reading php file code in text editor
 
On 06/23/10 08:22, Mick wrote:
> PS. I just looked at earlier (stable) versions of these files here:
>
> http://drupal.org/project/skinr
> [...]
> and they do not have the binary characters at the end - so this could
> well be a problem with the development versions.

Perhaps it was just a corrupt download. I grabbed
skinr-6.x-1.x-dev.tar.gz, and the skinr.module file was fine. (I assume
you got the same one, as the cvs $Id:$ is identical to the one you posted.)

Mick 06-23-2010 08:39 PM

reading php file code in text editor
 
On 23 June 2010 21:06, Vincent Launchbury <vincent@doublecreations.com> wrote:
> On 06/23/10 08:22, Mick wrote:
>> PS. *I just looked at earlier (stable) versions of these files here:
>>
>> http://drupal.org/project/skinr
>> [...]
>> and they do not have the binary characters at the end - so this could
>> well be a problem with the development versions.
>
> Perhaps it was just a corrupt download. I grabbed
> skinr-6.x-1.x-dev.tar.gz, and the skinr.module file was fine. (I assume
> you got the same one, as the cvs $Id:$ is identical to the one you posted.)

Guys thanks for your help. I thought of a corrupt download too, but
couldn't explain that happening more than once with different files.
Then I noticed a pattern developing ...

If the download took place on a ntfs partition (used to share files
with a MSWindows OS) and then transfered over to reiserfs where Gentoo
and the drupal server lives, well, all these phenomena of corrupt
files seem to take place.

I cannot honestly explain this! Why is it that if the download and
unzipping takes place using ntfs-3g on the said ntfs partition the php
files get corrupted?

This is what mount shows:

/dev/sda9 on /mnt/VideoDrive type fuseblk
(rw,nosuid,nodev,noatime,allow_other,blksize=4096)

Probably I did something wrong ... will keep an eye out for similar
errors in the future, because I just tried this again and there does
not seem to be a problem with it now.

Thanks for your help and sorry for the noise.
--
Regards,
Mick


All times are GMT. The time now is 04:31 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.