Here Document syntax is stringent - trailing blank

text = <<EOD

Hi there. Why does the Here Document
require there to be no space after
the closing symbol? If I type "EOD " and press
enter, I get a syntax error. (See below.) If I type “EOD” with
an immediate carraige return, it works fine.

Why so stringent?
EOD

puts text

=begin
Error: #<SyntaxError: (eval):0:in `load’: /Library/Application
Support/Google SketchUp
6/SketchUp/Plugins/myscripts/here_document_test.rb:12: can’t find string
“EOD” anywhere before EOF
/Library/Application Support/Google SketchUp
6/SketchUp/Plugins/myscripts/here_document_test.rb:1: parse error,
unexpected $, expecting tSTRING_CONTENT or tSTRING_DBEG or tSTRING_DVAR
or tSTRING_END>
(eval)
(eval):0

=end

On Jan 11, 2008, at 8:05 AM, Todd B. wrote:

Hi there. Why does the Here Document
require there to be no space after
the closing symbol? If I type "EOD " and press
enter, I get a syntax error. (See below.) If I type “EOD” with
an immediate carraige return, it works fine.

Why so stringent?

I would guess because it is simpler to implement and simpler to
understand.

If you made trailing white space allowed on the closing delimiter
then you must define ‘white space’ and you have to explicitly ignore
it when scanning for the end of the text. If you changed the rule to
simply look for a line prefixed by the delimiter (so that white space
wasn’t an issue) then you would end up with strange things like:

text <<EOT
line 1
EOTX terminates the line

It is just simpler and less ambiguous to look for a line that
contains the delimiter and only the delimiter.

Gary W.

Gary W. wrote:

I would guess because it is simpler to implement and simpler to
understand.

It is just simpler and less ambiguous to look for a line that
contains the delimiter and only the delimiter.

Gary W.

Well, I would agree that certainly would be simpler to implement.
However, I don’t see it as conforming to the rest of ruby’s loose coding
allowances.

I can put as many blanks as I want after the top delimiter - ruby
figures it out. Ruby already requires the ending delimiter to be in
column 1.

All in all, it just seems non-ruby-ish. (Not to mention the fact that
it causes me grief when send a file from my Mac to my PC, and run it
through a CRLF fixer-program that turns the first extra of the double
CRs into blanks, and subsequently causes ruby parser errors for these
situations)

Todd

On Jan 11, 1:14 pm, Todd B. [email protected] wrote:

All in all, it just seems non-ruby-ish. (Not to mention the fact that
it causes me grief when send a file from my Mac to my PC, and run it
through a CRLF fixer-program that turns the first extra of the double
CRs into blanks, and subsequently causes ruby parser errors for these
situations)

If you’re using Mac OS X, rather than OS 9 or earlier, then your text
files should be using LF as a line break, not CR. And ruby on the PC
should be able to handle LF line endings just fine; you shouldn’t need
to convert line endings. Any decent PC text editor shoud be able to
handle LF as well (notepad.exe is not a decent text editor), and
even if not, a proper line ending converter should just insert a CR
before each LF without causing any problems.

If you are actually using CR as a line ending, well then, um, stop
it. :slight_smile:

On Jan 11, 1:14 pm, Todd B. [email protected] wrote:

I can put as many blanks as I want after the top delimiter - ruby
figures it out.

Actually, you can put more code after the top delimiter as well:

$ cat thing.rb
puts <<EOT * 5 # print “Hello world” 5 times
Hello world
EOT

$ ruby thing.rb
Hello world
Hello world
Hello world
Hello world
Hello world

On Jan 11, 2008, at 1:14 PM, Todd B. wrote:

Well, I would agree that certainly would be simpler to implement.
However, I don’t see it as conforming to the rest of ruby’s loose
coding
allowances.

Here documents are a pretty special case. They are there
specifically so you can imbed somewhat arbitrary text in the source
code. As such it makes sense to have a very specific way to
terminate that text rather than a looser match that might accidently
coincide with some data. Obviously the choice of a delimiter is
important.

Gary W.

Karl von Laudermann wrote:

If you’re using Mac OS X, rather than OS 9 or earlier,

I am -10.4+

then your text
files should be using LF as a line break, not CR.

I use both TextEdit and TextWrangler. Both put in \r\n

And ruby on the PC
should be able to handle LF line endings just fine; you shouldn’t need
to convert line endings.

Ruby does handle it fine.

Any decent PC text editor shoud be able to
handle LF as well (notepad.exe is not a decent text editor),

Bingo. I don’t use a proper text editor. I use Notepad. And my PC
clients use Notepad. If I don’t do this, anyone who does edit it later
on a PC in Notepad gets a compressed file that will not subsequently run
(all text is mashed together and a real long string). If I didn’t
comment my code, and I always used a semi colon between clauses, it
would not be an issue.

