Path: csiph.com!au2pb.net!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!news.glorb.com!usenet.stanford.edu!not-for-mail From: Chet Ramey Newsgroups: gnu.bash.bug Subject: Re: minor language RFE(s) Date: Thu, 8 Oct 2015 14:05:17 -0400 Organization: ITS, Case Western Reserve University Lines: 32 Approved: bug-bash@gnu.org Message-ID: References: <5615ACEF.4040804@tlinx.org> <56168F51.1010207@case.edu> <5616AC52.2030601@tlinx.org> Reply-To: chet.ramey@case.edu NNTP-Posting-Host: lists.gnu.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Trace: usenet.stanford.edu 1444327697 24659 208.118.235.17 (8 Oct 2015 18:08:17 GMT) X-Complaints-To: action@cs.stanford.edu Cc: Andreas Schwab , chet.ramey@case.edu To: Linda Walsh , bug-bash Envelope-to: bug-bash@gnu.org User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 In-Reply-To: <5616AC52.2030601@tlinx.org> X-Junkmail-Whitelist: YES (by domain whitelist at mpv2.tis.cwru.edu) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 129.22.105.37 X-BeenThere: bug-bash@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports for the GNU Bourne Again SHell List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Xref: csiph.com gnu.bash.bug:11592 On 10/8/15 1:48 PM, Linda Walsh wrote: >> The arithetic `for' command takes arithmetic expressions, not shell >> commands, and the `for' command takes a name (identifier), not a >> shell command. Aside from any syntactic sugar (`int', `my'), these >> are not consistent with how the shell grammar is formed, and this >> isn't a good enough reason to change the grammar that dramatically. > --- > Yeah, I think I mentioned that case: > > I've no idea of the difficulty level to do this, but > was thinking if not too difficult... and if it is... > well keep it on a pile of ideas if bash ever got > refactored such that implementation became easier..? > > I understand the problems of working with 10+ year old code > that's been patched through the roof and trying to add _anything_ > to the design. Thus the proposal of keeping the idea around > if bash was ever refactored such that implementing a change like > this wouldn't be a big deal.... You misunderstand. The implementation difficulty, such as it is, is secondary to whether or not changing the grammar like that is a good idea in the first place. I don't think it is, and I don't think that adding syntactic sugar is a compelling reason to change that. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRU chet@case.edu http://cnswww.cns.cwru.edu/~chet/