cshjunkieparen bothers me (and always has)

cshjunkieparen bothers me (and always has)

[Bart Schaefer]

I realize we just hit 3.0-pre1, so this is probably a bad time to bring
this up, but ...

Cshjunkieparen got added sometime between 2.4.100 and 2.5.0.  Does anyone
remember WHY?  That is, I know why the option got added; I screamed about
it myself when the syntax it permits stopped working, so it got thrown in 
to shut me up.  But actually, the syntax I was really concerned about is

	if [[ ... ]] {
	    action
	}

which doesn't have anything at all to do with *parens*.

What I mean is, does anybody remember why you'd CARE whether that syntax
works or gives a syntax error?  The more csh-like syntax

	if ( ... ) then
	    action
	fi
or
	if [[ ... ]] then
	    action
	fi

works regardless of cshjunkieparen, and nobody ever complains about THAT,
so don't start throwing ksh compatibility around.

Furthermore, using { } as the body of an "if" isn't anything remotely like
csh, so the name of the option doesn't make any sense at all.  (If it also
enabled (and when unset, disabled) the above forms, then the name might be
slightly more sensible, but the necessity no less mystifying.)

So the only significant effect cshjunkieparen seems to have is that

	setopt cshjunkieparen
	if ( exec ... )
	...

blows away the current shell.  As this can hardly be considered desirable,
I'm having a really hard time figuring out why zsh can't simply support the
`if ( ... ) { ... }' and `if [[ ... ]] { ... }' syntax all the time, and
always have `( ... )' mean a subshell even with that syntax; and then get
rid of the cshjunkieparen option.

If ksh syntax is really the issue, then I suggest that the already-misnamed
noshortloops option be extended to prohibit the forms currently handled by
cshjunkieparen.  The syntactic shorthands are at least similar there.  (The
name of the option really should be `noshortbodies' as it isn't limited to
looping constructs.)

If we really wanted a cshjunkieparen that meant something useful, it would
mean that the parens were interpreted as [[ ... ]] like so:

	if ( $TERM == xterm ) then
	    ...
	fi

I certainly wouldn't object to that -- though you'd probably have to call
the option `cshjunkietests' now because cshjunkieparen is tainted.

I'm not suggesting that cshjunkietests be added to 3.0.0.  However, I *AM*
suggesting that cshjunkieparen be removed in favor of always supporting
the associated syntax.

-- 
Bart Schaefer                             Brass Lantern Enterprises
http://www.well.com/user/barts            http://www.nbn.com/people/lantern

New male in /home/schaefer:
>N  2 Justin William Schaefer  Sat May 11 03:43  53/4040  "Happy Birthday"

Re: cshjunkieparen bothers me (and always has)

[Bart Schaefer]

On Jun 30, 12:19am, Bart Schaefer wrote:
} Subject: cshjunkieparen bothers me (and always has)
}
} I'm having a really hard time figuring out why zsh can't simply support the
} `if ( ... ) { ... }' and `if [[ ... ]] { ... }' syntax all the time, and
} always have `( ... )' mean a subshell even with that syntax; and then get
} rid of the cshjunkieparen option.
} 
} If we really wanted a cshjunkieparen that meant something useful, it would
} mean that the parens were interpreted as [[ ... ]] like so:
} 
} 	if ( $TERM == xterm ) then
} 	    ...
} 	fi
} 
} I certainly wouldn't object to that -- though you'd probably have to call
} the option `cshjunkietests' now because cshjunkieparen is tainted.
} 
} I'm not suggesting that cshjunkietests be added to 3.0.0.  However, I *AM*
} suggesting that cshjunkieparen be removed in favor of always supporting
} the associated syntax.

Here's a patch that does just that -- removes cshjunkieparen, leaving the
associated syntax supported.  This patch also includes, but comments out,
the code to implement cshjunkietests.

No man page patch here, as I'm offering this only for consideration at
this point.

