comments, newlines

comments, newlines

[schwartz]

Consider this rc script:

x=(1 \
#  2 \
   3)

Using Byron's rc, this gets a syntax error.  Does Tom Duff's rc behave
similarly?   This doesn't seem like useful behavior to me: it makes it
too hard to use comments in a natural way.

Re: comments, newlines

[haahr]

the reason that
	x=(1 \
	#  2 \
	   3)
doesn't work is straightforward interpretation of rc's rules for continued  
lines and comments.  the first \+newline sequence results in the parser  
seeing
	x=(1 #  2 \
	3)
which seems reasonable.  now the question becomes, ``are backslash-newline  
sequences in comments ignored or treated as continuation sequences?''  rc  
currently implements comments by ignoring *everything* until the end of  
line.  the simplicity of this rule argues for not changing it.

two further comments:
	i don't find the ability to insert a comment in the middle of a
		sequence of lines continued with \ important
	i have no idea what td's rc does for this

Re: comments, newlines

[David J. Fiander]

>From:  haahr@adobe.com
>lines and comments.  the first \+newline sequence results in the parser  
>seeing
>	x=(1 #  2 \
>	3)
>which seems reasonable.  now the question becomes, ``are backslash-newline  
>sequences in comments ignored or treated as continuation sequences?''  rc  
>currently implements comments by ignoring *everything* until the end of  
>line.  the simplicity of this rule argues for not changing it.

The way in which the rule is interpreted doesn't matter.  If
\+nl is interpreted even in comments, then the shell will see

	x=(1 # 2 3)

and ignore everything after the '#' and _still_ complain about
a syntax error.

- David

Re: comments, newlines

[John Mackin]

I agree with Paul.  The rule doesn't need to be changed.  In fact, I think
it definitely should NOT be, since I think it makes scripts significantly
harder to read if comments are inserted inside continued commands.

But:

    The way in which the rule is interpreted doesn't matter.  If
    \+nl is interpreted even in comments, then the shell will see

    	x=(1 # 2 3)

This doesn't make sense.  The rule is, ignore everything between #
and newline, INCLUDING THE #.  I mean, if you go

echo foo # bar

you get "foo", not "foo #".  So if backslash were to be interpreted
at the end of a comment, that wouldn't happen, and it would all work.

And now for my real reason for sending this: there is one thing about
# that I have never liked.  I have complained privately about this (long
ago), but Byron didn't agree with me: so let's see if we can get some
public support for _this_ idea.

I claim that # should only be seen as a comment introducer if it is
preceded by whitespace or at the start of the line.  So if you do

echo foo#bar

you should, in my view, get "foo#bar".  You do in sh.  You don't in rc:
Byron thinks # should introduce a comment even if it is in the middle
of a word.  I think this is plainly wrong.  Opinions?

OK,
John.

RE: comments, newlines

[Dave Mason]

> From: John (I've got some bad news for you, sunshine) Mackin <john@vetsci.su.oz.au>
> Date: Fri, 13 Mar 1992 05:14:22 -0500

> I claim that # should only be seen as a comment introducer if it is
> preceded by whitespace or at the start of the line.  So if you do
> 
> echo foo#bar
> 
> you should, in my view, get "foo#bar".  You do in sh.  You don't in rc:
> Byron thinks # should introduce a comment even if it is in the middle
> of a word.  I think this is plainly wrong.  Opinions?

Why should it be special?  What's wrong with
	echo foo'#'bar
?  It's not as if octothorpe is exactly the most common character, and I
think it's actually harder for people to parse by your rules, as they have
to consider the context of whether it is preceeded by whitespace.

As for
	a=( 1 \
	# 2\
	3)

Either:
	a=( 1 3)
or:
	a=( 1 #2	---- error

Seem reasonable (in the second one you'd actually get a second error from
the ``3)'').  I can see the former as being handy, and the latter as being
consistent and simple.  I vote for consistent and simple.  I can see no
justification for the interpretation:
	a=( 1 # 2 3)	---- error

	../Dave

Re: comments, newlines

[Emin G. Sirer]

>From: Dave Mason <dmason@plg.waterloo.edu>
>Subject: RE: comments, newlines 
>Date: Fri, 13 Mar 1992 16:44:35 -0600
>
>> From: John (I've got some bad news for you, sunshine) Mackin
>> Date: Fri, 13 Mar 1992 05:14:22 -0500
>
>> I claim that # should only be seen as a comment introducer if it is
>> preceded by whitespace or at the start of the line.  So if you do
>> 	echo foo#bar
>> you should, in my view, get "foo#bar".  You do in sh.  You don't in rc:
>> Byron thinks # should introduce a comment even if it is in the middle
>> of a word.  I think this is plainly wrong.  Opinions?
>
>Why should it be special? 

	Because almost all the other metacharacters are 'special' in some
way or another. For example, echo f* (or f[a-c]*) will either expand 
(if there are matching files in .) or stay as it is. I think that that 
behaviour is very strange, and even unjustifiable. No part of shell 
behaviour should depend on the environment (i.e. current working directory).
I think csh's the only one that's got it right (gasp).
	Talking about strangeness, how do you explain to someone the bizarre
parenthesis behaviour ? They seem to introduce lists one-minute (a=(a b c))
and seem to mark the clauses to the while and if statements the next.
	'Special' is not the right word. All these characters are already 
special anyway (look in lexer.c; they are called special characters). The
key thing is whether the rules governing their use make sense. I, for one,
find the parenthesis usage very natural. The rule is that they delimit 
lists unless they follow while or if, when they delimit clauses (thus
we don't see code like 'while true echo foo;' I think it is much more 
desirable that we use 'while(true) echo foo'). The rule for '#' should 
be that it introduces comments iff it is preceded by whitespace, else 
it's a regular character.
	And the kind of change we're talking about here only involves a 
trivial change in the lexer.

> What's wrong with
>	echo foo'#'bar

	What's wrong with
		lpr -Gr2 -#3 foo.ps
	? Why doesn't it print anything ? Do you really prefer
		lpr -Gr2 -'#'3 foo.ps
	? Is that better syntax ? Is it more readable ?

>It's not as if octothorpe is exactly the most common character, and I
>think it's actually harder for people to parse by your rules, as they have
>to consider the context of whether it is preceeded by whitespace.

	A lot of the lexical analysis (not parsing) is done in a context
sensitive manner; what's the big deal ?

	I think sh behaviour is more desirable given that the rule is
very simple (both to remember and to implement); so much so that
remembering to escape the number sign is much harder than keeping
the rule in mind (in fact, you don't even have to). Simplicity does
not mean cumbersome notation.

Gun.

Re: comments, newlines

[James Matthew Farrow]

I am in favour of John's view.  I always getting caught by special
characters ([=~#]) always being special and having to quote them which
makes commands look really ugly and less readable sometimes.  For
example, the 

    	What's wrong with
    		lpr -Gr2 -#3 foo.ps
    	? Why doesn't it print anything ? Do you really prefer
    		lpr -Gr2 -'#'3 foo.ps
    	? Is that better syntax ? Is it more readable ?
	
that Emin mentioned.

					Matty.

Re: comments, newlines

[schwartz]

| I am in favour of John's view.  I always getting caught by special
| characters ([=~#]) always being special and having to quote them which
| makes commands look really ugly and less readable sometimes. 

The only such character I've had problems with is '='.  Rc and make are
like  csh and uucp. :-) 

But back to lists... Wouldn't it be nice if this were legal?

	x=(1
	   2
	   3)

(no backslashes) Then you could easily comment out parts.