why the following HereDoc print don't work?

[ÕÔ±û·å]

In a generator of C code file script, I wrote:

<CODE>
....
print SOURCE <<EOF;
default:
return 0;
}

return ret;
}
EOF
....
</CODE>

Perl complained "Can't find string terminator "EOF" anywhere before EOF at
XXX(line No.)".
What happened and why?



£­£­£­£­£­£­£­£­£­£­£­£­£­£­£­£­£­£­£­£­£­£­£­£­£­£­£­
Topsec, the first-class security products provider!

£­£­£­£­£­£­£­£­£­£­£­£­£­£­£­£­£­£­£­£­£­£­£­£­£­£­£­

 

[A. Sinan Unur]

In a generator of C code file script, I wrote:

<CODE>
...
print SOURCE <<EOF;
default:
return 0;
}

return ret;
}
EOF
...
</CODE>

Perl complained "Can't find string terminator "EOF" anywhere before
EOF at XXX(line No.)".
What happened and why?

Show real code.

D:\Home>cat t8.pl
use strict;
use warnings;

open SOURCE, '>-' or die $!;

print SOURCE <<EOF;
default:
return 0;
}

return ret;

EOF


D:\Home>perl t8.pl
default:
return 0;
}

return ret;

Sinan

 

[Andrew Hamm]

Perl complained "Can't find string terminator "EOF" anywhere before
EOF at XXX(line No.)".
What happened and why?

agree with Sinan - but then, showing real code might be difficult - many
news readers seem to rip out leading tabs and spaces when you make a
posting. From your lack of indentation, either you are a messy programmer,
or the newsreader you use has modified your message.

The EOF needs to be on the very left column. It should not be indented. If
the complete lack of indentation in your posting is how you really do have
it in your script, then it looks to me like it should work; indeed a test
does work for me.

summary - put EOF in the very left column of the line and you should be
happy.

 

[Bart Lateur]

Perl complained "Can't find string terminator "EOF" anywhere before EOF at
XXX(line No.)".
What happened and why?

Check your line holding the "EOF". It is likely there is some whitespace
on it.

 

[jl_post]

showing real code might be difficult - many
news readers seem to rip out leading tabs and
spaces when you make a posting. From your
lack of indentation, either you are a messy
programmer, or the newsreader you use has
modified your message.

I know for a fact that Google Groups strips out all indentations as
of this last weekend. Of course, this is bad for me because I can no
longer post properly-indented code. Honestly, I don't see a single
good reason to strip out leading white-space that the poster explicitly
put in. (I've submitted this feedback, but it's unclear whether Google
will do anything about it.)

In the meantime, if anyone knows how to preserve indentations using
Google Groups, please let me know. Otherwise, the code that I post
will look like this:

sub printHelloWorldNTimes
{
my $num = shift;

for (1 .. $num)
{
print "Hello, World!\n";
}
}

Thanks.

 

[bingfeng]

Oh, no, there is NO anything before the second "EOF" and I use indent
correctly, as you said, when I posting, my new reader trim all leader spaces
automatically The worse thing is I encountered another similar question
now and I doubt whether it is bug of perl 5.8.4. The following codes does
not work still:

<CODE>
use strict;
use warnings;

print <<EOF;
Help text:
Command line is:
Datecheck [options] <files> [<files>...]
where:
[Option] are to be defined
EOF
</CODE>

But other similar codea in another script worked correctly!

<CODE>
#! usr/bin/perl
use strict;
use warnings;

my $header = "define.h";
my $source = "parse.c";
my $func = "int Parse(char* pData, enum TOSTYPE type, void *pResult)";
open HEADER, '>', $header or die "cannot open the \'$header\': $!";
open SOURCE, '>', $source or die "cannot open the \'$source\': $!";
my $time = localtime;

print HEADER <<"EOF";
/*
* Interface definition header file of Parse(), generated by perl script
*
* File name : $header
* Last generated time : $time
*/


#ifndef DEFINE_H
#define DEFINE_H

EOF
# the fillowing omitted

</CODE>

I'm crazying now...

 

[Sherm Pendley]

Perl complained "Can't find string terminator "EOF" anywhere before EOF at
XXX(line No.)".
What happened and why?

Looks to me like the "EOF" is on the last line of your script, which
doesn't have a newline at the end of it.

Solution: Add a blank line to the end of your script.

sherm--

 

[Bart Lateur]

Oh, no, there is NO anything before the second "EOF" and I use indent
correctly, as you said,

It needn't be before it. Trailing spaces have just the same effect.

 