diff -c zsh-3.0-pre1/Src/globals.h zsh-3.0-pre1-work/Src/globals.h
*** zsh-3.0-pre1/Src/globals.h	Fri Jun 28 06:43:49 1996
--- zsh-3.0-pre1-work/Src/globals.h	Mon Jul  1 12:02:40 1996
***************
*** 648,654 ****
      {"correctall", 		'O', 0,   0},
      {"cshjunkiehistory", 	0,   0,   OPT_EMULATE|OPT_CSH},
      {"cshjunkieloops", 		0,   0,   OPT_EMULATE|OPT_CSH},
!     {"cshjunkieparen", 		0,   0,   OPT_EMULATE|OPT_CSH},
      {"cshjunkiequotes", 	0,   0,   OPT_EMULATE|OPT_CSH},
      {"cshnullglob", 		0,   0,   OPT_EMULATE|OPT_CSH},
      {"errexit", 		'e', 'e', 0},
--- 648,654 ----
      {"correctall", 		'O', 0,   0},
      {"cshjunkiehistory", 	0,   0,   OPT_EMULATE|OPT_CSH},
      {"cshjunkieloops", 		0,   0,   OPT_EMULATE|OPT_CSH},
! /*  {"cshjunkietests", 		0,   0,   OPT_EMULATE|OPT_CSH}, */
      {"cshjunkiequotes", 	0,   0,   OPT_EMULATE|OPT_CSH},
      {"cshnullglob", 		0,   0,   OPT_EMULATE|OPT_CSH},
      {"errexit", 		'e', 'e', 0},
diff -c zsh-3.0-pre1/Src/parse.c zsh-3.0-pre1-work/Src/parse.c
*** zsh-3.0-pre1/Src/parse.c	Fri Jun 28 06:43:50 1996
--- zsh-3.0-pre1-work/Src/parse.c	Mon Jul  1 12:03:32 1996
***************
*** 412,418 ****
  	c->args = par_wordlist();
  	if (tok != SEPER)
  	    YYERRORV;
!     } else if (tok == INPAR && (csh || isset(CSHJUNKIEPAREN))) {
  	f->inflag = 1;
  	incmdpos = 0;
  	yylex();
--- 412,418 ----
  	c->args = par_wordlist();
  	if (tok != SEPER)
  	    YYERRORV;
!     } else if (tok == INPAR) {
  	f->inflag = 1;
  	incmdpos = 0;
  	yylex();
***************
*** 599,620 ****
  	    cmdpop();
  	    YYERRORV;
  	}
! 	if (tok == INPAR && isset(CSHJUNKIEPAREN)) {
! 	    yylex();
! 	    l = par_list();
! 	    if (tok != OUTPAR) {
! 		cmdpop();
! 		YYERRORV;
! 	    }
! 	    addlinknode(ifsl, l);
! 	    ni++;
! 	    incmdpos = 1;
! 	    yylex();
! 	} else {
! 	    addlinknode(ifsl, par_list());
! 	    ni++;
! 	    incmdpos = 1;
! 	}
  	while (tok == SEPER)
  	    yylex();
  	xtok = FI;
--- 599,611 ----
  	    cmdpop();
  	    YYERRORV;
  	}
! /*
! 	if (tok == INPAR && isset(CSHJUNKIETESTS))
! 	    tok = DINBRACK;
! */
! 	addlinknode(ifsl, par_list());
! 	ni++;
! 	incmdpos = 1;
  	while (tok == SEPER)
  	    yylex();
  	xtok = FI;
***************
*** 627,633 ****
  	    nt++;
  	    incmdpos = 1;
  	    cmdpop();
! 	} else if (isset(CSHJUNKIEPAREN)) {
  	    if (tok == INBRACE) {
  		cmdpop();
  		cmdpush(nc);
--- 618,624 ----
  	    nt++;
  	    incmdpos = 1;
  	    cmdpop();
! 	} else {
  	    if (tok == INBRACE) {
  		cmdpop();
  		cmdpush(nc);
***************
*** 655,663 ****
  		incmdpos = 1;
  		break;
  	    }
- 	} else {
- 	    cmdpop();
- 	    YYERRORV;
  	}
      }
      cmdpop();
