From: Roman Perepelitsa <roman.perepelitsa@gmail.com>
To: Bart Schaefer <schaefer@brasslantern.com>
Cc: Zsh Users <zsh-users@zsh.org>
Subject: Re: A way to untie -T vars?
Date: Tue, 24 Jan 2023 18:54:47 +0100 [thread overview]
Message-ID: <CAN=4vMor55C9c4vw3vaKzfyx8KuWxMoproVzZ01o2HXGiJzr3g@mail.gmail.com> (raw)
In-Reply-To: <CAH+w=7YYJJxDyFZ20ZJ6FwtFzrsCyHb8tNkMNxBQqWSHRNBfpw@mail.gmail.com>
On Tue, Jan 24, 2023 at 6:41 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> On Tue, Jan 24, 2023 at 8:45 AM Peter Stephenson
> <p.w.stephenson@ntlworld.com> wrote:
> >
> > > On 24/01/2023 16:42 Bart Schaefer <schaefer@brasslantern.com> wrote:
> > > I don't think we're going to have any guarantied parameters. :-)
> > > Guaranteed, maybe.
> >
> > "Use of shell language by users voids guarantee".
>
> There are only 14 words containing "tied" in /usr/share/dict/words on
> my desktop, and a quick scan of words ending in "ty|tie" doesn't yield
> many that can be "tied", and none except "untied" seem likely to ever
> apply.
There is also "array", "scalar" and "left" in the code with a similar
assumption about the future keywords.
If I were writing this code, I would change it without computing
probabilities because it feels wrong to me. I've learned this specific
pitfall a long time ago and since then it jumps out at me when I see
it in someone's code. The fix is fairly simple and would make the code
more explicit, hence easier to understand. It'll be clear that we are
checking for "left" and not for any keyword that contains "left".
Right now I actually don't know what that line does and if there are
keywords that contain "left" but aren't equal to it.
Roman.
next prev parent reply other threads:[~2023-01-24 18:05 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-21 16:37 Sebastian Gniazdowski
2023-01-21 16:55 ` Bart Schaefer
2023-01-21 17:11 ` Bart Schaefer
2023-01-21 18:52 ` Bart Schaefer
2023-01-21 19:15 ` Roman Perepelitsa
2023-01-22 9:34 ` Pier Paolo Grassi
2023-01-22 9:58 ` Roman Perepelitsa
2023-01-23 2:14 ` Bart Schaefer
2023-01-23 9:47 ` Roman Perepelitsa
2023-01-23 18:27 ` Bart Schaefer
2023-01-23 18:42 ` Mikael Magnusson
2023-01-23 18:43 ` Mikael Magnusson
2023-01-23 19:12 ` Bart Schaefer
2023-01-24 5:45 ` Bart Schaefer
2023-01-24 9:56 ` Roman Perepelitsa
2023-01-24 16:42 ` Bart Schaefer
2023-01-24 16:45 ` Peter Stephenson
2023-01-24 17:40 ` Bart Schaefer
2023-01-24 17:54 ` Roman Perepelitsa [this message]
2023-01-24 22:54 ` Bart Schaefer
2023-01-25 14:41 ` Roman Perepelitsa
2023-01-25 22:39 ` Bart Schaefer
2023-01-25 23:48 ` Bart Schaefer
2023-01-26 2:34 ` Bart Schaefer
2023-01-21 17:15 ` Roman Perepelitsa
2023-01-21 17:23 ` Bart Schaefer
2023-01-21 17:31 ` Bart Schaefer
2023-01-21 17:48 ` Roman Perepelitsa
2023-01-21 17:50 ` Bart Schaefer
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='CAN=4vMor55C9c4vw3vaKzfyx8KuWxMoproVzZ01o2HXGiJzr3g@mail.gmail.com' \
--to=roman.perepelitsa@gmail.com \
--cc=schaefer@brasslantern.com \
--cc=zsh-users@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).