1. 11

  2. 7

    The rationale motivating this hack is good; I wonder if tree couldn’t be “fixed” upstream, though.

    1. 5

      One alternative to tree is broot.

      1. 5

        This sparked a distant memory of an admin I worked with that recompiled nslookup so quit worked for exiting.

        1. 3

          I do not want to be too negative nor sound condescending. But OP is just confused about his shell syntax and named parameter passing conventions/traditions.

          The pipe is interpreted as an Unix pipe by the shell. There is absolutely nothing to fix on the tree utility on that regard. OP should absolutely read about quoting on his shell manual and use it.

          Parameter parsing also does what is expected. Assembling a list by passing the same parameter many times is by no means the expected nor logical behaviour.

          1. 4

            There is at least one other GNU tool I can think of off the top of my head that builds a list when passed the same flag multiple times. Namely, GCC’s search path can be extended by passing -I<dir> any number of times.

            Personally, I think it’s reasonable to complain about how a tool’s interface interacts with the shell it’s used in. Bash is, after all, also a GNU tool.

            1. 3

              Hi, OP here!

              Yes, accepting the same arg several times to build up a list is a pattern we see also elsewhere, but don’t expect consistency from command line args, ever! For example, gcc will accept stuff like -Iblah with no space between flag and directory, but GNU tree insists on having a space between the flag and the pattern.

          2. 2

            I’ve grown used to ls -lR (recursive listing) when on remote boxes without tree installed. Quite useful, but it took me a while to grok the output. It also has an -I flag, although I haven’t really used it.

            1. 2

              I use find which by default acts like an ugly version of tree. I don’t think it has an ignore option, but I tend to use grep to filter out what I want, rather than cutting out what I don’t want.

              1. 1


                find ~/src -name "*.php" -not -path "*-backup*"
                1. 1

                  One thing that tends to bite me is that the default behavior works until I use -prune, whereupon I have to start specifying -print to get it to do what I want. So I too often pipe through grep instead.

                  1. 1

                    Same here. The man page tells me that find is very powerful, but all that power is only applicable to one tool. find | grep .md$ is much easier (for me at least) and covers pretty much everything I ever want to do.

                2. 1

                  give fd a look as a nice find replacement

                  1. 2

                    I suppose I could, but I don’t use any features of find beyond typing find, so getting used to a non-standard tool for that seems a bit of a waste. Thanks for the suggestion, though!