--- 646,651 ----
***************
*** 665,690 ****
  	cmdpush(CS_ELSE);
  	while (tok == SEPER)
  	    yylex();
! 	if (isset(CSHJUNKIEPAREN) && tok == INBRACE) {
! 	    yylex();
! 	    l = par_list();
! 	    if (tok != OUTBRACE) {
! 		cmdpop();
! 		YYERRORV;
! 	    }
! 	    addlinknode(thensl, l);
! 	    nt++;
! 	    yylex();
! 	} else {
! 	    l = par_list();
! 	    if (tok != FI) {
! 		cmdpop();
! 		YYERRORV;
! 	    }
! 	    addlinknode(thensl, l);
! 	    nt++;
! 	    yylex();
  	}
  	cmdpop();
      }
      i = (struct ifcmd *)make_ifcmd();
--- 653,666 ----
  	cmdpush(CS_ELSE);
  	while (tok == SEPER)
  	    yylex();
! 	l = par_list();
! 	if (tok != FI) {
! 	    cmdpop();
! 	    YYERRORV;
  	}
+ 	addlinknode(thensl, l);
+ 	nt++;
+ 	yylex();
  	cmdpop();
      }
      i = (struct ifcmd *)make_ifcmd();
***************
*** 718,732 ****
      w = c->u.whilecmd = (struct whilecmd *)make_whilecmd();
      w->cond = (tok == UNTIL);
      yylex();
!     if (tok == INPAR && isset(CSHJUNKIEPAREN)) {
! 	yylex();
! 	w->cont = par_list();
! 	if (tok != OUTPAR)
! 	    YYERRORV;
! 	yylex();
!     } else {
! 	w->cont = par_list();
!     }
      incmdpos = 1;
      while (tok == SEPER)
  	yylex();
--- 694,704 ----
      w = c->u.whilecmd = (struct whilecmd *)make_whilecmd();
      w->cond = (tok == UNTIL);
      yylex();
! /*
!     if (tok == INPAR && isset(CSHJUNKIETESTS))
! 	tok = DINBRACK;
! */
!     w->cont = par_list();
      incmdpos = 1;
      while (tok == SEPER)
  	yylex();
***************
*** 863,868 ****
--- 835,844 ----
      incmdpos = 0;
      yylex();
      c->u.cond = par_cond();
+ /*
+     if (isset(CSHJUNKIETESTS) && tok == OUTPAR)
+ 	tok = DOUTBRACK;
+ */
      if (tok != DOUTBRACK)
  	YYERRORV;
      incond = 0;
diff -c zsh-3.0-pre1/Src/zsh.h zsh-3.0-pre1-work/Src/zsh.h
*** zsh-3.0-pre1/Src/zsh.h	Fri Jun 28 06:43:52 1996
--- zsh-3.0-pre1-work/Src/zsh.h	Mon Jul  1 12:03:15 1996
***************
*** 1037,1043 ****
      CORRECTALL,
      CSHJUNKIEHISTORY,
      CSHJUNKIELOOPS,
!     CSHJUNKIEPAREN,
      CSHJUNKIEQUOTES,
      CSHNULLGLOB,
      ERREXIT,
--- 1037,1043 ----
      CORRECTALL,
      CSHJUNKIEHISTORY,
      CSHJUNKIELOOPS,
! /*  CSHJUNKIETESTS, */
      CSHJUNKIEQUOTES,
      CSHNULLGLOB,
      ERREXIT,

-- 
Bart Schaefer                             Brass Lantern Enterprises
http://www.well.com/user/barts            http://www.nbn.com/people/lantern

New male in /home/schaefer:
>N  2 Justin William Schaefer  Sat May 11 03:43  53/4040  "Happy Birthday"

Re: cshjunkieparen bothers me (and always has)

[Zoltan Hidvegi]

> Here's a patch that does just that -- removes cshjunkieparen, leaving the
> associated syntax supported.  This patch also includes, but comments out,
> the code to implement cshjunkietests.
> 
> No man page patch here, as I'm offering this only for consideration at
> this point.

