From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-return-43320-mason-zsh=primenet.com.au@zsh.org>
Received: (qmail 27913 invoked by alias); 20 Aug 2018 17:21:25 -0000
Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
List-Id: Zsh Workers List <zsh-workers.zsh.org>
List-Post: <mailto:zsh-workers@zsh.org>
List-Help: <mailto:zsh-workers-help@zsh.org>
List-Unsubscribe: <mailto:zsh-workers-unsubscribe@zsh.org>
X-Seq: 43320
Received: (qmail 28681 invoked by uid 1010); 20 Aug 2018 17:21:25 -0000
X-Qmail-Scanner-Diagnostics: from rcpt-mqugw.biglobe.ne.jp by f.primenet.com.au (envelope-from <takimoto-j@kba.biglobe.ne.jp>, uid 7791) with qmail-scanner-2.11 
 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1.  
 Clear:RC:0(133.208.100.2):SA:0(-2.6/5.0):. 
 Processed in 1.605448 secs); 20 Aug 2018 17:21:25 -0000
X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW,
	SPF_PASS autolearn=ham autolearn_force=no version=3.4.1
X-Envelope-From: takimoto-j@kba.biglobe.ne.jp
X-Qmail-Scanner-Mime-Attachments: |
X-Qmail-Scanner-Zip-Files: |
X-Biglobe-Sender: <takimoto-j@kba.biglobe.ne.jp>
From: "Jun T." <takimoto-j@kba.biglobe.ne.jp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: bug report about zsh
Date: Tue, 21 Aug 2018 02:20:46 +0900
References: <CAJbOvNxbshEc=YMe5BKUYfM7k3BGfWh=z8Jw7Acw5GnWRuTw_w@mail.gmail.com>
To: zsh-workers@zsh.org
In-Reply-To: <CAJbOvNxbshEc=YMe5BKUYfM7k3BGfWh=z8Jw7Acw5GnWRuTw_w@mail.gmail.com>
Message-Id: <F96F21D1-EB8D-44C1-B7F2-B57B883ADB4A@kba.biglobe.ne.jp>
X-Mailer: Apple Mail (2.3273)
X-Biglobe-Spnum: 62182


> 2018/08/20 10:56, air azure <blucmt@gmail.com> wrote:
> 
> Mount sshfs from an ipv6 server, on zsh you input
> sshfs xxxx@[yyyy:yy::yy]:/zzz ~/remote
> 
> zsh report back
> zsh: no matches found: xxxx@[yyyy:yy::yy]:/zzz

[1] (reply to azure) This is not a bug:
As you know, '[...]' on the command line is considered as a
file name generation pattern (glob pattern) like '*' and '?'.
Consider, for example, a pattern f[aio]x. If there are files
named 'fax', 'fix' or 'fox' then the pattern is replaced by
(a list of) those file names. But if none of the files exists
then (by default) bash leaves the pattern as is, i.e.,
    echo f[aio]x
will print 'f[aio]x', while zsh gives 'no match found' warning.
You can change this default behavior by
    zsh% unsetopt nomatch

But it would be better to escape the pattern, as
    zsh% sshfs 'xxxx@[yyyy:yy::yy]:/zzz' ~/remote
or
    zsh% sshfs xxxx@\[yyyy:yy::yy\]:/zzz ~/remote

[2] But (to zsh workers)
The current completion function for the sshfs command does not
work well with numeric IPv6 addresses. For example, If we use
    zsh% zstyle ':completion:*:sshfs:*:accounts' users-hosts \
                 'foo@12.34.56.78' 'bar@[12:34::5678]'
then
    zsh% sshfs f<TAB>
works but
    zsh% sshfs b<TAB>
does not. This is due to the option -s '[:@]' passed to
_combination in _user_at_host.

Do we need to fix this? If so, then how? Can we just remove
the ':' from the pattern [:@] ?