From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9315 invoked by alias); 14 Mar 2012 23:20:08 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 16887 Received: (qmail 2443 invoked from network); 14 Mar 2012 23:20:06 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED,RCVD_IN_DNSWL_LOW, T_DKIM_INVALID autolearn=no version=3.3.2 Received-SPF: pass (ns1.primenet.com.au: SPF record at _spf.google.com designates 74.125.82.171 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kwZlnc27yYujUn5PkKvaiCBzG2LowZiK9OmUhl+iaDg=; b=LUnAaaOHorfpVQJOpnLt3LRkOhwuy0MGTcrQR0PNDkmIuGxXqWPZ1svw7mvLWw5yGg quSFxOCxPYjV76icRA9Aj3uf1Yi7VSVsGl/WTH95R56Yj3tvBBHprQBeVe4D0flIANZq rPp9oSJJcdR7Dfd/LhTFrQAu2i9ISEm5GkyhWsVs6Y4mQ4GCx0v+hhZw2CEmu7OdrYlJ 1RCxFXYel9WMb0s288BZoZargrALtbJkQspsm1JvmWXUhg8GquBx5BPonMqC8JC0HlUY FYoo5JjiX7lZ6DbB4zp8uWI4wCIR8QzhNXztPbQGbNv6tzzG8DeSp1vvWrFWvuG22aap VJ7g== MIME-Version: 1.0 In-Reply-To: <20120314222918.3a0330b7@tormoz-pc> References: <3d1c765788f2c6b89b58beae6b318b54@foo.asia-king.co.uk> <20120314222918.3a0330b7@tormoz-pc> Date: Thu, 15 Mar 2012 00:19:58 +0100 Message-ID: Subject: Re: Why is this happening in zsh? From: =?UTF-8?Q?Damien_Th=C3=A9bault?= To: Heorhi Valakhanovich Cc: zsh-users@zsh.org Content-Type: text/plain; charset=UTF-8 On Wed, Mar 14, 2012 at 20:29, Heorhi Valakhanovich wrote: > This happens in many command processors. I usually use quotes like > > fossil --ignore "*.class" > > This is not a solution but usual workaround. Actually, I would say that it is a solution, and not a workaround. Here is an example with the find command to explain my point of view. Let's say you want to find files in this tree: ./file1.class ./folder1/file2.class ./folder1/file2.txt ./folder2/file3.class ./folder2/file3.txt Let see in bash: $ find -name *.class ./file1.class $ find -name *.txt ./folder2/file3.txt ./folder1/file2.txt In zsh: % find -name *.class ./file1.class % find -name *.txt zsh: no matches found: *.txt We can see that in bash, the first command and the second command are not doing the same thing: "find -name *.class" is expanded to [find] [-name] [file1.class] "find -name *.txt" is not expanted and gives [find] [-name] [*.txt] In zsh, both lines are processed the same way: "find -name *.class" is expanded to [find] [-name] [file1.class] "find -name *.txt" does not match anything and returns an error. Obviously, only the second command in bash is giving the expected result (find all files with a given extension), in zsh you don't get any result and the first command is not giving the expected result in both shells. To avoid erroneous results like the first command, the wildcard must be escaped so that it is always sent without modification to the find command, like this: $ find -name "*.class" ./file1.class ./folder2/file3.class ./folder1/file2.class or $ find -name \*.class ./file1.class ./folder2/file3.class ./folder1/file2.class Escaping the pattern ensures that the command will receive the expected pattern, you get the following in both bash and zsh: "find -name \*.class" is expanded to [find] [-name] [*.class] Not escaping the pattern is a bad habit that will give unexpected results once in a while (like the example above), so I would say that zsh's default behavior is good because it makes people understand how it works and avoid those mistakes. As it was said before, it's possible to activate the broken bash behavior in zsh, but I don't think that it's a good solution. Regards, -- Damien Thebault