combine the best of 'du' and 'tree'












15















I'm wondering if we can combine the honesty of 'du' with the indented formatting of 'tree'. If I want a listing of the sizes of directories:



du -hx -d2


...displays two levels deep and all the size summaries are honest, but there's no indenting of subdirs. On the other hand:



tree --du -shaC -L 2


...indents and colorizes nicely however the reported sizes are a lie. To get the real sizes one must:



tree --du -shaC


...which is to say that you only get the true sizes if you let 'tree' show you the entire directory structure. I'd like to be able to always have correct size summaries regardless of how many levels of subdirs I want to actually display. I often do this:



tree -du -shaC | grep "[01;34m"


... which prunes out everything but directories, and indents them nicely ... but there's no easy way to limit the display to just a given number levels (without the summaries lying). Is there a way? Perhaps I've missed the correct switches ...










share|improve this question





























    15















    I'm wondering if we can combine the honesty of 'du' with the indented formatting of 'tree'. If I want a listing of the sizes of directories:



    du -hx -d2


    ...displays two levels deep and all the size summaries are honest, but there's no indenting of subdirs. On the other hand:



    tree --du -shaC -L 2


    ...indents and colorizes nicely however the reported sizes are a lie. To get the real sizes one must:



    tree --du -shaC


    ...which is to say that you only get the true sizes if you let 'tree' show you the entire directory structure. I'd like to be able to always have correct size summaries regardless of how many levels of subdirs I want to actually display. I often do this:



    tree -du -shaC | grep "[01;34m"


    ... which prunes out everything but directories, and indents them nicely ... but there's no easy way to limit the display to just a given number levels (without the summaries lying). Is there a way? Perhaps I've missed the correct switches ...










    share|improve this question



























      15












      15








      15


      4






      I'm wondering if we can combine the honesty of 'du' with the indented formatting of 'tree'. If I want a listing of the sizes of directories:



      du -hx -d2


      ...displays two levels deep and all the size summaries are honest, but there's no indenting of subdirs. On the other hand:



      tree --du -shaC -L 2


      ...indents and colorizes nicely however the reported sizes are a lie. To get the real sizes one must:



      tree --du -shaC


      ...which is to say that you only get the true sizes if you let 'tree' show you the entire directory structure. I'd like to be able to always have correct size summaries regardless of how many levels of subdirs I want to actually display. I often do this:



      tree -du -shaC | grep "[01;34m"


      ... which prunes out everything but directories, and indents them nicely ... but there's no easy way to limit the display to just a given number levels (without the summaries lying). Is there a way? Perhaps I've missed the correct switches ...










      share|improve this question
















      I'm wondering if we can combine the honesty of 'du' with the indented formatting of 'tree'. If I want a listing of the sizes of directories:



      du -hx -d2


      ...displays two levels deep and all the size summaries are honest, but there's no indenting of subdirs. On the other hand:



      tree --du -shaC -L 2


      ...indents and colorizes nicely however the reported sizes are a lie. To get the real sizes one must:



      tree --du -shaC


      ...which is to say that you only get the true sizes if you let 'tree' show you the entire directory structure. I'd like to be able to always have correct size summaries regardless of how many levels of subdirs I want to actually display. I often do this:



      tree -du -shaC | grep "[01;34m"


      ... which prunes out everything but directories, and indents them nicely ... but there's no easy way to limit the display to just a given number levels (without the summaries lying). Is there a way? Perhaps I've missed the correct switches ...







      disk-usage tree






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Oct 25 '15 at 1:55









      terdon

      129k32253428




      129k32253428










      asked Oct 25 '15 at 1:39









      Ray AndrewsRay Andrews

      7403825




      7403825






















          5 Answers
          5






          active

          oldest

          votes


















          6














          Also checkout ncdu:
          http://dev.yorhel.nl/ncdu



          Its page also lists other "similar projects":




          gt5 - Quite similar to ncdu, but a different approach.



          tdu - Another small ncurses-based disk usage visualization utility.



          TreeSize - GTK, using a treeview.



          Baobab - GTK, using pie-charts, a treeview and a treemap. Comes with GNOME.



          GdMap - GTK, with a treemap display.



          Filelight - KDE, using pie-charts.



          KDirStat - KDE, with a treemap display.



          QDiskUsage - Qt, using pie-charts.



          xdiskusage - FLTK, with a treemap display.



          fsv - 3D visualization.



          Philesight - Web-based clone of Filelight.







          share|improve this answer



















          • 1





            Thanks David, finally got around to looking at those. I picked ncdu.

            – Ray Andrews
            Nov 18 '15 at 1:20











          • @David where does tdu come from ?

            – shirish
            Jan 27 '17 at 21:10











          • @shirish Refer to my source, noted above

            – David Potočnik
            Mar 30 '17 at 16:49



















          8














          You don't need to grep for the colour code, the -d option is list directories only.



          This seems to do what you want:



          $ tree --du -d -shaC | grep -Ev '(  *[^ ]* ){2}['
          .
          ├── [ 18] dir1
          ├── [ 30] dir2
          ├── [ 205] junk
          │   ├── [ 18] dir1
          │   ├── [ 30] dir2
          │   └── [ 76] dir3
          ├── [ 119] merge
          └── [ 20] stuff

          4.4K used in 10 directories


          The grep command removes all lines that have (one or more spaces followed by a non-space followed by a space) twice, followed by a [.



          If you want a depth of 1, change the bound count inside the {} curly braces to {1} rather than {2}. same if you want a depth of 3, change it to {3}.



          You can turn this into a shell function, like so:



          mytreedu() {
          local depth=''

          while getopts "L:" opt ; do
          case "$opt" in
          L) depth="$OPTARG" ;;
          esac
          done

          shift "$((OPTIND-1))"

          if [ -z "$depth" ] ; then
          tree --du -d -shaC "$@"
          else
          local PATTERN='( *[^ ]* ){'"$depth"'}['
          tree --du -d -shaC "$@" | grep -Ev "$PATTERN"
          fi
          }


          This uses getopts to "steal" any -L option and its argument from the tree command line, if there is one. If there isn't a -L n option on the command line, then that works too.



          All other options and args are passed to the tree command.



          The local PATTERN=... line isn't really necessary. I only did it like that to make sure that it would fit on one line and not word-wrap here on U&L. The regular expression could and probably should just go directly on the tree | grep ... line.



          Run it like this:



          mytreedu 


          or



          mytreedu -L 2 /path/to/dir/





          share|improve this answer





















          • 1





            I love the code, but repeat that you can't use the '-d' because if you do, the size summaries are incorrect, or at least they are here. The size will be reported always as '4096' which is the size of the entry for the dir itself, but not the size of all it's contents.

            – Ray Andrews
            Oct 25 '15 at 15:41











          • ... should have said '4096' for each directory under the current directory ... but you don't get the sizes of the dir including it's files.

            – Ray Andrews
            Oct 25 '15 at 15:48











          • you only mentioned -L as being a problem, didn't mention -d at all. Now that I look more closely at the numbers reported, neither tree --du nor tree --du -d report sizes that in any way resemble those reported by du.

            – cas
            Oct 25 '15 at 19:47











          • Point being that anything less than a 100% display will not give you correct sizes. You could limit via '-d' or '-L 2' or whatever else--it it isn't shown, it isn't counted in the size.

            – Ray Andrews
            Oct 26 '15 at 0:17











          • tree --du doesn't seem to give correct sizes for directories anyway, with or without -d or -L. I have no idea what the numbers are supposed to be, but they're unrelated to what du reports.

            – cas
            Oct 26 '15 at 0:30



















          1














          You can use dutree



          enter image description here




          • coloured output, according to the LS_COLORS environment variable.

          • display the file system tree

          • ability to aggregate small files

          • ability to exclude files or directories

          • ability to compare different directories

          • fast, written in Rust






          share|improve this answer































            0














            Inspired by cas, I'm now doing this:



            treee ()
            {
            integer levels=$(( ($1 + 1) * 4 ))
            tree --du -shaC | grep "[01;34m" | grep -Ev "^[^{$levels}[*"
            du -sh .
            }





            share|improve this answer
























            • if you're going to throw away all the getopts stuff, you should at least still have "$@" immediately after the -shaC. otherwise that function is hard-coded to work for the current directory only.

              – cas
              Oct 25 '15 at 19:50











            • Once we got the thing working, I was going to ask you about that: please elaborate. Right about "$@" of course, but so far I only ever use it in the current dir, so haven't noticed that yet. All this 'getopts' stuff is new to me, I'd like to know what you are thinking there.

              – Ray Andrews
              Oct 26 '15 at 0:14











            • One of the benefits of using getopts is that options can appear in any order on the command line. The initial version of the mytree function I wrote used "$1" just as yours did, so the depth argument had to be the first argument, and it was not optional. I decided that wasn't good enough so used the bash-builtin getopts to process the -L option. This allowed the -L n option to appear anywhere on the command line. It also allowed it to be completely optional.

              – cas
              Oct 26 '15 at 0:24











            • another way of looking at it is that getopts allows you to write scripts that take real options and arguments (rather than just args in hard-coded positions like $1 $2 $3 etc), just like most other programs on your system. And if you use the getopt program (note that's without an s) from the util-linux package you can use both short single-letter options (e.g. -l) and long options (like --long) just like GNU programs.

              – cas
              Oct 26 '15 at 0:26













            • Ah ... it comes back to me now. Yes, I actually used that once. Must take another look at it. Thanks.

              – Ray Andrews
              Oct 26 '15 at 6:54



















            0














            There isn't any perfect command tool to do this, But I found two ways that are closly.





            • shows both folders and files' size, but not showing in a tree mode.



              du -ah --max-depth=1 /var/log




            • shows in tree mode but only files' size, the folders are in counts



              tree -ah /var/log -L 1








            share|improve this answer























              Your Answer








              StackExchange.ready(function() {
              var channelOptions = {
              tags: "".split(" "),
              id: "106"
              };
              initTagRenderer("".split(" "), "".split(" "), channelOptions);

              StackExchange.using("externalEditor", function() {
              // Have to fire editor after snippets, if snippets enabled
              if (StackExchange.settings.snippets.snippetsEnabled) {
              StackExchange.using("snippets", function() {
              createEditor();
              });
              }
              else {
              createEditor();
              }
              });

              function createEditor() {
              StackExchange.prepareEditor({
              heartbeatType: 'answer',
              autoActivateHeartbeat: false,
              convertImagesToLinks: false,
              noModals: true,
              showLowRepImageUploadWarning: true,
              reputationToPostImages: null,
              bindNavPrevention: true,
              postfix: "",
              imageUploader: {
              brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
              contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
              allowUrls: true
              },
              onDemand: true,
              discardSelector: ".discard-answer"
              ,immediatelyShowMarkdownHelp:true
              });


              }
              });














              draft saved

              draft discarded


















              StackExchange.ready(
              function () {
              StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f238455%2fcombine-the-best-of-du-and-tree%23new-answer', 'question_page');
              }
              );

              Post as a guest















              Required, but never shown

























              5 Answers
              5






              active

              oldest

              votes








              5 Answers
              5






              active

              oldest

              votes









              active

              oldest

              votes






              active

              oldest

              votes









              6














              Also checkout ncdu:
              http://dev.yorhel.nl/ncdu



              Its page also lists other "similar projects":




              gt5 - Quite similar to ncdu, but a different approach.



              tdu - Another small ncurses-based disk usage visualization utility.



              TreeSize - GTK, using a treeview.



              Baobab - GTK, using pie-charts, a treeview and a treemap. Comes with GNOME.



              GdMap - GTK, with a treemap display.



              Filelight - KDE, using pie-charts.



              KDirStat - KDE, with a treemap display.



              QDiskUsage - Qt, using pie-charts.



              xdiskusage - FLTK, with a treemap display.



              fsv - 3D visualization.



              Philesight - Web-based clone of Filelight.







              share|improve this answer



















              • 1





                Thanks David, finally got around to looking at those. I picked ncdu.

                – Ray Andrews
                Nov 18 '15 at 1:20











              • @David where does tdu come from ?

                – shirish
                Jan 27 '17 at 21:10











              • @shirish Refer to my source, noted above

                – David Potočnik
                Mar 30 '17 at 16:49
















              6














              Also checkout ncdu:
              http://dev.yorhel.nl/ncdu



              Its page also lists other "similar projects":




              gt5 - Quite similar to ncdu, but a different approach.



              tdu - Another small ncurses-based disk usage visualization utility.



              TreeSize - GTK, using a treeview.



              Baobab - GTK, using pie-charts, a treeview and a treemap. Comes with GNOME.



              GdMap - GTK, with a treemap display.



              Filelight - KDE, using pie-charts.



              KDirStat - KDE, with a treemap display.



              QDiskUsage - Qt, using pie-charts.



              xdiskusage - FLTK, with a treemap display.



              fsv - 3D visualization.



              Philesight - Web-based clone of Filelight.







              share|improve this answer



















              • 1





                Thanks David, finally got around to looking at those. I picked ncdu.

                – Ray Andrews
                Nov 18 '15 at 1:20











              • @David where does tdu come from ?

                – shirish
                Jan 27 '17 at 21:10











              • @shirish Refer to my source, noted above

                – David Potočnik
                Mar 30 '17 at 16:49














              6












              6








              6







              Also checkout ncdu:
              http://dev.yorhel.nl/ncdu



              Its page also lists other "similar projects":




              gt5 - Quite similar to ncdu, but a different approach.



              tdu - Another small ncurses-based disk usage visualization utility.



              TreeSize - GTK, using a treeview.



              Baobab - GTK, using pie-charts, a treeview and a treemap. Comes with GNOME.



              GdMap - GTK, with a treemap display.



              Filelight - KDE, using pie-charts.



              KDirStat - KDE, with a treemap display.



              QDiskUsage - Qt, using pie-charts.



              xdiskusage - FLTK, with a treemap display.



              fsv - 3D visualization.



              Philesight - Web-based clone of Filelight.







              share|improve this answer













              Also checkout ncdu:
              http://dev.yorhel.nl/ncdu



              Its page also lists other "similar projects":




              gt5 - Quite similar to ncdu, but a different approach.



              tdu - Another small ncurses-based disk usage visualization utility.



              TreeSize - GTK, using a treeview.



              Baobab - GTK, using pie-charts, a treeview and a treemap. Comes with GNOME.



              GdMap - GTK, with a treemap display.



              Filelight - KDE, using pie-charts.



              KDirStat - KDE, with a treemap display.



              QDiskUsage - Qt, using pie-charts.



              xdiskusage - FLTK, with a treemap display.



              fsv - 3D visualization.



              Philesight - Web-based clone of Filelight.








              share|improve this answer












              share|improve this answer



              share|improve this answer










              answered Nov 3 '15 at 23:47









              David PotočnikDavid Potočnik

              763




              763








              • 1





                Thanks David, finally got around to looking at those. I picked ncdu.

                – Ray Andrews
                Nov 18 '15 at 1:20











              • @David where does tdu come from ?

                – shirish
                Jan 27 '17 at 21:10











              • @shirish Refer to my source, noted above

                – David Potočnik
                Mar 30 '17 at 16:49














              • 1





                Thanks David, finally got around to looking at those. I picked ncdu.

                – Ray Andrews
                Nov 18 '15 at 1:20











              • @David where does tdu come from ?

                – shirish
                Jan 27 '17 at 21:10











              • @shirish Refer to my source, noted above

                – David Potočnik
                Mar 30 '17 at 16:49








              1




              1





              Thanks David, finally got around to looking at those. I picked ncdu.

              – Ray Andrews
              Nov 18 '15 at 1:20





              Thanks David, finally got around to looking at those. I picked ncdu.

              – Ray Andrews
              Nov 18 '15 at 1:20













              @David where does tdu come from ?

              – shirish
              Jan 27 '17 at 21:10





              @David where does tdu come from ?

              – shirish
              Jan 27 '17 at 21:10













              @shirish Refer to my source, noted above

              – David Potočnik
              Mar 30 '17 at 16:49





              @shirish Refer to my source, noted above

              – David Potočnik
              Mar 30 '17 at 16:49













              8














              You don't need to grep for the colour code, the -d option is list directories only.



              This seems to do what you want:



              $ tree --du -d -shaC | grep -Ev '(  *[^ ]* ){2}['
              .
              ├── [ 18] dir1
              ├── [ 30] dir2
              ├── [ 205] junk
              │   ├── [ 18] dir1
              │   ├── [ 30] dir2
              │   └── [ 76] dir3
              ├── [ 119] merge
              └── [ 20] stuff

              4.4K used in 10 directories


              The grep command removes all lines that have (one or more spaces followed by a non-space followed by a space) twice, followed by a [.



              If you want a depth of 1, change the bound count inside the {} curly braces to {1} rather than {2}. same if you want a depth of 3, change it to {3}.



              You can turn this into a shell function, like so:



              mytreedu() {
              local depth=''

              while getopts "L:" opt ; do
              case "$opt" in
              L) depth="$OPTARG" ;;
              esac
              done

              shift "$((OPTIND-1))"

              if [ -z "$depth" ] ; then
              tree --du -d -shaC "$@"
              else
              local PATTERN='( *[^ ]* ){'"$depth"'}['
              tree --du -d -shaC "$@" | grep -Ev "$PATTERN"
              fi
              }


              This uses getopts to "steal" any -L option and its argument from the tree command line, if there is one. If there isn't a -L n option on the command line, then that works too.



              All other options and args are passed to the tree command.



              The local PATTERN=... line isn't really necessary. I only did it like that to make sure that it would fit on one line and not word-wrap here on U&L. The regular expression could and probably should just go directly on the tree | grep ... line.



              Run it like this:



              mytreedu 


              or



              mytreedu -L 2 /path/to/dir/





              share|improve this answer





















              • 1





                I love the code, but repeat that you can't use the '-d' because if you do, the size summaries are incorrect, or at least they are here. The size will be reported always as '4096' which is the size of the entry for the dir itself, but not the size of all it's contents.

                – Ray Andrews
                Oct 25 '15 at 15:41











              • ... should have said '4096' for each directory under the current directory ... but you don't get the sizes of the dir including it's files.

                – Ray Andrews
                Oct 25 '15 at 15:48











              • you only mentioned -L as being a problem, didn't mention -d at all. Now that I look more closely at the numbers reported, neither tree --du nor tree --du -d report sizes that in any way resemble those reported by du.

                – cas
                Oct 25 '15 at 19:47











              • Point being that anything less than a 100% display will not give you correct sizes. You could limit via '-d' or '-L 2' or whatever else--it it isn't shown, it isn't counted in the size.

                – Ray Andrews
                Oct 26 '15 at 0:17











              • tree --du doesn't seem to give correct sizes for directories anyway, with or without -d or -L. I have no idea what the numbers are supposed to be, but they're unrelated to what du reports.

                – cas
                Oct 26 '15 at 0:30
















              8














              You don't need to grep for the colour code, the -d option is list directories only.



              This seems to do what you want:



              $ tree --du -d -shaC | grep -Ev '(  *[^ ]* ){2}['
              .
              ├── [ 18] dir1
              ├── [ 30] dir2
              ├── [ 205] junk
              │   ├── [ 18] dir1
              │   ├── [ 30] dir2
              │   └── [ 76] dir3
              ├── [ 119] merge
              └── [ 20] stuff

              4.4K used in 10 directories


              The grep command removes all lines that have (one or more spaces followed by a non-space followed by a space) twice, followed by a [.



              If you want a depth of 1, change the bound count inside the {} curly braces to {1} rather than {2}. same if you want a depth of 3, change it to {3}.



              You can turn this into a shell function, like so:



              mytreedu() {
              local depth=''

              while getopts "L:" opt ; do
              case "$opt" in
              L) depth="$OPTARG" ;;
              esac
              done

              shift "$((OPTIND-1))"

              if [ -z "$depth" ] ; then
              tree --du -d -shaC "$@"
              else
              local PATTERN='( *[^ ]* ){'"$depth"'}['
              tree --du -d -shaC "$@" | grep -Ev "$PATTERN"
              fi
              }


              This uses getopts to "steal" any -L option and its argument from the tree command line, if there is one. If there isn't a -L n option on the command line, then that works too.



              All other options and args are passed to the tree command.



              The local PATTERN=... line isn't really necessary. I only did it like that to make sure that it would fit on one line and not word-wrap here on U&L. The regular expression could and probably should just go directly on the tree | grep ... line.



              Run it like this:



              mytreedu 


              or



              mytreedu -L 2 /path/to/dir/





              share|improve this answer





















              • 1





                I love the code, but repeat that you can't use the '-d' because if you do, the size summaries are incorrect, or at least they are here. The size will be reported always as '4096' which is the size of the entry for the dir itself, but not the size of all it's contents.

                – Ray Andrews
                Oct 25 '15 at 15:41











              • ... should have said '4096' for each directory under the current directory ... but you don't get the sizes of the dir including it's files.

                – Ray Andrews
                Oct 25 '15 at 15:48











              • you only mentioned -L as being a problem, didn't mention -d at all. Now that I look more closely at the numbers reported, neither tree --du nor tree --du -d report sizes that in any way resemble those reported by du.

                – cas
                Oct 25 '15 at 19:47











              • Point being that anything less than a 100% display will not give you correct sizes. You could limit via '-d' or '-L 2' or whatever else--it it isn't shown, it isn't counted in the size.

                – Ray Andrews
                Oct 26 '15 at 0:17











              • tree --du doesn't seem to give correct sizes for directories anyway, with or without -d or -L. I have no idea what the numbers are supposed to be, but they're unrelated to what du reports.

                – cas
                Oct 26 '15 at 0:30














              8












              8








              8







              You don't need to grep for the colour code, the -d option is list directories only.



              This seems to do what you want:



              $ tree --du -d -shaC | grep -Ev '(  *[^ ]* ){2}['
              .
              ├── [ 18] dir1
              ├── [ 30] dir2
              ├── [ 205] junk
              │   ├── [ 18] dir1
              │   ├── [ 30] dir2
              │   └── [ 76] dir3
              ├── [ 119] merge
              └── [ 20] stuff

              4.4K used in 10 directories


              The grep command removes all lines that have (one or more spaces followed by a non-space followed by a space) twice, followed by a [.



              If you want a depth of 1, change the bound count inside the {} curly braces to {1} rather than {2}. same if you want a depth of 3, change it to {3}.



              You can turn this into a shell function, like so:



              mytreedu() {
              local depth=''

              while getopts "L:" opt ; do
              case "$opt" in
              L) depth="$OPTARG" ;;
              esac
              done

              shift "$((OPTIND-1))"

              if [ -z "$depth" ] ; then
              tree --du -d -shaC "$@"
              else
              local PATTERN='( *[^ ]* ){'"$depth"'}['
              tree --du -d -shaC "$@" | grep -Ev "$PATTERN"
              fi
              }


              This uses getopts to "steal" any -L option and its argument from the tree command line, if there is one. If there isn't a -L n option on the command line, then that works too.



              All other options and args are passed to the tree command.



              The local PATTERN=... line isn't really necessary. I only did it like that to make sure that it would fit on one line and not word-wrap here on U&L. The regular expression could and probably should just go directly on the tree | grep ... line.



              Run it like this:



              mytreedu 


              or



              mytreedu -L 2 /path/to/dir/





              share|improve this answer















              You don't need to grep for the colour code, the -d option is list directories only.



              This seems to do what you want:



              $ tree --du -d -shaC | grep -Ev '(  *[^ ]* ){2}['
              .
              ├── [ 18] dir1
              ├── [ 30] dir2
              ├── [ 205] junk
              │   ├── [ 18] dir1
              │   ├── [ 30] dir2
              │   └── [ 76] dir3
              ├── [ 119] merge
              └── [ 20] stuff

              4.4K used in 10 directories


              The grep command removes all lines that have (one or more spaces followed by a non-space followed by a space) twice, followed by a [.



              If you want a depth of 1, change the bound count inside the {} curly braces to {1} rather than {2}. same if you want a depth of 3, change it to {3}.



              You can turn this into a shell function, like so:



              mytreedu() {
              local depth=''

              while getopts "L:" opt ; do
              case "$opt" in
              L) depth="$OPTARG" ;;
              esac
              done

              shift "$((OPTIND-1))"

              if [ -z "$depth" ] ; then
              tree --du -d -shaC "$@"
              else
              local PATTERN='( *[^ ]* ){'"$depth"'}['
              tree --du -d -shaC "$@" | grep -Ev "$PATTERN"
              fi
              }


              This uses getopts to "steal" any -L option and its argument from the tree command line, if there is one. If there isn't a -L n option on the command line, then that works too.



              All other options and args are passed to the tree command.



              The local PATTERN=... line isn't really necessary. I only did it like that to make sure that it would fit on one line and not word-wrap here on U&L. The regular expression could and probably should just go directly on the tree | grep ... line.



              Run it like this:



              mytreedu 


              or



              mytreedu -L 2 /path/to/dir/






              share|improve this answer














              share|improve this answer



              share|improve this answer








              edited Oct 25 '15 at 12:54









              terdon

              129k32253428




              129k32253428










              answered Oct 25 '15 at 2:21









              cascas

              38.7k453101




              38.7k453101








              • 1





                I love the code, but repeat that you can't use the '-d' because if you do, the size summaries are incorrect, or at least they are here. The size will be reported always as '4096' which is the size of the entry for the dir itself, but not the size of all it's contents.

                – Ray Andrews
                Oct 25 '15 at 15:41











              • ... should have said '4096' for each directory under the current directory ... but you don't get the sizes of the dir including it's files.

                – Ray Andrews
                Oct 25 '15 at 15:48











              • you only mentioned -L as being a problem, didn't mention -d at all. Now that I look more closely at the numbers reported, neither tree --du nor tree --du -d report sizes that in any way resemble those reported by du.

                – cas
                Oct 25 '15 at 19:47











              • Point being that anything less than a 100% display will not give you correct sizes. You could limit via '-d' or '-L 2' or whatever else--it it isn't shown, it isn't counted in the size.

                – Ray Andrews
                Oct 26 '15 at 0:17











              • tree --du doesn't seem to give correct sizes for directories anyway, with or without -d or -L. I have no idea what the numbers are supposed to be, but they're unrelated to what du reports.

                – cas
                Oct 26 '15 at 0:30














              • 1





                I love the code, but repeat that you can't use the '-d' because if you do, the size summaries are incorrect, or at least they are here. The size will be reported always as '4096' which is the size of the entry for the dir itself, but not the size of all it's contents.

                – Ray Andrews
                Oct 25 '15 at 15:41











              • ... should have said '4096' for each directory under the current directory ... but you don't get the sizes of the dir including it's files.

                – Ray Andrews
                Oct 25 '15 at 15:48











              • you only mentioned -L as being a problem, didn't mention -d at all. Now that I look more closely at the numbers reported, neither tree --du nor tree --du -d report sizes that in any way resemble those reported by du.

                – cas
                Oct 25 '15 at 19:47











              • Point being that anything less than a 100% display will not give you correct sizes. You could limit via '-d' or '-L 2' or whatever else--it it isn't shown, it isn't counted in the size.

                – Ray Andrews
                Oct 26 '15 at 0:17











              • tree --du doesn't seem to give correct sizes for directories anyway, with or without -d or -L. I have no idea what the numbers are supposed to be, but they're unrelated to what du reports.

                – cas
                Oct 26 '15 at 0:30








              1




              1





              I love the code, but repeat that you can't use the '-d' because if you do, the size summaries are incorrect, or at least they are here. The size will be reported always as '4096' which is the size of the entry for the dir itself, but not the size of all it's contents.

              – Ray Andrews
              Oct 25 '15 at 15:41





              I love the code, but repeat that you can't use the '-d' because if you do, the size summaries are incorrect, or at least they are here. The size will be reported always as '4096' which is the size of the entry for the dir itself, but not the size of all it's contents.

              – Ray Andrews
              Oct 25 '15 at 15:41













              ... should have said '4096' for each directory under the current directory ... but you don't get the sizes of the dir including it's files.

              – Ray Andrews
              Oct 25 '15 at 15:48





              ... should have said '4096' for each directory under the current directory ... but you don't get the sizes of the dir including it's files.

              – Ray Andrews
              Oct 25 '15 at 15:48













              you only mentioned -L as being a problem, didn't mention -d at all. Now that I look more closely at the numbers reported, neither tree --du nor tree --du -d report sizes that in any way resemble those reported by du.

              – cas
              Oct 25 '15 at 19:47





              you only mentioned -L as being a problem, didn't mention -d at all. Now that I look more closely at the numbers reported, neither tree --du nor tree --du -d report sizes that in any way resemble those reported by du.

              – cas
              Oct 25 '15 at 19:47













              Point being that anything less than a 100% display will not give you correct sizes. You could limit via '-d' or '-L 2' or whatever else--it it isn't shown, it isn't counted in the size.

              – Ray Andrews
              Oct 26 '15 at 0:17





              Point being that anything less than a 100% display will not give you correct sizes. You could limit via '-d' or '-L 2' or whatever else--it it isn't shown, it isn't counted in the size.

              – Ray Andrews
              Oct 26 '15 at 0:17













              tree --du doesn't seem to give correct sizes for directories anyway, with or without -d or -L. I have no idea what the numbers are supposed to be, but they're unrelated to what du reports.

              – cas
              Oct 26 '15 at 0:30





              tree --du doesn't seem to give correct sizes for directories anyway, with or without -d or -L. I have no idea what the numbers are supposed to be, but they're unrelated to what du reports.

              – cas
              Oct 26 '15 at 0:30











              1














              You can use dutree



              enter image description here




              • coloured output, according to the LS_COLORS environment variable.

              • display the file system tree

              • ability to aggregate small files

              • ability to exclude files or directories

              • ability to compare different directories

              • fast, written in Rust






              share|improve this answer




























                1














                You can use dutree



                enter image description here




                • coloured output, according to the LS_COLORS environment variable.

                • display the file system tree

                • ability to aggregate small files

                • ability to exclude files or directories

                • ability to compare different directories

                • fast, written in Rust






                share|improve this answer


























                  1












                  1








                  1







                  You can use dutree



                  enter image description here




                  • coloured output, according to the LS_COLORS environment variable.

                  • display the file system tree

                  • ability to aggregate small files

                  • ability to exclude files or directories

                  • ability to compare different directories

                  • fast, written in Rust






                  share|improve this answer













                  You can use dutree



                  enter image description here




                  • coloured output, according to the LS_COLORS environment variable.

                  • display the file system tree

                  • ability to aggregate small files

                  • ability to exclude files or directories

                  • ability to compare different directories

                  • fast, written in Rust







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Nov 1 '18 at 1:26









                  nachoparkernachoparker

                  47935




                  47935























                      0














                      Inspired by cas, I'm now doing this:



                      treee ()
                      {
                      integer levels=$(( ($1 + 1) * 4 ))
                      tree --du -shaC | grep "[01;34m" | grep -Ev "^[^{$levels}[*"
                      du -sh .
                      }





                      share|improve this answer
























                      • if you're going to throw away all the getopts stuff, you should at least still have "$@" immediately after the -shaC. otherwise that function is hard-coded to work for the current directory only.

                        – cas
                        Oct 25 '15 at 19:50











                      • Once we got the thing working, I was going to ask you about that: please elaborate. Right about "$@" of course, but so far I only ever use it in the current dir, so haven't noticed that yet. All this 'getopts' stuff is new to me, I'd like to know what you are thinking there.

                        – Ray Andrews
                        Oct 26 '15 at 0:14











                      • One of the benefits of using getopts is that options can appear in any order on the command line. The initial version of the mytree function I wrote used "$1" just as yours did, so the depth argument had to be the first argument, and it was not optional. I decided that wasn't good enough so used the bash-builtin getopts to process the -L option. This allowed the -L n option to appear anywhere on the command line. It also allowed it to be completely optional.

                        – cas
                        Oct 26 '15 at 0:24











                      • another way of looking at it is that getopts allows you to write scripts that take real options and arguments (rather than just args in hard-coded positions like $1 $2 $3 etc), just like most other programs on your system. And if you use the getopt program (note that's without an s) from the util-linux package you can use both short single-letter options (e.g. -l) and long options (like --long) just like GNU programs.

                        – cas
                        Oct 26 '15 at 0:26













                      • Ah ... it comes back to me now. Yes, I actually used that once. Must take another look at it. Thanks.

                        – Ray Andrews
                        Oct 26 '15 at 6:54
















                      0














                      Inspired by cas, I'm now doing this:



                      treee ()
                      {
                      integer levels=$(( ($1 + 1) * 4 ))
                      tree --du -shaC | grep "[01;34m" | grep -Ev "^[^{$levels}[*"
                      du -sh .
                      }





                      share|improve this answer
























                      • if you're going to throw away all the getopts stuff, you should at least still have "$@" immediately after the -shaC. otherwise that function is hard-coded to work for the current directory only.

                        – cas
                        Oct 25 '15 at 19:50











                      • Once we got the thing working, I was going to ask you about that: please elaborate. Right about "$@" of course, but so far I only ever use it in the current dir, so haven't noticed that yet. All this 'getopts' stuff is new to me, I'd like to know what you are thinking there.

                        – Ray Andrews
                        Oct 26 '15 at 0:14











                      • One of the benefits of using getopts is that options can appear in any order on the command line. The initial version of the mytree function I wrote used "$1" just as yours did, so the depth argument had to be the first argument, and it was not optional. I decided that wasn't good enough so used the bash-builtin getopts to process the -L option. This allowed the -L n option to appear anywhere on the command line. It also allowed it to be completely optional.

                        – cas
                        Oct 26 '15 at 0:24











                      • another way of looking at it is that getopts allows you to write scripts that take real options and arguments (rather than just args in hard-coded positions like $1 $2 $3 etc), just like most other programs on your system. And if you use the getopt program (note that's without an s) from the util-linux package you can use both short single-letter options (e.g. -l) and long options (like --long) just like GNU programs.

                        – cas
                        Oct 26 '15 at 0:26













                      • Ah ... it comes back to me now. Yes, I actually used that once. Must take another look at it. Thanks.

                        – Ray Andrews
                        Oct 26 '15 at 6:54














                      0












                      0








                      0







                      Inspired by cas, I'm now doing this:



                      treee ()
                      {
                      integer levels=$(( ($1 + 1) * 4 ))
                      tree --du -shaC | grep "[01;34m" | grep -Ev "^[^{$levels}[*"
                      du -sh .
                      }





                      share|improve this answer













                      Inspired by cas, I'm now doing this:



                      treee ()
                      {
                      integer levels=$(( ($1 + 1) * 4 ))
                      tree --du -shaC | grep "[01;34m" | grep -Ev "^[^{$levels}[*"
                      du -sh .
                      }






                      share|improve this answer












                      share|improve this answer



                      share|improve this answer










                      answered Oct 25 '15 at 17:13









                      Ray AndrewsRay Andrews

                      7403825




                      7403825













                      • if you're going to throw away all the getopts stuff, you should at least still have "$@" immediately after the -shaC. otherwise that function is hard-coded to work for the current directory only.

                        – cas
                        Oct 25 '15 at 19:50











                      • Once we got the thing working, I was going to ask you about that: please elaborate. Right about "$@" of course, but so far I only ever use it in the current dir, so haven't noticed that yet. All this 'getopts' stuff is new to me, I'd like to know what you are thinking there.

                        – Ray Andrews
                        Oct 26 '15 at 0:14











                      • One of the benefits of using getopts is that options can appear in any order on the command line. The initial version of the mytree function I wrote used "$1" just as yours did, so the depth argument had to be the first argument, and it was not optional. I decided that wasn't good enough so used the bash-builtin getopts to process the -L option. This allowed the -L n option to appear anywhere on the command line. It also allowed it to be completely optional.

                        – cas
                        Oct 26 '15 at 0:24











                      • another way of looking at it is that getopts allows you to write scripts that take real options and arguments (rather than just args in hard-coded positions like $1 $2 $3 etc), just like most other programs on your system. And if you use the getopt program (note that's without an s) from the util-linux package you can use both short single-letter options (e.g. -l) and long options (like --long) just like GNU programs.

                        – cas
                        Oct 26 '15 at 0:26













                      • Ah ... it comes back to me now. Yes, I actually used that once. Must take another look at it. Thanks.

                        – Ray Andrews
                        Oct 26 '15 at 6:54



















                      • if you're going to throw away all the getopts stuff, you should at least still have "$@" immediately after the -shaC. otherwise that function is hard-coded to work for the current directory only.

                        – cas
                        Oct 25 '15 at 19:50











                      • Once we got the thing working, I was going to ask you about that: please elaborate. Right about "$@" of course, but so far I only ever use it in the current dir, so haven't noticed that yet. All this 'getopts' stuff is new to me, I'd like to know what you are thinking there.

                        – Ray Andrews
                        Oct 26 '15 at 0:14











                      • One of the benefits of using getopts is that options can appear in any order on the command line. The initial version of the mytree function I wrote used "$1" just as yours did, so the depth argument had to be the first argument, and it was not optional. I decided that wasn't good enough so used the bash-builtin getopts to process the -L option. This allowed the -L n option to appear anywhere on the command line. It also allowed it to be completely optional.

                        – cas
                        Oct 26 '15 at 0:24











                      • another way of looking at it is that getopts allows you to write scripts that take real options and arguments (rather than just args in hard-coded positions like $1 $2 $3 etc), just like most other programs on your system. And if you use the getopt program (note that's without an s) from the util-linux package you can use both short single-letter options (e.g. -l) and long options (like --long) just like GNU programs.

                        – cas
                        Oct 26 '15 at 0:26













                      • Ah ... it comes back to me now. Yes, I actually used that once. Must take another look at it. Thanks.

                        – Ray Andrews
                        Oct 26 '15 at 6:54

















                      if you're going to throw away all the getopts stuff, you should at least still have "$@" immediately after the -shaC. otherwise that function is hard-coded to work for the current directory only.

                      – cas
                      Oct 25 '15 at 19:50





                      if you're going to throw away all the getopts stuff, you should at least still have "$@" immediately after the -shaC. otherwise that function is hard-coded to work for the current directory only.

                      – cas
                      Oct 25 '15 at 19:50













                      Once we got the thing working, I was going to ask you about that: please elaborate. Right about "$@" of course, but so far I only ever use it in the current dir, so haven't noticed that yet. All this 'getopts' stuff is new to me, I'd like to know what you are thinking there.

                      – Ray Andrews
                      Oct 26 '15 at 0:14





                      Once we got the thing working, I was going to ask you about that: please elaborate. Right about "$@" of course, but so far I only ever use it in the current dir, so haven't noticed that yet. All this 'getopts' stuff is new to me, I'd like to know what you are thinking there.

                      – Ray Andrews
                      Oct 26 '15 at 0:14













                      One of the benefits of using getopts is that options can appear in any order on the command line. The initial version of the mytree function I wrote used "$1" just as yours did, so the depth argument had to be the first argument, and it was not optional. I decided that wasn't good enough so used the bash-builtin getopts to process the -L option. This allowed the -L n option to appear anywhere on the command line. It also allowed it to be completely optional.

                      – cas
                      Oct 26 '15 at 0:24





                      One of the benefits of using getopts is that options can appear in any order on the command line. The initial version of the mytree function I wrote used "$1" just as yours did, so the depth argument had to be the first argument, and it was not optional. I decided that wasn't good enough so used the bash-builtin getopts to process the -L option. This allowed the -L n option to appear anywhere on the command line. It also allowed it to be completely optional.

                      – cas
                      Oct 26 '15 at 0:24













                      another way of looking at it is that getopts allows you to write scripts that take real options and arguments (rather than just args in hard-coded positions like $1 $2 $3 etc), just like most other programs on your system. And if you use the getopt program (note that's without an s) from the util-linux package you can use both short single-letter options (e.g. -l) and long options (like --long) just like GNU programs.

                      – cas
                      Oct 26 '15 at 0:26







                      another way of looking at it is that getopts allows you to write scripts that take real options and arguments (rather than just args in hard-coded positions like $1 $2 $3 etc), just like most other programs on your system. And if you use the getopt program (note that's without an s) from the util-linux package you can use both short single-letter options (e.g. -l) and long options (like --long) just like GNU programs.

                      – cas
                      Oct 26 '15 at 0:26















                      Ah ... it comes back to me now. Yes, I actually used that once. Must take another look at it. Thanks.

                      – Ray Andrews
                      Oct 26 '15 at 6:54





                      Ah ... it comes back to me now. Yes, I actually used that once. Must take another look at it. Thanks.

                      – Ray Andrews
                      Oct 26 '15 at 6:54











                      0














                      There isn't any perfect command tool to do this, But I found two ways that are closly.





                      • shows both folders and files' size, but not showing in a tree mode.



                        du -ah --max-depth=1 /var/log




                      • shows in tree mode but only files' size, the folders are in counts



                        tree -ah /var/log -L 1








                      share|improve this answer




























                        0














                        There isn't any perfect command tool to do this, But I found two ways that are closly.





                        • shows both folders and files' size, but not showing in a tree mode.



                          du -ah --max-depth=1 /var/log




                        • shows in tree mode but only files' size, the folders are in counts



                          tree -ah /var/log -L 1








                        share|improve this answer


























                          0












                          0








                          0







                          There isn't any perfect command tool to do this, But I found two ways that are closly.





                          • shows both folders and files' size, but not showing in a tree mode.



                            du -ah --max-depth=1 /var/log




                          • shows in tree mode but only files' size, the folders are in counts



                            tree -ah /var/log -L 1








                          share|improve this answer













                          There isn't any perfect command tool to do this, But I found two ways that are closly.





                          • shows both folders and files' size, but not showing in a tree mode.



                            du -ah --max-depth=1 /var/log




                          • shows in tree mode but only files' size, the folders are in counts



                            tree -ah /var/log -L 1









                          share|improve this answer












                          share|improve this answer



                          share|improve this answer










                          answered Jan 16 at 4:14









                          Valiant JiangValiant Jiang

                          101




                          101






























                              draft saved

                              draft discarded




















































                              Thanks for contributing an answer to Unix & Linux Stack Exchange!


                              • Please be sure to answer the question. Provide details and share your research!

                              But avoid



                              • Asking for help, clarification, or responding to other answers.

                              • Making statements based on opinion; back them up with references or personal experience.


                              To learn more, see our tips on writing great answers.




                              draft saved


                              draft discarded














                              StackExchange.ready(
                              function () {
                              StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f238455%2fcombine-the-best-of-du-and-tree%23new-answer', 'question_page');
                              }
                              );

                              Post as a guest















                              Required, but never shown





















































                              Required, but never shown














                              Required, but never shown












                              Required, but never shown







                              Required, but never shown

































                              Required, but never shown














                              Required, but never shown












                              Required, but never shown







                              Required, but never shown







                              Popular posts from this blog

                              How to reconfigure Docker Trusted Registry 2.x.x to use CEPH FS mount instead of NFS and other traditional...

                              is 'sed' thread safe

                              How to make a Squid Proxy server?