zsh-workers
 help / color / mirror / code / Atom feed
From: "Bart Schaefer" <schaefer@candle.brasslantern.com>
To: zsh-workers@math.gatech.edu
Subject: cshjunkieparen bothers me (and always has)
Date: Sun, 30 Jun 1996 00:19:32 -0700	[thread overview]
Message-ID: <960630001936.ZM9764@candle.brasslantern.com> (raw)

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"



             reply	other threads:[~1996-06-30  7:34 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1996-06-30  7:19 Bart Schaefer [this message]
1996-07-01 19:19 ` Bart Schaefer
1996-07-01 21:02   ` Zoltan Hidvegi
1996-07-01 21:35     ` Anthony Heading
1996-07-02  1:03       ` Bart Schaefer
1996-07-02  8:48   ` Peter Stephenson
1996-07-02 19:35     ` Bart Schaefer
1996-07-04 13:14       ` Zoltan Hidvegi
1996-07-04 15:58         ` Bart Schaefer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=960630001936.ZM9764@candle.brasslantern.com \
    --to=schaefer@candle.brasslantern.com \
    --cc=schaefer@nbn.com \
    --cc=zsh-workers@math.gatech.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).