[A. Sinan Unur]

I encountered another similar question now and I doubt whether
it is bug of perl 5.8.4.

This brings to mind:

#11907 Looking for a compiler bug is the strategy of LAST resort. LAST
resort.

and

#11938 If you have `some weird error', the problem is probably with your
frobnitzer.

as well as

#11958 The bug is in you, not in Perl.

from MJD's timeless post (http://tinyurl.com/4pz2t)

The following codes does not work still:

<CODE>
use strict;
use warnings;

print <<EOF;
Help text:
Command line is:
Datecheck [options] <files> [<files>...]
where:
[Option] are to be defined
EOF
</CODE>

Funny ... odd ... curious ...

D:\Home\Dload>perl t3.pl
Help text:
Command line is:
Datecheck [options] <files> [<files>...]
where:
[Option] are to be defined

But other similar codea in another script worked correctly!

#11948 Perhaps your veeblefitzer is clogged.

I'm crazying now...

You and me both ...

news:[email protected]...

Oooops ... didn't see this. Don't top-post.

Sinan.

 

[Tad McClellan]

Perl complained "Can't find string terminator "EOF" anywhere before EOF at
XXX(line No.)".
What happened and why?

You can most often answer questions about messages from perl if
you read up on the message in perldiag.pod.

Or, put

use diagnostics;

at the top of your program and run it again, then perl will lookup
and display the description from perldiag for you.


=item Can't find string terminator %s anywhere before EOF

(F) Perl strings can stretch over multiple lines. This message means
that the closing delimiter was omitted. Because bracketed quotes count
nesting levels, the following is missing its final parenthesis:

print q(The character '(' starts a side comment.);

If you're getting this error from a here-document, you may have included
unseen whitespace before or after your closing tag. A good programmer's
editor will have a way to help you find these characters.

 

[Sherm Pendley]

The following codes does not work still:

<CODE>
use strict;
use warnings;

print <<EOF;
Help text:
Command line is:
Datecheck [options] <files> [<files>...]
where:
[Option] are to be defined
EOF
</CODE>

Funny ... odd ... curious ...

.... and correct. I copy everything up to and including the EOF - but
*NOT* the newline after EOF - into a text file and run it. What do I see?

Sherm-Pendleys-Computer:~ sherm$ perl test.pl
Can't find string terminator "EOF" anywhere before EOF at test.pl line 6.

Now I add a newline to the end, after EOF, and what do I see?

Sherm-Pendleys-Computer:~ sherm$ perl test.pl
Help text:
Command line is:
Datecheck [options] <files> [<files>...]
where:
[Option] are to be defined

sherm--

 

[Sherm Pendley]

You can most often answer questions about messages from perl if
you read up on the message in perldiag.pod.

Excellent advice for the general case, but in this case specifically it
looks to me like perldiag is missing a critical bit of info that might
have been helpful:

If you're getting this error from a here-document, you may have included
unseen whitespace before or after your closing tag.

.... or, the closing tag might be at the end of the file, on a line that
doesn't end with a newline character.

sherm--

 

[Anno Siegel]

The following codes does not work still:

<CODE>
use strict;
use warnings;

print <<EOF;
Help text:
Command line is:
Datecheck [options] <files> [<files>...]
where:
[Option] are to be defined
EOF
</CODE>

Funny ... odd ... curious ...

... and correct. I copy everything up to and including the EOF - but
*NOT* the newline after EOF - into a text file and run it. What do I see?

Sherm-Pendleys-Computer:~ sherm$ perl test.pl
Can't find string terminator "EOF" anywhere before EOF at test.pl line 6.

Now I add a newline to the end, after EOF, and what do I see?

Sherm-Pendleys-Computer:~ sherm$ perl test.pl
Help text:
Command line is:
Datecheck [options] <files> [<files>...]
where:
[Option] are to be defined

I cannot reproduce this with v5.8.1, but if it is the reason then
it *is* arguably a bug in (some version of) Perl. The final line
shouldn't matter.

Anno

 

[Anno Siegel]

The following codes does not work still:

<CODE>
use strict;
use warnings;

print <<EOF;
Help text:
Command line is:
Datecheck [options] <files> [<files>...]
where:
[Option] are to be defined
EOF
</CODE>

Funny ... odd ... curious ...

... and correct. I copy everything up to and including the EOF - but
*NOT* the newline after EOF - into a text file and run it. What do I see?

Sherm-Pendleys-Computer:~ sherm$ perl test.pl
Can't find string terminator "EOF" anywhere before EOF at test.pl line 6.

