Your message dated Wed, 16 Dec 2015 20:39:52 +0100 with message-id <[email protected]> and subject line Re: Bug#808064: tree: Output incorrect if certain filenames are detected. has caused the Debian Bug report #808064, regarding tree: Output incorrect if certain filenames are detected. to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 808064: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=808064 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: tree Version: 1.7.0-3 Severity: important Dear Maintainer, I hope this came out right, I used "bugreport" but it was unable to send. I had to dig around in exim to find this and send it manually via gmail. Output is incorrect if index.txt file is present in the filesystem being scanned. Actually the extention of the index file can probably be anything (I came across this issue with html files) The bug is easy to reproduce and I have seen it on Debian / OSX and CYGWIN. You can paste the following to see the issue (I included the output of tree to demonstrate, you need to not paste that.) mkdir TESTING cd TESTING mkdir test1 mkdir test2 mkdir test3 touch test1/file.txt touch test2/file.txt touch test3/file.txt touch file.txt #This is as expected, for comparison tree -P *.txt . ├── file.txt ├── test1 │ └── file.txt ├── test2 │ └── file.txt └── test3 └── file.txt 3 directories, 4 files touch index.txt #Here I expect the same result as above + 1 extra file listed tree -P *.txt index.txt [error opening dir] 0 directories, 0 files mv file.txt index.txt #Again I expect the same as the first result but with the 1 extra file tree -P *.txt . ├── index.txt ├── test1 ├── test2 └── test3 3 directories, 1 file -- System Information: Debian Release: 8.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.16.0-4-586 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages tree depends on: ii libc6 2.19-18+deb8u1 tree recommends no packages. tree suggests no packages. -- no debconf information
--- End Message ---
--- Begin Message ---Hello Ben, thank you for your report. However, what you have experienced is not actually a bug but rather a combination of certain features with a somewhat confusing - at first - net result. Please allow me to detail below: On Tue, Dec 15, 2015 at 04:53:57PM +0000, Ben Burrows wrote: > [...] > mkdir TESTING > cd TESTING > mkdir test1 > mkdir test2 > mkdir test3 > touch test1/file.txt > touch test2/file.txt > touch test3/file.txt > touch file.txt Thanks for this easy-to-reproduce test case. I'll start just like that. > #This is as expected, for comparison > tree -P *.txt > . > ├── file.txt > ├── test1 > │ └── file.txt > ├── test2 > │ └── file.txt > └── test3 > └── file.txt > > 3 directories, 4 files Yes, this is as expected, given this structure. That is to say, here certain features don't distort the outcome. But let's check the next: > touch index.txt > #Here I expect the same result as above + 1 extra file listed > tree -P *.txt > index.txt [error opening dir] > > 0 directories, 0 files What happens here is that first the executing command shell expands the given wildcard (per default in alphanumerical order), so in effect this command now reads tree -P file.txt index.txt which translates into "list all files (and only those) named 'file.txt' below a directory named 'index.txt'" which in turn yields the correct error message "index.txt [error opening dir]" as indeed there isn't any such directory that could possibly be opened. What you need here is to forbid your command shell from prematurely expanding the wildcard by enclosing it in (single or double) quotes: fernst@fernst:~/TESTING$ tree -P '*.txt' . ├── file.txt ├── index.txt ├── test1 │ └── file.txt ├── test2 │ └── file.txt └── test3 └── file.txt 3 directories, 5 files and violà, the same result as above + 1 extra file listed. > mv file.txt index.txt > #Again I expect the same as the first result but with the 1 extra file > tree -P *.txt > . > ├── index.txt > ├── test1 > ├── test2 > └── test3 > > 3 directories, 1 file Here, shell wildcard expansion turns this into tree -P index.txt and this actually translates into "list all files (and only those) named 'index.txt' below the current directory". Note: you can '--prune' empty directories from the result list if so inclined, and achieve the desired result again by quoting the wildcard: fernst@fernst:~/TESTING$ tree -P *.txt --prune . └── index.txt 0 directories, 1 file fernst@fernst:~/TESTING$ tree -P '*.txt' . ├── index.txt ├── test1 │ └── file.txt ├── test2 │ └── file.txt └── test3 └── file.txt 3 directories, 4 files And coming back to your first example, this was expanded into tree -P file.txt which translates into "list all files (and only those) named 'file.txt' below the current directory", and tree then does just that, which exactly matches what you get when you actually protect the wildcard from your shell and thus allow tree to expand it. So, all in all: "It's not a bug, it's a feature." ;-) Accordingly, I'm now closing this bugreport with this mail. Please see "Shell Patterns" in "man dash" or "Pathname Expansion" in "man bash" as well as the surrounding paragraphs for all the gory details. HTH, Flo
signature.asc
Description: PGP signature
--- End Message ---
