zsh-workers
 help / color / mirror / code / Atom feed
From: Martijn Dekker <martijn@inlv.org>
To: zsh-workers@zsh.org
Subject: Re: [doc] "sh_word_split nothing to do with word splitting"?
Date: Mon, 26 Mar 2018 20:11:49 +0200	[thread overview]
Message-ID: <3da133f5-197b-aa50-7827-f24085b5b192@inlv.org> (raw)
In-Reply-To: <20180325064254.GA5782@chaz.gmail.com>

Op 25-03-18 om 08:42 schreef Stephane Chazelas:
> There have been many cases where POSIX have specified accidents
> of implementation or design bugs of original implementations and
> the POSIX specification has been fixed later on when spotted
> even in some cases forcing the original implementation to be
> fixed.
> 
> IMO, here, it's clearly one of those. The solution here is not to
> implement the bug but fix the specification.

By that token, global field splitting and globbing themselves are
massive design flaws (which they are -- as you know I've been working on
a cross-shell way to make it practical to get rid of them).

Yet, POSIX shells conform, at least in their respective POSIX modes.

At least the current spec is consistent. All POSIX expansions are
subject to global split & glob (unless those are disabled).

Why would $( ... ) be subject to split+glob but not $(( ... ))? That
would be a bit confusing, and would detract from quoting expansions
consistently.

I think consistent and broken is better than inconsistent and broken.

> There are many "unspecified areas" in POSIX where it's the case,
> if you rely on unspecified behaviour you can't expect anything
> portably.

I don't see that as a reason to add yet another unspecified behaviour.
In practice we'd be stuck with it for a decade anyway, maybe two.

To rephrase myself, I think specified and broken is better than
unspecified and broken.

> In the mean time, we should document the difference so it's no
> longer "mysterious" like in my  suggested patch.

Yes, but what wonderful planet do you live on, where people actually
read documentation? :)

>> Then pdksh, supposedly a ksh88 clone, failed to clone ksh88 in that
>> aspect -- among many others.
> [...]
> 
> pdksh has fixed a number of issues in ksh88 (itself broken on
> many aspects as you've found out) as well. Another one shared
> with zsh: that the ".*" glob does not include "." nor ".." (in
> the case of pdksh actually inherited from the Forsyth shell).

I don't really see that as a fix though, just as another mostly
pointless difference causing incompatibility surprises. ksh93 matches
'.' and '..' to this day.

On zsh, it looks like another emulation bug. The SH_GLOB option should
cause ".*" to match "." and "..".

(Actually, modernish ought to detect this as a shell quirk with its own
ID. Thanks for reminding me of it.)

- M.


      reply	other threads:[~2018-03-26 18:11 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-11  9:44 Stephane Chazelas
2018-03-11 18:24 ` Bart Schaefer
2018-03-11 20:53   ` Stephane Chazelas
2018-03-11 23:41     ` Martijn Dekker
2018-03-12  7:43       ` Stephane Chazelas
2018-03-12  8:07         ` Stephane Chazelas
2018-03-16 17:26           ` Stephane Chazelas
2018-03-16 18:28             ` Bart Schaefer
2018-03-16 19:33               ` Stephane Chazelas
2018-03-24 20:17         ` Martijn Dekker
2018-03-25  6:42           ` Stephane Chazelas
2018-03-26 18:11             ` Martijn Dekker [this message]

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=3da133f5-197b-aa50-7827-f24085b5b192@inlv.org \
    --to=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).