From: Bart Schaefer <schaefer@brasslantern.com>
To: Robert Elz <kre@munnari.oz.au>
Cc: Martijn Dekker <martijn@inlv.org>,
"zsh-workers@zsh.org" <zsh-workers@zsh.org>
Subject: Re: The big kre zsh bug report
Date: Fri, 21 Dec 2018 12:37:08 -0800 [thread overview]
Message-ID: <CAH+w=7ajDgcRHg6A+LXSCExq6k3sexx7aeM8U-XErV_QcbbZMg@mail.gmail.com> (raw)
In-Reply-To: <16681.1545391852@jinx.noi.kre.to>
(For some reason gmail put your reply in spam, I only found it by accident.)
On Fri, Dec 21, 2018 at 3:31 AM Robert Elz <kre@munnari.oz.au> wrote:
>
> | It seems to me that changing this for $=t in zsh native mode might
> | break a lot of things, so I'll leave it open for discussion as to
> | whether it's feasible to change it only for emulation mode. However,
> | it does differ from the most recent version of bash I have handy.
By this I meant zsh's current behavior differs from bash, so we ought
to at least consider changing it in emulation.
> From the version in the prompt string where you illustrated bash
> behaviour later, you seem to be testing against a very old bash
It's what's on CentOS 6.10.
> (though apparently bash 3 still exists in the wild).
MacOS 10.13 appears to have bash3, at least based on the prompt.
> | For the lazy or very busy reader:
> |
> | -h Locate and remember utilities invoked by functions as those
> | functions are defined (the utilities are normally located when the
> | function is executed).
>
> Yes, I know what it means.
Obviously you do, but I didn't until it was mentioned here, so I
assume the rest of the zsh-workers audience might not either.
> I cannot think of a use for it, nor have
> I ever seen any script that would ever use it, nor does anything I
> know of implement it
It doesn't even seem possible to implement sanely, unless perhaps by
freezing $PATH and putting the shell in a virtual chroot jail.
var=grep
$var "$@"
would seem to be enough to thwart it without some really elaborate
"compile time" analysis of what $var was going to yeild.
> | var='"z"'; case ${var} in (${var}) printf M;; (*) printf X;; esac
> |
> | This also prints M. If backslash-z should become a quoted z,
> | shouldn't the above case also become a quoted z?
>
> No. It all comes from the use of RE's to define how glob works
> (and the ancient implementation) - '\' quotes magic in an RE, other
> forms of shell quoting do not.
OK, that's understandable. Any situation in which given (just for
example) var='[a-z]' we interpret $var as a character class, we ought
to also when given var='\z' treat $var as a literal z.
As mentioned above about $=t for splitting, I'm not sure we can safely
apply this to $~var without changing some expected behavior, so it'll
require careful consideration.
> In native zsh mode if you want to change that to be more like csh,
> which did complain about invalid patterns, that's fine, but for emulating
> sh it really isn't.
None of the discussion of $var interpolation of '\z' in pattern
context has any relationship to the discussion about treatment of bad
patterns.
> | There isn't any --emulate bash, really, it's merly a synonym for
> | --emulate sh.
>
> In that case, I would suggest deleting it. It gives a false impression.
> bash has lots of stuff that sh does not have, how close some of that
> is to zsh native mode I have no idea.
>
> | And therefore no, it's not intended to be perfect.
>
> It depends what you're aiming for with --emulate ... if it is just so you
> can run native sh scripts, then most of this does not matter.
It's just so you can run native sh scripts. It's not intended to turn
zsh into a portability test platform. Really it's so that you can do
ln -s /bin/zsh bash
The --emulation option is just a way to talk zsh into behaving as if
$0 were changed. --emulate csh is even farther from accurate.
> | Checking for overflow here seems like a lot of computational expense for a
> | case that probably only happens in test suites. Since zsh implements arrays
> | as actual non-sparse C arrays, memory is going to explode long before
> | anything manages to assign that many positional parameters.
>
> Don't bet on it. An array with 2^32 unset elements, followed by one set
> (assuming it is implemented in a rational way) is just 8 * (2^32 + 1) bytes,
I don't recall exactly but it's probably more like double that (2^32
pointers to things representing unset elements, not 2^32 null
pointers).
Nevertheless, point taken.
next prev parent reply other threads:[~2018-12-21 20:37 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <d7b0451f90bdfe61f48cc1361690180e07158900.camel@ntlworld.com>
[not found] ` <b8851c3a50bd8bceba1961f2f764e1a6869481ac.camel@ntlworld.com>
2018-12-20 22:25 ` Martijn Dekker
2018-12-21 7:53 ` Bart Schaefer
2018-12-21 8:11 ` Fix for ${\var} oddity Bart Schaefer
2018-12-25 17:18 ` [PATCH] honour NO_UNSET when reading values in arithmetic expansion/commands Martijn Dekker
2018-12-25 20:44 ` 'wait' exit status and warnings [was: The big kre zsh bug report] Martijn Dekker
2018-12-30 18:13 ` Peter Stephenson
2019-01-21 22:53 ` Martijn Dekker
2018-12-31 2:08 ` Line continuation between $ and { " Martijn Dekker
2018-12-21 11:30 ` The big kre zsh bug report Robert Elz
2018-12-21 20:37 ` Bart Schaefer [this message]
2018-12-22 0:13 ` Robert Elz
2018-12-21 2:28 ` Robert Elz
2018-12-24 5:40 ` zsh 5.6.2-test-2 Axel Beckert
2018-12-24 7:14 ` Axel Beckert
2018-12-24 7:38 ` dana
2018-12-24 9:16 ` [PATCH] ztrftime(): Fix truncation for % dana
2018-12-24 12:45 ` Daniel Shahaf
2018-12-24 16:24 ` dana
2018-12-24 17:06 ` Daniel Shahaf
2018-12-24 17:31 ` dana
2018-12-28 22:16 ` dana
2018-12-29 9:55 ` Daniel Shahaf
2018-12-29 10:27 ` Daniel Shahaf
2018-12-29 11:02 ` dana
2018-12-29 11:08 ` Daniel Shahaf
2018-12-29 11:30 ` dana
2018-12-29 11:34 ` Daniel Shahaf
2018-12-24 23:35 ` Joey Pabalinas
2018-12-24 23:30 ` Joey Pabalinas
[not found] ` <CAKc7PVDUjo8HAdwqgRAKcgQHOzThM+hYnjX+2FKzUZB+pfmC-Q@mail.gmail.com>
[not found] ` <CAKc7PVB-agFUarJ=LqC2QNDFta1O5D_o4v-gt7LiobVDohNGVQ@mail.gmail.com>
[not found] ` <06228a6975b91f7066d0046bf912dd69fa5993a2.camel@ntlworld.com>
2018-12-31 13:44 ` zsh 4.6.2-test-2 dana
2018-12-31 15:19 ` Sebastian Gniazdowski
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='CAH+w=7ajDgcRHg6A+LXSCExq6k3sexx7aeM8U-XErV_QcbbZMg@mail.gmail.com' \
--to=schaefer@brasslantern.com \
--cc=kre@munnari.oz.au \
--cc=martijn@inlv.org \
--cc=zsh-workers@zsh.org \
/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).