and
even if not, a proper line ending converter should just insert a CR
before each LF without causing any problems.

Well, er… umm… I wrote it. It replaces the \r with a blank. It’s
very fast (C code), doesn’t change the size of the file and converts
them in place. I simply drag and drop the file needing to be converted
onto my desktop icon and it’s done a split second later.

What should it be doing? If I changed the \r to a \n, wouldn’t I get
double spacing?

Thanks, Todd

On Jan 11, 2008 7:14 PM, Todd B. [email protected] wrote:

I can put as many blanks as I want after the top delimiter - ruby
figures it out. Ruby already requires the ending delimiter to be in
column 1.

It’s not necessary when prefixing the terminator with “-”:
put <<-EOT
gfsgfdgdf
dg gdfgdf
dfg
EOT

I too would welcome the whitespace after the delimiter.

Jano

Karl von Laudermann wrote:

Ok, one of us is confused, and I think it’s you. :slight_smile:

Well, I certainly am confused!

So, in summary:

  • If you’re transferring a text file to a PC, you want to then
    ensure that each line ends with \r\n.

I’m confused because everything you state is 100% correct, yet Notepad
still collapses text file on first edit.

I did set my “save as” format in TextWrangler as Windows format.
TextWrangler is saving files with \r\n.
Notepad still collapses files on first edit.

'Splain me this!

  • And if you’re doing a conversion that strips the \r from each \r\n
    pair, you want to delete the \r, not replace it with a blank.

I could do that, but that would be too easy, right? !!

On Jan 11, 4:49 pm, Todd B. [email protected] wrote:

Karl von Laudermann wrote:

If you’re using Mac OS X, rather than OS 9 or earlier,
then your text
files should be using LF as a line break, not CR.

I use both TextEdit and TextWrangler. Both put in \r\n

even if not, a proper line ending converter should just insert a CR
before each LF without causing any problems.

Well, er… umm… I wrote it. It replaces the \r with a blank. It’s
very fast (C code), doesn’t change the size of the file and converts
them in place. I simply drag and drop the file needing to be converted
onto my desktop icon and it’s done a split second later.

What should it be doing? If I changed the \r to a \n, wouldn’t I get
double spacing?

Ok, one of us is confused, and I think it’s you. :slight_smile: Different OS’s
use and expect different line endings for text files. Specifically:

Unix and Mac OS X: \n
Dos/Windows: \r\n
Classic Mac OS: \r

You said you were transferring files from a Mac to a PC. So I
assumed your files had \n line endings, and you used a converter to
add a \r before each \n, once the files were on the PC. But you’re
saying that using TextEdit and TextWrangler on the Mac, the files
already get \r\n line endings, which is what the PC expects. So no
conversion should be necessary when transferring them to a PC. And
this is suspicious anyway, because I would expect TextEdit and
TextWrangler to use unix line endings by default, so you would have to
have manually changed the preferences to use PC line endings.

If you were going from a PC to a Mac (or Linux or other Unix),
then you would want a converter to delete all the \r characters from
each \r\n pair. Note I said delete, but you say your program
replaces each \r with a blank, thus not changing the file size. So in
effect each line gets an extra blank at the end.

So, in summary:

  • If you’re transferring a text file to a PC, you want to then
    ensure that each line ends with \r\n.
  • If you’re transferring a text file to a Mac, you want to then
    ensure that each line ends with \n.
  • And if you’re doing a conversion that strips the \r from each \r\n
    pair, you want to delete the \r, not replace it with a blank.

Karl von Laudermann wrote:

On Jan 15, 5:35 pm, Todd B. [email protected] wrote:

Ok, I guess the only question I have then is, how are you transferring
the files from the Mac to the PC?

Email, sending from the Mac (Mac Mail) to the PC (Outlook), as a
“windows friendly” attachment (whatever that means).

So, I’m stumped.

That’s two of us. When I use my CRLF converter, all is well, except
the… here document. :slight_smile:

On Jan 15, 5:35 pm, Todd B. [email protected] wrote:

I’m confused because everything you state is 100% correct, yet Notepad
still collapses text file on first edit.

I did set my “save as” format in TextWrangler as Windows format.
TextWrangler is saving files with \r\n.
Notepad still collapses files on first edit.

'Splain me this!

Ok, I guess the only question I have then is, how are you transferring
the files from the Mac to the PC? If you’re using FTP, and tranferring
in ASCII mode rather than binary mode, that might muck with the line
endings. Although, if that were causing a problem, I would expect it
would be adding extra \r before each \n, thus ending each line with \r
\r\n. Which shouldn’t cause Notepad to collapse the lines.

So, I’m stumped.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs