It looks like "tree --du" should do it, but "tree -d --du -h" says
├── [452K] Documents
when du says it's 787M.
Hello,
is there a command that shows dir/subdir structure like `tree`, but for each dir has the size in results as well?
The question is: which one do you want?
both the size of current path and subdir should be expected.
On Thu, May 30, 2024 at 06:51:30PM -0400, eben@gmx.us wrote:
It looks like "tree --du" should do it, but "tree -d --du -h" says
├── [452K] Documents
when du says it's 787M.
Well, that sounds like one of the numbers includes subdirectories and
the other only includes files in the immediate directory.
The question is: which one do you want?
I think "du -h -S -s Documents/" gives just the files in Documents, and not its subdirectories, and it gives 269M. "ls -ldh Documents/" says the directory itsely takes up 36k, so I'm not sure where "tree" got that number.It looks like "tree --du" should do it, but "tree -d --du -h" says ├── [452K] Documents
is there a command that shows dir/subdir structure like `tree`, but for
each dir has the size in results as well?
On 31/05/24 at 02:18, Greg Wooledge wrote:
Confusing and useless. I still don't have a better answer than this:
hobbit:~$ tree --du -Fh /tmp/x | grep /$
[7.8M]/tmp/x/
└── [4.0K] y/
It could be improved adding the "-a" switch to show also the hidden directories and the "--color" switch to the "grep" command but this sadly doesn't show the expected result (colorized directories) I don't know why:
~$ tree --du -Fah /tmp/x | grep --color /$
Me too needed to summarize the directory's size thus I wrote a bash function to accomplish this and added it to my /etc/profile.d/local.sh file:
duhs() { IFS=$'\n\r' ; for d in $(/usr/bin/find $1 -maxdepth 1 -type d |/usr/bin/sort) ; do du -hs $d ; done }
On Fri, May 31, 2024 at 09:18:03PM +0200, Franco Martelli wrote:
On 31/05/24 at 02:18, Greg Wooledge wrote:
Confusing and useless. I still don't have a better answer than this:
hobbit:~$ tree --du -Fh /tmp/x | grep /$
[7.8M]/tmp/x/
└── [4.0K] y/
It could be improved adding the "-a" switch to show also the hidden directories and the "--color" switch to the "grep" command but this sadly doesn't show the expected result (colorized directories) I don't know why:
~$ tree --du -Fah /tmp/x | grep --color /$
You're only coloring the trailing / characters. If you want everything
from after the last space to the end of the line, you'd want:
tree --du -Fh /usr/local | grep --color '[^[:space:]]*/$'
Of course this fails to colorize the entire directory name if there's
a space in it.
If a coloured ] is unimportant, I suppose you could use:
tree --du -Fh whatever | grep --color '][[:space:]][[:space:]].*/$'
~$ tree --du -Fah /tmp/x | grep --color /$You're only coloring the trailing / characters. If you want everything from after the last space to the end of the line, you'd want:
tree --du -Fh /usr/local | grep --color '[^[:space:]]*/$'
I realized why "tree" command doesn't colorized the directories: "tree" detects that its std output goes through a pipe and therefore it disables
the escaped code to colorize (like also "dmesg" does).
"tree" detects that its std output goes through a pipe and
therefore it disables the escaped code to colorize (like also
"dmesg" does). To avoid this behavior you must use the "unbuffer"
command:
unbuffer tree --du -Fah /usr/local | grep /$
You can also try:
~# unbuffer dmesg | grep snd
On 31/05/24 at 22:03, Greg Wooledge wrote:
It could be improved adding the "-a" switch to show also the hidden directories and the "--color" switch to the "grep" command but this sadly doesn't show the expected result (colorized directories) I don't know why:
~$ tree --du -Fah /tmp/x | grep --color /$You're only coloring the trailing / characters. If you want everything from after the last space to the end of the line, you'd want:
tree --du -Fh /usr/local | grep --color '[^[:space:]]*/$'
I realized why "tree" command doesn't colorized the directories: "tree" detects that its std output goes through a pipe and therefore it disables
the escaped code to colorize (like also "dmesg" does).
To avoid this behavior you must use the "unbuffer" command:
unbuffer tree --du -Fah /usr/local | grep /$
If you want to avoid that, you can use xargs -0:
duhs() { printf '%s\0' "${1:-.}"/*/ | xargs -0 du -sh; }
As printf is a bash builtin, it can handle an unlimited number of arguments. So this form should work in all cases.
Thank you very much for revolutionizing my duhs() function, but sadly this version omits to show the hidden directories. Do you have a version that it shows also those directories? For me it's so hard to figure out what the "${1:-.}"/*/ block does.
If that's the only thing you're using unbuffer for, why not just use
the -C option of tree? It's a bit like the "--color=always" of ls.
On Mon 03 Jun 2024 at 10:32:16 (-0400), Greg Wooledge wrote:
duhs() (
shopt -s dotglob
printf '%s\0' "${1:-.}"/*/ | xargs -0 du -sh
)
I'm not personally fond of this. It's extremely easy to overlook
the fact that the curly braces have been replaced with parentheses,
I guess minimalists would make a one-liner out of that.
Myself, I prefer verbosity, and the ability to search and find
all my functions with /function.*{$ in less. For example,
I write what is probably my most trivial function in .bashrc as:
function _Cat_ {
cat
}
rather than:
_Cat_() { cat; }
function _Cat_ {
On 03/06/24 at 16:32, Greg Wooledge wrote:
duhs() {
(
shopt -s dotglob
printf '%s\0' "${1:-.}"/*/ | xargs -0 du -sh
)
}
I've some issue with this function. It doesn't show the size of the
directory specified as argument, it follows the output of my original function:
On Mon, Jun 03, 2024 at 01:11:57PM -0500, David Wright wrote:
On Mon 03 Jun 2024 at 10:32:16 (-0400), Greg Wooledge wrote:
duhs() (
shopt -s dotglob
printf '%s\0' "${1:-.}"/*/ | xargs -0 du -sh
)
I'm not personally fond of this. It's extremely easy to overlook
the fact that the curly braces have been replaced with parentheses,
I guess minimalists would make a one-liner out of that.
Myself, I prefer verbosity, and the ability to search and find
all my functions with /function.*{$ in less. For example,
I write what is probably my most trivial function in .bashrc as:
function _Cat_ {
cat
}
rather than:
_Cat_() { cat; }
... I feel like you've just exemplified what I was talking about, missing
the fact that the curly braces were replaced with parentheses around the function body to force a subshell every time it's called.
It had nothing to do with how many lines of code were used. I could
have written them as
duhs() { (shopt -s dotglob; printf '%s\0' "${1:-.}"/*/ | xargs -0 du -sh); }
and
duhs() (shopt -s dotglob; printf '%s\0' "${1:-.}"/*/ | xargs -0 du -sh)
and the same point would have applied.
function _Cat_ {
Do note that the "function" keyword is a bash/ksh extension, and not
part of POSIX sh syntax. In bash, "x()" and "function x" are identical
in behavior. In ksh, they cause two different kinds of variable scoping behavior. Bash also allows "function x()" which ksh does not.
Just for the record.
On Mon 03 Jun 2024 at 18:29:17 (-0400), Greg Wooledge wrote:
‘-s’
‘--summarize’
Display only a total for each argument.
There's supposed to be a total *FOR EACH ARGUMENT*. There isn't.
Try adding -l. The idea is that du is trying to avoid double-counting,
so when the subdirectories come first, those ones are "used up" by
the time it reaches the parent. When the parent is first, it's (all)
the subdirectories instead that have been "used up".
FYI the revision of duhs() I adopt is:
duhs() { ( shopt -s dotglob; printf '%s\0' "${1:-.}" "${1:-.}"*/ | xargs -0 du -shl ) } ↑
Please note that I dropped a "/" in the "${1:-.}"/*/ block because the directories listed had a double "//" in their names:
~# duhs /usr/local/
88K /usr/local/
4,0K /usr/local//bin/
4,0K /usr/local//etc/
4,0K /usr/local//games/
4,0K /usr/local//include/
4,0K /usr/local//man/
4,0K /usr/local//sbin/
60K /usr/local//share/
4,0K /usr/local//src/
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 546 |
Nodes: | 16 (0 / 16) |
Uptime: | 169:23:30 |
Calls: | 10,385 |
Calls today: | 2 |
Files: | 14,057 |
Messages: | 6,416,552 |