From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from primenet.com.au (ns1.primenet.com.au [203.24.36.2]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id c05df1b1 for ; Thu, 31 Jan 2019 14:10:29 +0000 (UTC) Received: (qmail 18701 invoked by alias); 31 Jan 2019 14:10:18 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: List-Unsubscribe: X-Seq: 44028 Received: (qmail 26874 invoked by uid 1010); 31 Jan 2019 14:10:18 -0000 X-Qmail-Scanner-Diagnostics: from mailout1.w1.samsung.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.100.2/25112. spamassassin: 3.4.2. Clear:RC:0(210.118.77.11):SA:0(-7.0/5.0):. Processed in 4.66394 secs); 31 Jan 2019 14:10:18 -0000 X-Envelope-From: p.stephenson@samsung.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | DKIM-Filter: OpenDKIM Filter v2.11.0 mailout1.w1.samsung.com 20190131140011euoutp0165030cdf8ed384b5608384f8858eb11f~_86T4sIur0112701127euoutp01Y DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1548943211; bh=G1TD75clblmdJoQKnCBbnsvVw2uC9mcUk2HDD4bUCyg=; h=Subject:From:To:Date:In-Reply-To:References:From; b=CiQZYdNau8fs/4piVVdLVTQJkdUI6TQkfCP1wAFDH4jemswsetaA+natQ5rN/aM9I OUUbCDq1uVipKO8cwHPwOhcGTZUPqLx0uutLdxgRJ/DrAPuyFqVVbGO0usb2/weUlP b1Hln2nc5k4GWoWSnmlAwy/FT6aiWBdMtkTNSUoA= X-AuditID: cbfec7f4-c77a99c0000010c6-da-5c52ff6af809 Message-ID: <1548943208.4543.1.camel@samsung.com> Subject: Re: zsh function declaration bug From: Peter Stephenson To: Date: Thu, 31 Jan 2019 14:00:08 +0000 In-Reply-To: <730BA7F6-5BE4-419D-838E-457B43F93B90@dana.is> X-Mailer: Evolution 3.18.5.2-0ubuntu3.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDIsWRmVeSWpSXmKPExsWy7djP87pZ/4NiDN5cs7A42PyQyYHRY9XB D0wBjFFcNimpOZllqUX6dglcGdfXpBRsl6hY3nqSrYFxh3AXIyeHhICJxOPJHWwgtpDACkaJ K/uyuxi5gOw+JonHT9tYIJxeJom1bc+ZYTomtr+BSixnlHh/ajoTXFXvopfMEM4ZRolzD1ay QzgXGCWW/pgG5HBw8AoYSlxaJAAySlhAU+LAvpMsIDYbUHjqptmMILaIgKTEtebTYDaLgKrE x46tbCCtnALWEu+Oq0NcoSGx4eYxJhCbV0BQ4uTMJ2BjmAXkJZq3zga7QULgMZvEvpbzbBAN LhLr9m9lhLCFJV4d38IOYctInJ7cwwLR0M4osWbSa3YIp4dRYtPRO1Ad1hJ9ty8yglzBDHT1 +l36EGFHiQUzW1hAwhICfBI33gpCHMEnMWnbdGaIMK9ER5sQRLWaxI6mrYwQYRmJp2sUJjAq zULywSwkH8xCWLWAkXkVo3hqaXFuemqxUV5quV5xYm5xaV66XnJ+7iZGYBo4/e/4lx2Mu/4k HWIU4GBU4uHd8CsoRog1say4MvcQowQHs5IIr9QDoBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXHe aoYH0UIC6YklqdmpqQWpRTBZJg5OqQbGkvbCN7JfThzoKN2kzxG1Uv75nM6I2z2Ku48tMFTI v+84/caVdlau1waO75Y/jT+ddYl1VuIEb2fVxV7zquP6jZX/zL0eMOmNvX+mULyfwsE0advT wWu2G61Z/a6ijbF5/1zGF3c8phcGCQbxHvuSlHRWMSspNvbwFIeMeywZ+3KsT6X0TW1VYinO SDTUYi4qTgQA+BIo8/8CAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPLMWRmVeSWpSXmKPExsVy+t/xu7qZ/4NiDM40mFscbH7I5MDoserg B6YAxig9m6L80pJUhYz84hJbpWhDCyM9Q0sLPSMTSz1DY/NYKyNTJX07m5TUnMyy1CJ9uwS9 jOtrUgq2S1Qsbz3J1sC4Q7iLkZNDQsBEYmL7G5YuRi4OIYGljBK/T3xlgUjISHy68pEdwhaW +HOtiw2iqJtJ4uzfu+wQzhlGiQ0rGqAyFxglbixaCJTh4OAVMJS4tEgApFtYQFPiwL6TYFPZ gMJTN81mBLFFBCQlrjWfBrNZBFQlPnZsZQNp5RSwlnh3XB0kLCRwnVFi5xNNEJsZaEzr9t9Q B2lIbLh5jAnE5hUQlDg58wkLRI28RPPW2cwTGIVmIWmZhaRsFpKyBYzMqxhFUkuLc9Nziw31 ihNzi0vz0vWS83M3MQIDf9uxn5t3MF7aGHyIUYCDUYmHd8OvoBgh1sSy4srcQ4wSHMxKIrxS D4BCvCmJlVWpRfnxRaU5qcWHGE2B/pnILCWanA+MyrySeENTQ3MLS0NzY3NjMwslcd7zBpVR QgLpiSWp2ampBalFMH1MHJxSDYxct90XduQWPm9cxL/25ec+k0vHF26PfR3dGe6Reifne8vX cztMPHhjJx/TrQqMnPMiddmCKfUHzswMV7SuX8vu6FunfHlSpk1k63o5ZesdLRdXb31jdNl8 whbfqTUr47xzvNjE9tjesdmv+bbOU3hajI7c/ndN9To39rh4MCXlV4UkH7LZPk2JpTgj0VCL uag4EQBRBr4gkgIAAA== X-CMS-MailID: 20190131140010eucas1p1fe2af416ac44ca96e23fdcabfe151b61 X-Msg-Generator: CA Content-Type: text/plain; charset="utf-8" X-RootMTR: 20190131131207epcas2p27decb7ffcef2380d75e134ff512293bf X-EPHeader: CA CMS-TYPE: 201P X-CMS-RootMailID: 20190131131207epcas2p27decb7ffcef2380d75e134ff512293bf References: <730BA7F6-5BE4-419D-838E-457B43F93B90@dana.is> On Thu, 2019-01-31 at 07:11 -0600, dana wrote: > On 30 Jan 2019, at 11:46, Mitchell Gildenberg wrote: > > > > ➜ mgild $ l(){ echo "hello"} > > zsh: defining function based on alias `ls' > > zsh: parse error near `()' > Presumably you have an alias l=ls, which is being expanded because the l in > l() { ... } is considered to be in command position. workers/40300 made this > an error by default, since the expansion behaviour is generally unexpected > > If you don't need the l alias, you can just unalias it. Otherwise it will > work with the function key word like you said, or if you put the definition in > a file rather than entering it at the command line. But i'm guessing you don't > actually want an alias and a function with the same name anyway Yes, this is described in the FAQ, quoted at the bottom (it lives in the source distribution in the Etc directory, or at http://zsh.sourceforge.net/FAQ/).  This was written before you got the error message when this happened. The new error is basically there to tell you "you don't want to do this".  The old behaviour --- silently defining functions based on aliases --- was almost never what you wanted. pws There is one other serious problem with aliases: consider     alias l='/bin/ls -F'     l() { /bin/ls -la "$@" | more }   `l' in the function definition is in command position and is expanded   as an alias, defining `/bin/ls' and `-F' as functions which call   `/bin/ls', which gets a bit recursive.  This can be avoided if you use   `function' to define a function, which doesn't expand aliases.  It is   possible to argue for extra warnings somewhere in this mess. One workaround for this is to use the "function" keyword instead:     alias l='/bin/ls -F'     function l { /bin/ls -la "$@" | more }   The `l' after `function' is not expanded.  Note you don't need   the `()' in this case, although it's harmless. You need to be careful if you are defining a function with multiple   names; most people don't need to do this, so it's an unusual problem,   but in case you do you should be aware that in versions of the shell   before 5.1 names after the first were expanded:     function a b c { ... }   Here, `b' and `c', but not `a', have aliases expanded.   This oddity was fixed in version 5.1. The rest of this item assumes you use the (more common,   but equivalent) `()' definitions. Bart Schaefer's rule is:  Define first those aliases you expect to   use in the body of a function, but define the function first if the   alias has the same name as the function. If you aware of the problem, you can always escape part or all of the   name of the function:      'l'() { /bin/ls -la "$@" | more }   Adding the quotes has no effect on the function definition, but   suppresses alias expansion for the function name.  Hence this is   guaranteed to be safe---unless you are in the habit of defining   aliases for expressions such as 'l', which is valid, but probably   confusing.