zsh-users
 help / color / Atom feed
From: "Daniel Shahaf" <d.s@daniel.shahaf.name>
To: zsh-users@zsh.org
Cc: "Frank Gallacher" <franxg@gmail.com>
Subject: Re: Use of == in functions
Date: Sun, 12 Jan 2020 13:58:43 +0000
Message-ID: <69a81ce1-245b-478c-bd43-08a5ad7aa7fa@www.fastmail.com> (raw)
In-Reply-To: <20200112120353.snhivqosevvv526a@chaz.gmail.com>

Stephane Chazelas wrote on Sun, 12 Jan 2020 12:03 +00:00:
> [repost to zsh-users. I'll see if I can add a mutt hook to avoid
> the problem in the future].
> 
> 2020-01-12 11:09:06 +0100, Kusalananda Kähäri:
> [...]
> > == within [[ ]]
> > =  within [   ]
> > 
> > ... just like in bash (but bash allows its built in test/[ utility to
> > understand == too)
> [...]
> 
> zsh's [ builtin also supports == as an alias of = (like its [[
> ]] construct also supports == as an alias of =), but in zsh,
> =cmd is an operator that expands to the path of the cmd command,
> 
> $ echo =ls
> /usr/bin/ls
> 
> so you would need:
> 
> [ a '==' b ]
> 
> (or disable the =cmd feature with set +o equals) if for some
> reason you wanted to use the non-standard == in place of =.
> 
> Just like you need
> 
> [ a '=~' regex ]
> 
> for regex matching.
> 
> And
> 
> [ a '<' b ]
> 
> to compare strings lexically as < is also a redirection
> operator.
> 
> Now, as none of <, ==, =~ are standard [ operators (so sh
> compatibility is no longer a good reason to use the "["
> command), you might as well use the ksh-style [[...]] construct
> which doesn't have this kind of issue:
> 
> [[ a =~ b ]], [[ a < b ]], [[ a == b ]] are all fine (but then
> again, there's no need to double the =. == is an operator that
> is needed in languages where there's a need to disambiguate
> between assignment and equality comparison, but inside [[...]]
> (as opposed to ((...)) for instance), there's no assignment)

The reason for the difference between «[ x == y ]» and «[[ x == y ]]» is
that [ is a _builtin_, so it's parsed using the same rules as any random
external command, whereas [[ is a _reserved word_, part of the syntax,
like '&&', so the normal command line syntax rules don't apply within
it.  This is also why «[[ -n foo && -n bar ]]» works

      reply index

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-12  8:34 Frank Gallacher
2020-01-12 10:09 ` Kusalananda Kähäri
2020-01-12 10:33   ` SUMMARY " Frank Gallacher
     [not found] ` <20200112100906.GA95942__47727.4053309642$1578823915$gmane$org@pooh.prefix.duckdns.org>
2020-01-12 12:03   ` Stephane Chazelas
2020-01-12 13:58     ` Daniel Shahaf [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=69a81ce1-245b-478c-bd43-08a5ad7aa7fa@www.fastmail.com \
    --to=d.s@daniel.shahaf.name \
    --cc=franxg@gmail.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

zsh-users

Archives are clonable: git clone --mirror http://inbox.vuxu.org/zsh-users

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.zsh.users


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git