I approve this without cshjunkietests since it makes the code simpler.  The
other reason is that the while list; { ... } syntax always worked.

Below is the documentation.  I do not know much about nroff so if something
is wrong in it, tell me.  I'll be away till thursday.  Than I'll release
3.0-per2.  I've already fixed most signal related bugs and made ulimit bash
compatible.

Zoltan

*** Doc/zshoptions.man	1996/06/26 08:58:31	2.12
--- Doc/zshoptions.man	1996/07/01 20:49:45
***************
*** 126,136 ****
  "\fIlist\fP; \fBend\fP" instead of
  "\fBdo\fP \fIlist\fP; \fBdone\fP".
  .TP
- \fBCSH_JUNKIE_PAREN\fP
- Allow \fBfor\fP, \fBif\fP and \fBwhile\fP loops where the argument
- list is given in parentheses.  Otherwise, the parentheses will be
- treated as specifying a subshell.
- .TP
  \fBCSH_JUNKIE_QUOTES\fP
  Complain if a quoted expression runs off the end of a line;
  prevent quoted expressions from containing unescaped newlines.
--- 126,131 ----
*** Doc/zshmisc.man	1996/06/26 08:58:31	2.8
--- Doc/zshmisc.man	1996/07/01 20:48:30
***************
*** 250,257 ****
  of \fIexp\fP.
  .SH "ALTERNATE FORMS FOR COMPLEX COMMANDS"
  .PP
! Many of zsh's complex commands have alternate forms.  These forms
! require that the option \fBCSH_JUNKIE_PAREN\fP  be set.  These particular
  versions of complex commands should be considered deprecated and may be
  removed in the future.  The versions in the previous section should be
  preferred instead.
--- 250,256 ----
  of \fIexp\fP.
  .SH "ALTERNATE FORMS FOR COMPLEX COMMANDS"
  .PP
! Many of zsh's complex commands have alternate forms.  These particular
  versions of complex commands should be considered deprecated and may be
  removed in the future.  The versions in the previous section should be
  preferred instead.
***************
*** 259,269 ****
  .RS
  .PD 0
  .TP
! \fBif\fP \fB(\fP \fIlist\fP \fB) {\fP
  .TP
  \fIlist\fP
  .TP
! \fB} elif (\fP \fIlist\fP \fB) {\fP
  .TP
  \fIlist\fP
  .TP
--- 258,272 ----
  .RS
  .PD 0
  .TP
! \fBif\fP \fIlist\fP
! .TP
! \fB{\fP
  .TP
  \fIlist\fP
  .TP
! \fB} elif \fIlist\fP
! .TP
! \fB{\fP
  .TP
  \fIlist\fP
  .TP
***************
*** 273,286 ****
  .TP
  \fB}\fP
  .PD
! An alternate form of \fBif\fP.  The parentheses surrounding \fIlist\fP
! can be omitted if the only command in the list is a conditional expression
! of the form [[ exp ]].
  .PP
  .PD 0
  .TP
! \fBif (\fP \fIlist\fP \fB)\fP \fIsublist\fP
! A shorter form of previous one.
  .PD
  .PP
  .PD 0
--- 276,290 ----
  .TP
  \fB}\fP
  .PD
! An alternate form of \fBif\fP.
  .PP
  .PD 0
  .TP
! \fBif\fP \fIlist\fP
! .TP
! \fIsublist\fP
! A shorter form of previous one which only works in \fBNO_SHORT_LOOPS\fP
! is not set.
  .PD
  .PP
  .PD 0
***************
*** 297,307 ****
  .TP
  \fBfor\fP \fIname\fP \fB(\fP \fIword\fP ... \fB) \fIsublist\fP
  .PD
! A shorter form of the previous one.
  .PP
  .PD 0
  .TP
