Fedora 31 and Debian 10 behaves different when I run the following command:

/bin/ls /bin/!(znew) | /bin/grep znew

Fedora it outputs nothing, but Debian it does:


znew exists on Fedora, if I run /bin/ls /bin/znew | /bin/grep znew I get:


(On Debian it happens the same thing)

I've checked bash configuration on both distros, the only difference I've found is that on Fedora I have:

cdable_vars     on
cdspell         on
dirspell        on
login_shell     on

On Debian those options are disabled, and extglob is on on both distros

Note: Command grep it's only used here to make the listing shorter


  • On Fedora: 5.0.11

  • On Debian: 5.0-4

Why does it exist such a difference?


/bin is a symlink to /usr/bin on both Debian and Fedora.

This is the output of searching for znew string in filenames:

updatedb && locate  znew


I've find something interesting, there was in Debian a symlink of /bin/X11 pointing to . after removing it behaves as in Fedora.


1 Answer 1


Given that the extglob shell option is set in your interactive bash session, the command

ls /bin/!(znew) | grep znew

would first run ls with all the names in /bin that is not znew as arguments. If this list of names includes names of subdirectories, ls would output the contents of those subdirectories (since -d was not used with ls). If one of these subdirectories contain the name znew, then the grep would match and output that name.

The contents of the unknown subdirectory of /bin would be listed by ls without prepending the names in it with any directory path. Hence, if a subdirectory contains the znew name, it would be outputted as znew rather than as /bin/some-dir/znew.

When ls is used as in

ls /bin/znew | grep znew

it would output the string /bin/znew rather than znew (if that pathname exists). It does this because it is outputting the specific pathname of a file given as a command line argument, not the contents of a directory given as an argument.

A situation like this could possibly have occurred if someone tried to create a symbolic link for /usr/bin called /bin while /bin was already a symbolic link to /usr/bin, or while /bin was still a directory.

In an update to the question, it is revealed that /bin/X11 was a symbolic link to . (the current directory). This means that znew would have been accessible through the pathname /bin/X11/znew.

So, in conclusion, what is happening is that the /bin/!(znew) globbing pattern expanded to a list of pathnames, one of these being /bin/X11 (but not /bin/znew). The ls utility would then get all pathnames, including /bin/X11 as arguments. When ls gets to list /bin/X11, the contents of the /bin directory is listed, due to /bin/X11 pointing there. The grep utility then picks out znew, which will part of the output of ls.

As Stéphane Chazelas points out in comments, you would get the same effect if there is a file in /bin on your Debian system that has a name containing a newline followed by the string znew (possibly followed by another newline and maybe further characters).

Since the name is not exactly the string znew, it would match the pattern /bin/!(znew) and ls would output this single name as

maybe more

and grep would extract znew from that output.

  • 2
    Another possible (though also unlikely) explanation could be that there's a $'/bin/whatever\nznew' file in /bin May 8, 2020 at 7:14
  • 1
    An explanation that sounds likely is that /bin contains a symlink to itself or /usr/bin like if someone did a ln -s /usr/bin /bin whilst /bin was already there. May 8, 2020 at 11:38
  • @StéphaneChazelas Good one! I forgot some Linuxes have this symbolic link, and it sounds plausible that an admin might have intended to set this up on the Debian system, but failed (or didn't clean up a failed attempt).
    – Kusalananda
    May 8, 2020 at 11:39
  • In any case that can't by a problem with bash globs as if !(znew) failed not to match on znew, you would get /bin/znew as output, not just znew. May 8, 2020 at 11:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .