[GH-ISSUE #506] [feat request]: command to open an interactive file manager and dust #225

New Issue

2026-06-08T11:26:13+03:00

zhus commented

2026-06-08 11:26:13 +03:00

Originally created by @juanMarinero on GitHub (Jul 1, 2025).
Original GitHub issue: https://github.com/bootandy/dust/issues/506

dust is awesome, but not dynamic like a file manager. One can take advantage of both if:

one terminal window shows the dust tree
the other window runs a file manager, that sorts by size is ideal like ncdu

Next is my proposal, though it just works using kitty and zsh.

Request:

Improve and provide alike next command in this repo
Expand for other shells, terminals and file-managers

#!/usr/bin/env zsh

_du() {

  dust -r

  unset answer_du && echo -n "Navigate dirs with ncdu? (y/N):  "
  read answer_du
  answer_du=${answer_du:-n} # Default to 'n' if no input is provided
  echo
  if [[ "$answer_du" == "n" ]]; then
    return
  fi

  _kitty_vwindow_new "dust -r" "_du_ncdu"
}
_du_ncdu() {
  sleep 1
  # flags: https://dev.yorhel.nl/ncdu/man
  ncdu --color dark-bg --show-percent --show-itemcount --follow-symlinks --confirm-delete
}
_kitty_vwindow_new() {
  if [ $# -lt 1 ]; then
    echo "Error: Missing arguments"
    echo "Usage: x_kitty_vwindow_new <right_cmd> <left_cmd>"
    return 1
  fi
  local right_cmd="$1"
  local left_cmd="$2"

  # Create new window
  kitty @ launch\
    --type=window \
    --keep-focus \
    --hold zsh -c "source ~/.zshrc && cd $PWD && $right_cmd; exec zsh"

  # Run left command if any
  if [ -n "$left_cmd" ]; then
    $left_cmd
  fi
}

Originally created by @juanMarinero on GitHub (Jul 1, 2025). Original GitHub issue: https://github.com/bootandy/dust/issues/506 **dust** is awesome, but not dynamic like a file manager. One can take advantage of both if: - one terminal window shows the **dust** tree - the other window runs a file manager, that sorts by size is ideal like [ncdu](https://dev.yorhel.nl/ncdu) Next is my proposal, though it just works using [kitty](https://sw.kovidgoyal.net/kitty/) and `zsh`. Request: - [ ] Improve and provide alike next command in this repo - [ ] Expand for other shells, terminals and file-managers ![Image](https://github.com/user-attachments/assets/6adcb657-06e9-475c-8b1d-5088a9ce373b) ```zsh #!/usr/bin/env zsh _du() { dust -r unset answer_du && echo -n "Navigate dirs with ncdu? (y/N): " read answer_du answer_du=${answer_du:-n} # Default to 'n' if no input is provided echo if [[ "$answer_du" == "n" ]]; then return fi _kitty_vwindow_new "dust -r" "_du_ncdu" } _du_ncdu() { sleep 1 # flags: https://dev.yorhel.nl/ncdu/man ncdu --color dark-bg --show-percent --show-itemcount --follow-symlinks --confirm-delete } _kitty_vwindow_new() { if [ $# -lt 1 ]; then echo "Error: Missing arguments" echo "Usage: x_kitty_vwindow_new <right_cmd> <left_cmd>" return 1 fi local right_cmd="$1" local left_cmd="$2" # Create new window kitty @ launch\ --type=window \ --keep-focus \ --hold zsh -c "source ~/.zshrc && cd $PWD && $right_cmd; exec zsh" # Run left command if any if [ -n "$left_cmd" ]; then $left_cmd fi } ```

zhus commented

2026-06-08 11:26:14 +03:00

@bootandy commented on GitHub (Jul 2, 2025):

This has come up before, I was thinking about how best to add this.

@bootandy commented on GitHub (Jul 2, 2025): This has come up before, I was thinking about how best to add this.

zhus commented

2026-06-08 11:26:14 +03:00

@juanMarinero commented on GitHub (Jul 3, 2025):

Thanks for answering!

Sorry if duplicated issue, I searched file manager on any issue (including closed) and I found nothing alike: link.

Maybe this can be:

added to a TODO list
or added to an advises list
or added to a how to use guide
...

And there just link to this issue, so anyone can further expand (adding comments or repo links) with new solutions. Because iterate all requires a lot of effort, it's a 3 dimensional issue:

shells (bash, zsh, fish,...)
terminals (gnome-terminal, kitty, Alacritty, WezTerm,...)
and file-managers like ncdu, NNN, broot,...

Well, actually the file-manager command it's easy to customize for each user needs, but that's still a O(n^2) (Shells × Terminals) job!

Once there are several solutions (for various Shells × Terminals) then one could try to unify all them under a script (create a PR). But if this task gets too big/dirty then there is no need to accomplish it, just let the user copy what needed. This is just my humble opinion how to approach it. If you agree then this issue should be kept open for a while.

@juanMarinero commented on GitHub (Jul 3, 2025): Thanks for answering! Sorry if duplicated issue, I searched `file manager` on any issue (including closed) and I found nothing alike: [link](https://github.com/bootandy/dust/issues?q=is%3Aissue%20file%20manager). Maybe this can be: - [ ] added to a TODO list - [ ] or added to an advises list - [ ] or added to a how to use guide - ... And there just link to this issue, so anyone can further expand (adding comments or repo links) with new solutions. Because iterate all requires a lot of effort, it's a 3 dimensional issue: - shells (bash, zsh, fish,...) - terminals (gnome-terminal, kitty, Alacritty, WezTerm,...) - and file-managers like `ncdu`, NNN, broot,... Well, actually the file-manager command it's easy to customize for each user needs, but that's still a O(n^2) (Shells × Terminals) job! Once there are several solutions (for various Shells × Terminals) then one could try to *unify* all them under a script (create a PR). But if this task gets too big/dirty then there is no need to accomplish it, just let the user copy what needed. This is just my humble opinion how to approach it. If you agree then this issue should be kept open for a while.

zhus commented

2026-06-08 11:26:14 +03:00

@bootandy commented on GitHub (Jul 5, 2025):

https://github.com/bootandy/dust/issues/159
I'm thinking about implementing this currently

@bootandy commented on GitHub (Jul 5, 2025): https://github.com/bootandy/dust/issues/159 I'm thinking about implementing this currently

zhus commented

2026-06-08 11:26:14 +03:00

@juanMarinero commented on GitHub (Jul 5, 2025):

Make each program do one thing well. - Unix philosophy

dust does one thing very well: tree show where my disk is being used
I use NNN for most file manager tasks
Excepts when I need to find a file (if no clue about the path) by name , its content or its size. Also to check for big disk usage. For those I use FZF, broot and ncdu

Also, I would not try to add an interactive mode like NCDU has as you comment in #159 (btw thanks to point me to the original issue I could not find). I think:

The effort is enormous
It's quasi duplicate job, since other terminal file managers with lot of features are already coded
My proposal to just collect multi-terminal-window scripts it's easier

Actually dust remember me a lot to br --whale-spotting

...which sadly does not allow to show tree depth in this mode, i.e. --max-depth flag is not compatible with whale mode. In contrast the normal tree mode does yes show several depths [and the sizes].

So my proposal is, to apply your experience to further develop broot enabling depths in whale mode, alike dust already does [but it does it not interactive].

But who am I to judge? No one hehe. You have coded dust, and I have not coded it nor broot. So maybe making dust interactive it's not so hard as I think, and people will not asks for terminal-file-managers features once you accomplish it.

@juanMarinero commented on GitHub (Jul 5, 2025): > Make each program do one thing well. - Unix philosophy - *dust* does one thing very well: **tree** show where my disk is being used - I use [NNN](https://github.com/jarun/nnn) for most file manager tasks - Excepts when I need to find a file (if no clue about the path) by name , its content or its size. Also to check for big disk usage. For those I use [FZF](https://github.com/junegunn/fzf), [broot](https://github.com/Canop/broot) and [ncdu](https://dev.yorhel.nl/ncdu) Also, I would not try to *add an interactive mode like NCDU has* as you comment in #159 (btw thanks to point me to the original issue I could not find). I think: - The effort is enormous - It's quasi duplicate job, since other terminal file managers with lot of features are already coded - My proposal to just collect multi-terminal-window scripts it's easier Actually *dust* remember me a lot to [br --whale-spotting](https://dystroy.org/broot/tree_view/#whale-mode) <img src="https://dystroy.org/broot/img/br-w.png" alt="Broot White Logo"> ...which sadly does **not** allow to show tree **depth** in this mode, i.e. [--max-depth](https://github.com/Canop/broot/blob/707e554015b3b0af7feed23d5db7d96975d308b4/src/shell_install/nushell.rs#L162) flag is not compatible with whale mode. In contrast the normal [tree](https://dystroy.org/broot/tree_view/#sizes) mode does yes show several depths [and the sizes]. So my proposal is, to apply your experience to further develop *broot* enabling depths in whale mode, alike *dust* already does [but it does it not interactive]. But who am I to judge? No one hehe. You have coded *dust*, and I have not coded it nor *broot*. So maybe making *dust* interactive it's not so hard as I think, and people will not asks for terminal-file-managers features once you accomplish it.

zhus commented

2026-06-08 11:26:14 +03:00

@bootandy commented on GitHub (Jul 5, 2025):

Make each program do one thing well. - Unix philosophy

dust does one thing very well: tree show where my disk is being used

Yes that was exactly my thinking originally.

However, when I have the time I'd like to see if I can fit an interactive mode in there, ( I don't know if its possible or sensible - but I'm curious to try).

@bootandy commented on GitHub (Jul 5, 2025): > Make each program do one thing well. - Unix philosophy dust does one thing very well: tree show where my disk is being used Yes that was exactly my thinking originally. However, when I have the time I'd like to see if I can fit an interactive mode in there, ( I don't know if its possible or sensible - but I'm curious to try).

zhus commented

2026-06-08 11:26:14 +03:00

@bootandy commented on GitHub (Jul 5, 2025):

For your integration script and any future extensions - I think you should host that in a separate repo, and I'm happy to add a link in the README of dust.

@bootandy commented on GitHub (Jul 5, 2025): For your integration script and any future extensions - I think you should host that in a separate repo, and I'm happy to add a link in the README of dust.

zhus commented

2026-06-08 11:26:14 +03:00

@nickjj commented on GitHub (May 1, 2026):

I usually agree with the idea of doing one thing very well but sometimes you have to factor in a full view of what folks are using your tool for.

For example, someone might have a use case of "I want to see what's taking up a lot of disk space", maybe they are just curious and that's completely reasonable, but it's also likely they want to take action to delete the big files or directories.

This is where having both the current behavior and an opt-in optional interactive mode could be handy. It solves the end game problem of "show me big files and let me clean them" in a unified way.

This comes with a pretty big responsibility though, if you introduced interactive mode with a hotkey to delete selected items, this adds code to the code base that really deletes files on disk in a permanent way.

The current behavior isn't too bad in a lot of cases though, you just end up manually rm'ing these files separately. If you have a small handful of files this isn't too bad.

@nickjj commented on GitHub (May 1, 2026): I usually agree with the idea of doing one thing very well but sometimes you have to factor in a full view of what folks are using your tool for. For example, someone might have a use case of "I want to see what's taking up a lot of disk space", maybe they are just curious and that's completely reasonable, but it's also likely they want to take action to delete the big files or directories. This is where having both the current behavior and an opt-in optional interactive mode could be handy. It solves the end game problem of "show me big files and let me clean them" in a unified way. This comes with a pretty big responsibility though, if you introduced interactive mode with a hotkey to delete selected items, this adds code to the code base that really deletes files on disk in a permanent way. The current behavior isn't too bad in a lot of cases though, you just end up manually `rm`'ing these files separately. If you have a small handful of files this isn't too bad.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: bootandy/archived-dust#225