! \fBwhile (\fP \fIlist\fP \fB) {\fP
  .TP
  \fIlist\fP
  .TP
--- 301,314 ----
  .TP
  \fBfor\fP \fIname\fP \fB(\fP \fIword\fP ... \fB) \fIsublist\fP
  .PD
! A shorter form of the previous one which only works in \fBNO_SHORT_LOOPS\fP
! is not set.
  .PP
  .PD 0
  .TP
! \fBwhile\fP \fIlist\fP
! .TP
! \fB{\fP
  .TP
  \fIlist\fP
  .TP

Re: cshjunkieparen bothers me (and always has)

[Anthony Heading]

Zoltan wrote:
> I approve this without cshjunkietests since it makes the code simpler.  The
> other reason is that the while list; { ... } syntax always worked.
> 
> Below is the documentation [...]

> ! Many of zsh's complex commands have alternate forms.  These particular
>   versions of complex commands should be considered deprecated and may be
>   removed in the future.  The versions in the previous section should be
>   preferred instead.

If this syntax is being developed, it seems weird that it's deprecated.  Does
anyone really want to get rid of it?   If so, fine.  But if the sentiment is
that these forms should be available without setting options, shouldn't they:
  a) be supported;
  b) not be advised against in the manual?

It seems a pity not to make the most of this useful feature.

Anthony

Re: cshjunkieparen bothers me (and always has)

[Bart Schaefer]

On Jul 1, 11:02pm, Zoltan Hidvegi wrote:
} Subject: Re: cshjunkieparen bothers me (and always has)
}
} Below is the documentation.  I do not know much about nroff so if something
} is wrong in it, tell me.

Looks OK to me.

On Jul 1, 10:35pm, Anthony Heading wrote:
} Subject: Re: cshjunkieparen bothers me (and always has)
}
} > ! Many of zsh's complex commands have alternate forms.  These particular
} >   versions of complex commands should be considered deprecated and may be
} >   removed in the future.  The versions in the previous section should be
} >   preferred instead.
} 
} If this syntax is being developed, it seems weird that it's deprecated.

The syntax isn't really being developed (except for my cshjunkietests
suggestion, which I put forth because I used to be a csh junkie).  What
has happened is that a special case to *reject* an otherwise reasonable
syntax has been *removed*; this is deconstruction, not construction.

} Does anyone really want to get rid of it?

Just before 2.5.0 was released, there was a big push among some of the zsh
maintainers to remove csh-like features from zsh in favor of faithfully
emulating ksh.  That faction no longer seems so vocal, probably because
zsh is now a more complete superset of ksh, so the fact that some extra
non-ksh syntax is available is less noticeable.

} If so, fine.  But if the sentiment is that these forms should be
} available without setting options

That isn't quite an accurate depiction.  These forms work for the same
reason that this kind of thing works:

	if true ; ; ; then
	    echo bash or ksh would give a syntax error on ';'
	fi

Zsh permits things like empty commands in a "list" syntax element and
other unambiguous combinations because it makes for a simpler parser.
It's actually more work in most cases to reject it than to accept it.

} shouldn't they:
}   a) be supported;
}   b) not be advised against in the manual?

I'd be all in favor of that.

-- 
Bart Schaefer                             Brass Lantern Enterprises
http://www.well.com/user/barts            http://www.nbn.com/people/lantern

New male in /home/schaefer:
>N  2 Justin William Schaefer  Sat May 11 03:43  53/4040  "Happy Birthday"

Re: cshjunkieparen bothers me (and always has)

[Peter Stephenson]