Now I add a newline to the end, after EOF, and what do I see?

Sherm-Pendleys-Computer:~ sherm$ perl test.pl
Help text:
Command line is:
Datecheck [options] <files> [<files>...]
where:
[Option] are to be defined

I cannot reproduce this with v5.8.1, but if it is the reason then
it *is* arguably a bug in (some version of) Perl. The final line
feed shouldn't matter.

Anno

 

[Tad McClellan]

Excellent advice for the general case, but in this case specifically it
looks to me like perldiag is missing a critical bit of info that might
have been helpful:

We should be able to assume that the documentation for here-docs
has been consulted when debugging a problem related to here-docs.

So the critical bit of info is in perlop.pod, though it could be
more explicit in either place...

... or, the closing tag might be at the end of the file, on a line that
doesn't end with a newline character.

If it doesn't end with a newline, we shouldn't be calling it "a line"
(maybe "chunk" or "input"?).


=head2 Quote and Quote-like Operators
...
The terminating string must appear by itself (unquoted and
with no surrounding whitespace) on the terminating line.


ie. it won't work if the closing tag is not on a (real) "line".

 

[A. Sinan Unur]

The following codes does not work still:

<CODE>
use strict;
use warnings;

print <<EOF;
Help text:
Command line is:
Datecheck [options] <files> [<files>...]
where:
[Option] are to be defined
EOF
</CODE>

Funny ... odd ... curious ...

... and correct. I copy everything up to and including the EOF - but
*NOT* the newline after EOF - into a text file and run it. What do I
see?

A-ha! I was using Gvim and I think my settings ensure that there is
always a newline there. So, I went and did what you describe above using
Notepad this time:

C:\Home> perl -v

This is perl, v5.8.4 built for MSWin32-x86-multi-thread
(with 3 registered patches, see perl -V for more detail)

C:\Home> cat t.pl
use strict;
use warnings;

print <<EOF;
Help text:
Command line is:
Datecheck [options] <files> [<files>...]
where:
[Option] are to be defined
EOF
C:\Home> perl t.pl
Can't find string terminator "EOF" anywhere before EOF at t.pl line 4.

You are right.

Sinan

 

[Arndt Jonasson]

We should be able to assume that the documentation for here-docs
has been consulted when debugging a problem related to here-docs.

So the critical bit of info is in perlop.pod, though it could be
more explicit in either place...




If it doesn't end with a newline, we shouldn't be calling it "a line"
(maybe "chunk" or "input"?).


=head2 Quote and Quote-like Operators
...
The terminating string must appear by itself (unquoted and
with no surrounding whitespace) on the terminating line.


ie. it won't work if the closing tag is not on a (real) "line".

There are programs that work if the final line is not ended by a
newline. The above text alone does not indicate that the terminating
line must be ended by a newline - it depends on the notion of "line"
used.

The name itself does not prove much, but is an indication: both
"newline" and "linefeed" seem to say something about the _next_ line,
not that the current line is ended.

There is more than one Unix program that does not work if the final
line is not newline-terminated ('sed' for example), so it's probably a
good habit to conform to the "a line is always newline-terminated"
school when you produce text files.

 

[Ben Morrow]

... and correct. I copy everything up to and including the EOF - but
*NOT* the newline after EOF - into a text file and run it. What do I see?

Sherm-Pendleys-Computer:~ sherm$ perl test.pl
Can't find string terminator "EOF" anywhere before EOF at test.pl line 6.

Now I add a newline to the end, after EOF, and what do I see?

By 'the newline after EOF' do you mean a /\r?\n/ immediately after 'EOF'
(terminating that line) or another one after that? That is, does the
file that fails look like this at the end

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

or like this

45 E
4f O
46 F
0a \n
<end-of-file>

? If the former, then it isn't a valid text file (no Unix editor will
produce a file like that unless you explicitly ask for it, though some
Windows editors do) and it's not surprising it fails. When given the
here-doc <<EOF perl looks for the literal sequence "\nEOF\n" as the
terminator.

Ben

 

[Ben Morrow]

Looks to me like the "EOF" is on the last line of your script, which
doesn't have a newline at the end of it.

Solution: Add a blank line to the end of your script.

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.

Ben

 

[Sherm Pendley]

I cannot reproduce this with v5.8.1

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.

but if it is the reason then
it *is* arguably a bug in (some version of) Perl. The final line
feed shouldn't matter.

Agreed. Anyone using 5.8.6 care to comment here?

sherm--