Mailing List Archive

Hi,

Thank you for the reply.

Adding [- $optRawInput = 1 -] did not make things better but worse. It generates more runtime errors.

I think you might have misunderstood my problem. The point of trouble is at the second END instead of the first one.

I'm sure that Embperl (I'm using version 1.2b9) does NOT remove CRs from page sources. This is because it runs good when I use vi to remove the CR immediately after the second 'END'. But manual removal of CR is, after all, not the solution.

Which version of Embperl removes CR?

Thanks.

Huang-Ming
----- Original Message -----
From: Gerald Richter
To: Hello ; Embperl@Perl. Apache. Org
Sent: Saturday, April 29, 2000 8:20 PM
Subject: RE: PERL string terminator with Carriage Return...




Everything is ok except when I use the following Perl string terminator construct:
[+
print <<END;
111111111111
222222222222
END
+]
Embperl complains with:
[2310]ERR: 24: Line 10: Error in Perl code: (in cleanup) Can't find string terminator "
END" anywhere before EOF at /usr/local/apache/htdocs/test.htm line 11.

When I dig into the file source with vi, there is a ^M (ie. CarriageReturn) immediately following "END". I think Perl won't allow anything execpt LineFeed (0A) to follow the string terminator, END here.

Embperl already removes the CR from your source (because Perl 5.004 don't like CR's at all).

Does it change anything when you put the block [- $optRawInput = 1 -] before the above code? or you can write &lt;&lt; instead of the <<. Otherwise Embperl will treat the << as the start of an HTML tag and removes the rest of the block. This is done to get rid of unwanted HTML tags e.g. <BR> that are inserted by FrontPage or other editors in your perl code.

Gerald

P.S. Support for Embperl has moved from modperl to embperl mailing list