schaefer@candle.brasslantern.com wrote:
> } I'm having a really hard time figuring out why zsh can't simply support the
> } `if ( ... ) { ... }' and `if [[ ... ]] { ... }' syntax all the time, and
> } always have `( ... )' mean a subshell even with that syntax; and then get
> } rid of the cshjunkieparen option.
> 
> Here's a patch that does just that -- removes cshjunkieparen, leaving the
> associated syntax supported.

I have a vague feeling there were things which later got moved to
CSH_JUNKIE_PAREN because they caused some problem with some strange sh
syntax.  However, the patch looks fairly clean and I can't see how any
valid sh syntax would fail.  Maybe the expedient of treating (..) and
{..} the usual way has fixed things up.  If I was more energetic I
would look back in the list archive.

> } If we really wanted a cshjunkieparen that meant something useful, it would
> } mean that the parens were interpreted as [[ ... ]] like so:
> } 
> } 	if ( $TERM == xterm ) then
> } 	    ...
> } 	fi

I've got lost along the way somewhere.  I thought CSH_JUNKIE_PAREN
(which I originally wrote some time ago) was once supposed to do that?
Otherwise what was the big deal?  If zsh has never treated the
parentheses as a test, why was it advertised as a csh-compatibility
feature?  If it did, why was it taken out?

-- 
Peter Stephenson <pws@ifh.de>       Tel: +49 33762 77366
WWW:  http://www.ifh.de/~pws/       Fax: +49 33762 77330
Deutches Electronen-Synchrotron --- Institut fuer Hochenergiephysik Zeuthen
DESY-IfH, 15735 Zeuthen, Germany.

Re: cshjunkieparen bothers me (and always has)

[Bart Schaefer]

On Jul 2, 10:48am, Peter Stephenson wrote:
} Subject: Re: cshjunkieparen bothers me (and always has)
}
} I have a vague feeling there were things which later got moved to
} CSH_JUNKIE_PAREN because they caused some problem with some strange sh
} syntax.  However, the patch looks fairly clean and I can't see how any
} valid sh syntax would fail.  Maybe the expedient of treating (..) and
} {..} the usual way has fixed things up.

Yes, I think that's it -- sh syntax would be broken if the (...) were
not treated as a subshell.  But there's no reason not to treat it as
a subshell, so ...

} > } If we really wanted a cshjunkieparen that meant something useful, it would
} > } mean that the parens were interpreted as [[ ... ]] like so:
} > } 
} > } 	if ( $TERM == xterm ) then
} > } 	    ...
} > } 	fi
} 
} I've got lost along the way somewhere.  I thought CSH_JUNKIE_PAREN
} (which I originally wrote some time ago) was once supposed to do that?

No, zsh hasn't ever interpreted parens that way.

} Otherwise what was the big deal?  If zsh has never treated the
} parentheses as a test, why was it advertised as a csh-compatibility
} feature?

I *think* this is what happened:

Cshjunkieparen at one time affected whether

	if [[ $TERM == xterm ]] then

would work.  This was the csh compatibility feature, even though it
wasn't precisely csh syntax.  I have no idea why "paren" was used in
the name of the option.

However, par_list() now permits empty statements, consuming all trailing
SEPER tokens; so by necessity par_if() no longer requires a SEPER before
the "then".

Thus the above began working even without cshjunkieparen, rendering
cshjunkieparen useless.

-- 
Bart Schaefer                             Brass Lantern Enterprises
http://www.well.com/user/barts            http://www.nbn.com/people/lantern

New male in /home/schaefer:
>N  2 Justin William Schaefer  Sat May 11 03:43  53/4040  "Happy Birthday"

Re: cshjunkieparen bothers me (and always has)

[Zoltan Hidvegi]

> I *think* this is what happened:
> 
> Cshjunkieparen at one time affected whether
> 
> 	if [[ $TERM == xterm ]] then
> 
> would work.  This was the csh compatibility feature, even though it
> wasn't precisely csh syntax.  I have no idea why "paren" was used in
> the name of the option.

This syntax is really a ksh compatibility syntax.  But by a more general
rure it is a POSIX compatibility syntax.  POSIX does not requires separator
before then so the syntax

if (subshell ...) then

should be accepted by a POSIX shell.  The accepted syntax is

if compound_list then compound_list fi

So

if true ; false ; true ; then echo yes ; fi

is valid, and should print yes.  The semicolon before then is necessary
to recognize then as a reserved word.

POSIX also states that reserved words are recognized after one of the
reserved words other than case, for, or in.  In ksh [[ and ]] are reserved
words so it is not necessary to use a semicolon before then (in zsh [[ is
not a reserved word but it behaves similarily).

> However, par_list() now permits empty statements, consuming all trailing
> SEPER tokens; so by necessity par_if() no longer requires a SEPER before
> the "then".

POSIX does not seem to allow that but the zsh behaviour is more logical.
The biggest problem using braces instead of then ... fi is the following:

if (true)
{ echo yes; }

The patch I posted recently to the manual says that it is equivalent to

if (true)
then
	echo yes
fi

But that's not true since par_list parses a list as long as it is possible
so the above is the same as

if (true) ; { echo yes; }

And now a then or an open brace should come after some semicolons.  I think
csh junkies do not like that change.

if true {
	echo yes
}

does not work either since { behaves like a reserved word (POSIX says that
{ and } should be reserved words).

if (true) {
	echo yes
}

works since a separator must come after a subshell so par_list could not
continue parsing of the list.

if [[ foo -eq 13 ]] {
	echo yes
}

and

if ((foo == 13)) {
	echo yes
}

works for similar reasons.  As it turns out { can only be used in place of
if when it comes after a ) terminating a subshell or a ]] terminating a
conditional command.  When csh_junkie_paren was on zsh digested an open
parenthesis before calling par_list which terefore stopped before the
matching closing parenthesis.  To summarize this after Bart's patch the

if (foo)
{
	...
}

syntax will not work but the

if (foo) {
	...
}

syntax still works.

Zoltan

Re: cshjunkieparen bothers me (and always has)

[Bart Schaefer]

On Jul 4,  3:14pm, Zoltan Hidvegi wrote:
> Subject: Re: cshjunkieparen bothers me (and always has)
>
> > I *think* this is what happened:
> > 
> > Cshjunkieparen at one time affected whether
> > 
> > 	if [[ $TERM == xterm ]] then
> > 
> > would work.  This was the csh compatibility feature, even though it
> > wasn't precisely csh syntax.  I have no idea why "paren" was used in
> > the name of the option.
> 
> This syntax is really a ksh compatibility syntax.  But by a more general
> rure it is a POSIX compatibility syntax.

That may be, but there wasn't any such thing as `POSIX compatibility' (at
least within zsh) at the time that it was originally introduced as csh
compatibility.

