zsh-workers
 help / color / mirror / code / Atom feed
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.

  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).