Here Document syntax is stringent - trailing blank

ruby-talk
1

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

···

--
Posted via http://www.ruby-forum.com/.

2

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 Wright

···

On Jan 11, 2008, at 8:05 AM, Todd Burch 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?

3

Gary Wright 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 Wright

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

···

--
Posted via http://www.ruby-forum.com/.

4

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, 1:14 pm, Todd Burch <pro...@burchwoodusa.com> wrote:

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

5

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 Burch <pro...@burchwoodusa.com> 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)

6

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 Wright

···

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

Gary Wright 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 Wright

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.

7

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

···

On Jan 11, 2008 7:14 PM, Todd Burch <promos@burchwoodusa.com> 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.

8

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

···

--
Posted via http://www.ruby-forum.com/.

9

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

<snip>

> 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.

···

On Jan 11, 4:49 pm, Todd Burch <pro...@burchwoodusa.com> wrote:

10

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? !!

···

--
Posted via http://www.ruby-forum.com/.

11

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.

···

On Jan 15, 5:35 pm, Todd Burch <pro...@burchwoodusa.com> 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!

12

Karl von Laudermann 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 Burch <pro...@burchwoodusa.com> wrote:

--
Posted via http://www.ruby-forum.com/.