Re: cshjunkieparen bothers me (and always has)

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

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"