Magic comments justification

Ruby
1

Hi,

I’m looking for explanations about the choice of using magic comment to
set the source encoding for ruby 1.9 code. I’ve searched on the web but
didn’t find anything. Does anyone have good pointers?

Thanks

Raph

2

The encoding has to be set before the file is even parsed. So
obviously you can’t use a regular method call to do this; this
basically forces you to create new syntax for setting the encoding.
However, you also want to keep backwards compatibility when possible –
so you make that new syntax look like comments for older Ruby
versions. Bam, you’ve got a magic encoding comment.

– Matma R.

3

Bartosz Dziewoński wrote in post #1063320:

The encoding has to be set before the file is even parsed. So
obviously you can’t use a regular method call to do this; this
basically forces you to create new syntax for setting the encoding.
However, you also want to keep backwards compatibility when possible –
so you make that new syntax look like comments for older Ruby
versions. Bam, you’ve got a magic encoding comment.

– Matma R.

Thanks for your answer.
That could be achieved (though not on a per file basis) with the -K
flag, but I’ve read the -K flag could become deprecated, and that magic
comments are the future. I don’t understand how comments can get such an
importance in source code, and I want to learn more because I’m
suspecting I am missing something.

Raph

4

2012/6/6 Raphael B. [email protected]:

That could be achieved (though not on a per file basis) with the -K
flag, but I’ve read the -K flag could become deprecated, and that magic
comments are the future. I don’t understand how comments can get such an
importance in source code, and I want to learn more because I’m
suspecting I am missing something.

You can’t always provide command-line options (or it might be
troublesome).

– Matma R.

5

On Wed, Jun 6, 2012 at 10:04 AM, Bartosz Dziewoński
[email protected] wrote:

2012/6/6 Raphael B. [email protected]:

That could be achieved (though not on a per file basis) with the -K
flag, but I’ve read the -K flag could become deprecated, and that magic
comments are the future. I don’t understand how comments can get such an
importance in source code, and I want to learn more because I’m
suspecting I am missing something.

You can’t always provide command-line options (or it might be troublesome).

It is also worth noting that in shell scripts (ruby use to be thought
of as a scripting language primarily)
that #!/shell/path like
#!/bin/bash

is very common in perl and other shell script languages.
So to see #utf-8 is to me more of a homage to declaring interpreter
path than anything else.
infact in a .cgi file
#!/usr/bin/ruby is perfectly valid

Andrew McElroy

6

On Thu, Jun 07, 2012 at 03:30:42AM +0900, andrew mcelroy wrote:

It is also worth noting that in shell scripts (ruby use to be thought
of as a scripting language primarily)
that #!/shell/path like
#!/bin/bash

is very common in perl and other shell script languages.
So to see #utf-8 is to me more of a homage to declaring interpreter
path than anything else.
infact in a .cgi file
#!/usr/bin/ruby is perfectly valid

I’m not entirely sure, but it looks like you’re suggesting that nobody
uses a shebang line any longer. I find that odd, considering I
constantly create new executable files that start like the following
line:

#!/usr/bin/env ruby

These are not “.cgi file” programs, either. They’re mostly sysadmin
scripts, plus occasional widely reusable command line utilities
including
a couple that come with a Ruby gem I just recently (last month) pushed
to
gemcutter for the first time. The shebang line is far from dead.

7

Andrew Mcelroy wrote in post #1063392:

On Wed, Jun 6, 2012 at 10:04 AM, Bartosz Dziewoński
[email protected] wrote:

2012/6/6 Raphael B. [email protected]:

That could be achieved (though not on a per file basis) with the -K
flag, but I’ve read the -K flag could become deprecated, and that magic
comments are the future. I don’t understand how comments can get such an
importance in source code, and I want to learn more because I’m
suspecting I am missing something.

You can’t always provide command-line options (or it might be troublesome).

It is also worth noting that in shell scripts (ruby use to be thought
of as a scripting language primarily)
that #!/shell/path like
#!/bin/bash

is very common in perl and other shell script languages.
So to see #utf-8 is to me more of a homage to declaring interpreter
path than anything else.
infact in a .cgi file
#!/usr/bin/ruby is perfectly valid

Andrew McElroy

The hashbang/shebang line is read by the current shell to know which
interpreter should be run to execute the script, and the interpreter
actually running the script ignores this line, because it is indeed a
comment for him!

The situation with the encoding comment is quite different. It is a
comment not ignored by the interpreter running the script. A semantic
comment seems an oxymoron to me, but I’m interested to know how it came
to become the preferred solution. Doesn’t it make it harder now that
ruby comments can’t be ignored semantically?

Raph

8

On Wed, Jun 6, 2012 at 6:53 AM, Raphael B. [email protected] wrote:

Thanks for your answer.
That could be achieved (though not on a per file basis) with the -K
flag, but I’ve read the -K flag could become deprecated, and that magic
comments are the future. I don’t understand how comments can get such an
importance in source code, and I want to learn more because I’m
suspecting I am missing something.

Ruby’s hardly alone in having semantically significant comments. I
seem to recall something in Java comments that has actual meaning not
just to javadoc but to the compiler (though I can’t recall what it
is).

9

On Fri, Jun 8, 2012 at 11:51 AM, Raphael B. [email protected]
wrote:

The hashbang/shebang line is read by the current shell to know which
interpreter should be run to execute the script, and the interpreter
actually running the script ignores this line, because it is indeed a
comment for him!

It’s not the current shell but one of the system calls exec* which is
invoked in the child after fork(). See section “Interpreter scripts”
at execve(2): execute program - Linux man page

Kind regards

robert