On 29-Apr-2000 Hello wrote:
[# snip #]

> [.+
> print <<END;
> 111111111111
> 222222222222
> END
> +]
> Embperl complains with:
> [2310]ERR: 24: Line 10: Error in Perl code: (in cleanup) Can't find
> string terminator "
> END" anywhere before EOF at /usr/local/apache/htdocs/test.htm line
> 11.

Just to make sure... the second END has to be the first character in the
sentance... Otherwise you will get that error.

Just making sure, in case it wasn't just your mail program that indented it
like that above.

Regards,

Wim Kerkhoff, Software Engineer
NetMaster Networking Solutions
wim@netmaster.com

all the lines including the second END sentance start on column #1. i should
not indent it in my email.

thanks anyway.

regards,
huang-ming
----- Original Message -----
From: Wim Kerkhoff <wim@netmaster.com>
To: Hello <panpipi@ksts.seed.net.tw>
Cc: Embperl@Perl. Apache. Org <embperl@perl.apache.org>
Sent: Sunday, April 30, 2000 3:01 AM
Subject: Re: PERL string terminator with Carriage Return...


>
> On 29-Apr-2000 Hello wrote:
> [# snip #]
>
> > [.+
> > print <<END;
> > 111111111111
> > 222222222222
> > END
> > +]
> > Embperl complains with:
> > [2310]ERR: 24: Line 10: Error in Perl code: (in cleanup) Can't
find
> > string terminator "
> > END" anywhere before EOF at /usr/local/apache/htdocs/test.htm
line
> > 11.
>
> Just to make sure... the second END has to be the first character in the
> sentance... Otherwise you will get that error.
>
> Just making sure, in case it wasn't just your mail program that indented
it
> like that above.
>
> Regards,
>
> Wim Kerkhoff, Software Engineer
> NetMaster Networking Solutions
> wim@netmaster.com
>

hi,

i'm sorry. embperl does remove '\r' on line 247 of eputil.c.

but actually it replaces it with a space, ' '. this makes a PERL string terminator, for example "END\r\n' become "END \n", thus still makes PERL compile to error.

i downloaded most up-to-date embperl, version 1.3b3. and it remains the same handling and the same error result.

so i could not but change line 247 of eputil.c to
*ep++ = '\n';
by myself and found it finally works!!

however, i perfer to complete removal of \r rather than replacement.

this is important to me because i get used to dividing a long MySQL SQL statement into several lines and terminating them by a terminator "END", for example,

my $st=$db->mysql(<<END);
SELECT album.* ,album.oid AS oid2,uinfo.name,uinfo.user, uinfo.gid, uinfo.frs, count(alobj.oid) AS nobj,
(unix_timestamp()-unix_timestamp(album.birth)<$ndays*24*60*60) AS new
FROM uinfo, album LEFT OUTER JOIN alobj USING (aid)
WHERE kind='$fdat{kind}' $search AND ($pref)
AND album.oid=uinfo.id
GROUP BY album.aid
LIMIT $fdat{limit}
END

i understand that all these troubles are caused by Composer and FrontPage of windows version, which terminate each line of html files with '\r\n'.

but i wish newer version of embperl could filter out \r completely.

thanks.

regards,
huang-ming
----- Original Message -----
From: Gerald Richter
To: Hello ; Embperl@Perl. Apache. Org
Sent: Saturday, April 29, 2000 8:20 PM
Subject: RE: PERL string terminator with Carriage Return...




Everything is ok except when I use the following Perl string terminator construct:
[+
print <<END;
111111111111
222222222222
END
+]
Embperl complains with:
[2310]ERR: 24: Line 10: Error in Perl code: (in cleanup) Can't find string terminator "
END" anywhere before EOF at /usr/local/apache/htdocs/test.htm line 11.

When I dig into the file source with vi, there is a ^M (ie. CarriageReturn) immediately following "END". I think Perl won't allow anything execpt LineFeed (0A) to follow the string terminator, END here.

Embperl already removes the CR from your source (because Perl 5.004 don't like CR's at all).

Does it change anything when you put the block [- $optRawInput = 1 -] before the above code? or you can write &lt;&lt; instead of the <<. Otherwise Embperl will treat the << as the start of an HTML tag and removes the rest of the block. This is done to get rid of unwanted HTML tags e.g. <BR> that are inserted by FrontPage or other editors in your perl code.

Gerald

P.S. Support for Embperl has moved from modperl to embperl mailing list







But I cannot change Composer or Frontpage anyway. Is there any remedy I can do to drop the annoying ^M on the fly during Embperl parsing phase? Has anyone else ever reported such a problem? I used to using X-window version of Composer and never found such problem.

I cannot but edit my web pages on Win/98 and use Samba server because there is no way to edit Chinese characters on Linux X-window.

Please advise on this. Thanks a lot.

Best Regards,

Huang-Ming


----- Original Message -----
From: Gerald Richter
To: seednet
Sent: Monday, February 21, 2000 3:28 AM
Subject: RE: Chinese char input problem...


Hi,

sorry, I missed this mail, so my answer is coming very late.

Also your idea of a familiy site sounds interesting to me, it currently doesn't fit in the things we do. We also currently don't have the men power to do further developement on that.

Sorry

Gerald
-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting

Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925151
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------






-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting

Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925151
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

At 7:58 PM +0800 4/30/00, Hello wrote:
>this is important to me because i get used to dividing a long MySQL
>SQL statement into several lines and terminating them by a
>terminator "END", for example,
>
>my $st=$db->mysql(<<END);
>SELECT album.* ,album.oid AS oid2,uinfo.name,uinfo.user, uinfo.gid,
>uinfo.frs, count(alobj.oid) AS nobj,
> (unix_timestamp()-unix_timestamp(album.birth)<$ndays*24*60*60) AS new
> FROM uinfo, album LEFT OUTER JOIN alobj USING (aid)
> WHERE kind='$fdat{kind}' $search AND ($pref)
> AND album.oid=uinfo.id
> GROUP BY album.aid
> LIMIT $fdat{limit}
>END

This isn't a fix to the bug, but I recently picked up another way of
doing this which works much the same way and is a little cleaner:

my $st=$db->mysql(qq[.
SELECT album.* ,album.oid AS oid2,uinfo.name,uinfo.user, uinfo.gid,
uinfo.frs, count(alobj.oid) AS nobj,
(unix_timestamp()-unix_timestamp(album.birth)<$ndays*24*60*60) AS new
FROM uinfo, album LEFT OUTER JOIN alobj USING (aid)
WHERE kind='$fdat{kind}' $search AND ($pref)
AND album.oid=uinfo.id
GROUP BY album.aid
LIMIT $fdat{limit}
]);
- --

Kee Hinckley - Somewhere Consulting Group - Cyberspace Architects(rm)

I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.2 for non-commercial use <http://www.pgp.com>

iQA/AwUBOQw7NiZsPfdw+r2CEQI7iQCgr7q/moTHNaDQ4zvkQUoPvJfDI84Amwb/
TFY8dhAlYbDO1qU+ETegkK4A
=+lcX
-----END PGP SIGNATURE-----

i'm sorry. embperl does remove '\r' on line 247 of eputil.c.

but actually it replaces it with a space, ' '. this makes a PERL string
terminator, for example "END\r\n' become "END \n", thus still makes PERL
compile to error.

Yes, when I wrote my last answer I were in great hurry and didn't tought
enought about your problem.


i downloaded most up-to-date embperl, version 1.3b3. and it remains the
same handling and the same error result.

Replaceing with space is much faster, then removing the \r and the HERE
documents are the only place were this really is a problem.

so i could not but change line 247 of eputil.c to
*ep++ = '\n';
by myself and found it finally works!!

however, i perfer to complete removal of \r rather than replacement.


I will keep this in mind for the new Embperl 2 version, for now use the
solution which Kee already pointed out, by using qq[ ].

Gerald