Re: [xsl] variable ending with ^@

Subject: Re: [xsl] variable ending with ^@
From: himanshu padmanabhi <himanshu.padmanabhi@xxxxxxxxx>
Date: Tue, 24 Feb 2009 17:29:15 +0530
Thank you for all that help

Yes,problem is in the later part.

abc.cgi- > abc.xsl -> abc.cgi

Still finding the exact point where they get inserted.I will tell you
if I fail to.

btw,in above flow,in my 'xsl file',I am getting values filled in the
combo box from 'logic file'.
I want to choose value selected by user from combo either my 'logic
file' or 'abc.cgi'.
How can I get it?Values should be there in $in hash of 'logic file',I think.


On Tue, Feb 24, 2009 at 11:25 AM, Deborah Pickett
<debbiep-list-xsl@xxxxxxxxxx> wrote:
>
> Hi himanshu,
>
> It might help for you to try to find whether the problem is with the first
> stage:
>  CGI -> Perl -> libxslt -> HTML
> or the second stage after the user presses the submit button:
>  CGI -> Perl logic_file.cgi -> HTTP redirect -> CGI -> Perl abc.cgi
>
> You can do that easily enough by going "View Source" on the HTML that the
> libxslt is producing.  Is there trailing garbage on the variable?  I
> suspect not.
>
> (If my suspicion is correct, it makes the rest of this reply off-topic for
> an XSL list, since there isn't any XSLT in the second stage.  But if you
> just want to hack together something that works, then I will summon my
> Perl-fu for this advice:)
>
> If you want to trim a trailing ASCII NUL byte from a Perl string, chomp
> won't work.  chop should work, but it's usually too aggressive and will
> chop anything.  Try instead:
>  $variable =~ s/\0$//;
>
> But I believe that you have probably removed the part of the code that is
> introducing the trailing NUL in your effort to simplify the problem.  It's
> quite unlikely that it's in the XSLT part of your chain, and far more
> likely to be in the Perl code.
>
> It might also be good to look through your HTTP server's logs and see if
> the HTTP redirect URL looks right.
>



--
Regards,
Himanshu Padmanabhi

Current Thread