why the following HereDoc print don't work?

[Anno Siegel]

My Perl:

Sherm-Pendleys-Computer:~ sherm$ perl -v

This is perl, v5.8.1-RC3 built for darwin-thread-multi-2level
(with 1 registered patch, see perl -V for more detail)

Standard factory-supplied Perl for Mac OS X "Panther".

Your editor might be adding a trailing newline to text files
automatically - quite a few can be configured to do that.

Yes, that's what was happening. Sorry -- should have checked.
With the newline actually missing I see the same effect.

Agreed. Anyone using 5.8.6 care to comment here?

RSN...

Anno

 

[Sherm Pendley]

does the file that fails look like this at the end

45 E
4f O
46 F
<end-of-file>

Yes, exactly.

sherm--

 

[Sherm Pendley]

No, Solution 1: get a real text editor.

Solution 2: persuade the one you've got to create a proper text file by
apparently putting a blank line on the end.

Are you seriously suggesting that Perl *should* refuse to run a file,
simply because the file doesn't end with a blank line? That's ridiculous
- if I believed that whitespace-as-syntax nonsense, I'd be using Python.

sherm--

 

[Brian McCauley]

Yes, exactly.

The odd thing is that chop($text=eval"<<EOF\n$text\nEOF") works without
a trailing newline on 5.6.1 and 5.8.4 (although IIRC it failed on some
older Perls).

 

[Ben Morrow]

Are you seriously suggesting that Perl *should* refuse to run a file,
simply because the file doesn't end with a blank line?

*IT ISN'T A BLANK LINE*. The "\n" is the end of the line.

That's ridiculous
- if I believed that whitespace-as-syntax nonsense, I'd be using Python.

This has nothing to do with Perl (so I shall not continue the discussion
any further). It has to do with what is, and what isn't, a text file.

Ben

 

[Sherm Pendley]

This has nothing to do with Perl

Nonsense. We're discussing what Perl should accept as valid input. That
has *everything* to do with Perl. (Well technically I suppose it's to do
with perl, not Perl...)

It has to do with what is, and what isn't, a text file.

Okay, so a text file is supposed to end in a newline, according to some
arbitrary definition. I think that definition is *far* from universally
accepted, but let's accept it for the sake of debate.

The question is, so what? Why should that be a fatal error?

Perl accepts just about any kind of garbage and jumps through hoops to
parse and run it. It's famous as a "do what I mean" language where there
is "more than one way to do it." Throwing an error because of a single
missing whitespace character runs completely counter to that philosophy.

What's more, it's inconsistent. Perl doesn't require a trailing newline
in any other situation I could find. Nor do the other languages I tried
- C, Python, Ruby, sh, and bash all cope just fine. Only Perl dies, and
it dies only when the closing delimiter of a here-document is at the end
of such a "non-text" file.

sherm--

 

[Gunnar Hjalmarsson]

Only Perl dies, and it dies only when the closing delimiter of a
here-document is at the end of such a "non-text" file.

But that has nothing to do with the Perl compiler complaining about the
*file* syntax, has it? It's complaining because the here-document syntax
requires a line that matches /^EOF\n\z/ (assuming that the terminating
string happens to be 'EOF'...), right?

 

[Gunnar Hjalmarsson]

.. the here-document syntax requires a line that matches /^EOF\n\z/

Sorry, I meant /^EOF\n/

 

[Sherm Pendley]

But that has nothing to do with the Perl compiler complaining about the
*file* syntax, has it? It's complaining because the here-document syntax
requires a line that matches /^EOF\n\z/ (assuming that the terminating
string happens to be 'EOF'...), right?

That sounds right, yes. No other part of perl fails in this manner, as
far as I've found. Ordinary statements are parsed just fine if they
appear at the end of a file.

It appears to me that the lexer is failing to match a here-doc token
when the terminating delimiter is at the end of the file. Since it
doesn't fail when other statements appear at the end of the file, I'm
assuming it's a bug in perl.

I'm going to verify this with the latest Perl before I file a perlbug -
I need to upgrade anyway. And I'll try to be a good citizen and follow
it up with a patch to p5p, if I can manage to create one.

sherm--

 

[Sherm Pendley]

I'm going to verify this with the latest Perl before I file a perlbug -
I need to upgrade anyway. And I'll try to be a good citizen and follow
it up with a patch to p5p, if I can manage to create one.

Okay, I've verified that the bug still exists in 5.8.6, and used
'perlbug' to file a bug. (Haven't received a verification or response
yet though - should I expect one?)

No luck with the patch. I found the likely function in toke.c, but the
code in there is scary. Perl's lexer is apparently *not* the best place
to begin studying the internals... :-(

sherm--