> The biggest problem using braces instead of then ... fi is the following:
> 
> if (true)
> { echo yes; }
> 
> The patch I posted recently to the manual says that it is equivalent to
> 
> if (true)
> then
> 	echo yes
> fi
> 
> But that's not true since par_list parses a list as long as it is possible
> so the above is the same as
> 
> if (true) ; { echo yes; }
> 
> And now a then or an open brace should come after some semicolons.  I think
> csh junkies do not like that change.

I don't think csh junkies care one way or the other.  C junkies might,
but braces are not a command-grouping syntax in csh EXCEPT in exactly
one circumstance:

	#! /bin/csh
	if { something } then
	    echo something succeeded
	endif

I.e., in "if" (and possibly "while", I forget) statements, using braces
instead of parens is equivalent to:

	#! /bin/csh
	something
	if ( $status == 0 ) then
	    echo something succeeded
	endif

> if true {
> 	echo yes
> }
> 
> does not work either since { behaves like a reserved word (POSIX says that
> { and } should be reserved words).

That's equivalent to passing '{' as an argument to 'true', which is fine.
No problem with that either from a csh junkie standpoint; you can't omit
the parens in csh.  I note that this works:

	if { true } {
	    echo yes
	}

> To summarize this after Bart's patch the
> 
> if (foo)
> {
> 	...
> }
> 
> syntax will not work

But that in turn means that

	if [[ -f foo ]]
	{
	    ...
	}

has never worked, or at least hasn't worked for quite some time.  (Boy,
sometimes I wish my old machine with the 2.0.0 zsh on it hadn't died.)
In any case, I think this bit of consistency is worthwhile.


-- 
Bart Schaefer                             Brass Lantern Enterprises
http://www.well.com/user/barts            http://www.nbn.com/people/lantern

New male in /home/schaefer:
>N  2 Justin William Schaefer  Sat May 11 03:43  53/4040  "Happy Birthday"