I don't care if it's been done before. I don't care if <insert name here> exists and does a similar thing.
- short name (br in terminal, I'll remember that instantly)
- easy installation
- web page is awesome and shows you instantly how to best use this program
- help page in the program itself is awesome, clear and easy to navigate
- defaults are sensible and totally easy to get used to
- broot just WORKS! and it works well, I finally got rid of all the aliases around ls that I used in order to get info I want
Amazing job Denys, 10/10 for the web, program, documentation and examples!
Btw. Linux/Windows user here.
Have an excellent day and successful year!
(A really cheeky issue tracker could have this built in as issue 0.)
Thank you issues while clutter would be my favourite off topic issue to close.
I don't think you can generalize here; it's like Twitter, where some people use Likes to remember all-time favourites and some people use them as an "I've read this" checkbox.
I might Star e.g. Postgres (yeah, I know, not their official repo) because someone told me that it's an example of good, elegant code, and I would like to study it. But that doesn't mean that I'm a Postgres user, let alone an adoring fan. I'm starring the code.
Let me pile on btw: great tool!
I think a vim mode would be great. The first thing I did was to use 'j' to navigate in the tree.
Vim keys is the closest console programs have to a common language! I seriously think all console programs should use a vim-like keymap. Not Emacs, because Emacs has a completely different philosophy - integrate everything into Emacs. Emacs is the prototype IDE. Emacs doesn't seek to export its keybindings, it seeks to import everything.
But without first class support for vi navigation, be will end up replacing tree as my directory preview pane in vifm.
This should teach anyone that tackling something that's considered "the basics" is not a bad idea. It is astounding how these really simple things can still be enhanced (or even revolutionised ;)) in 2020.
Can you please elaborate? Is that specifically because nnn doesn't show a complete overview of the filesystem or some other features are missing?
One of the guiding principles of nnn is to generate minimum disk IOs.
Reading through a complete volume on a stuffed microSD or SD card attached to a RaspberryPi to list the filesystem (even if compacted) and then supporting filesystem changes dynamically is resource-intensive. nnn development is driven by minimum resource availability and usage.
It simplifies a lot of workflows and reduces the number of keys.
disclaimer: my definition of "devops" is sitting in a remote terminal for where I run docker and chasing down which files take up all my precious space, or not remembering where I put something, which makes the tree overview very useful. I know I could achieve this via many other means also (and did before Broot), but Broot is also very pretty, so I quite like that, too :)
It's the keybind "S" with nnn (or "A" for apparent usage). You can also use the same option ("-S") to open nnn in du mode.
> the overview of multiple directories at once
I explained the nnn design strategy in my other response
> the gitignore handling
This can be added but it changes the current generic way of handling directory entries
> There might be more, but I would have to spend more time with it
That would actually be a constructive data to improve nnn as well.
Thanks for the notes!
I like how 'on the ball' you are with this though, it's that kind of passion that makes projects like nnn so strong!
#1 ask: please add a Vim mode for j/k navigation and / search.
but seriously, how to install from source is clearly shown
Especially the screenshots help to get motivated to try it and if you try it you will notice it just works as advertised - awesome :-D
then run the broot command and it will prompt you to update your .bashrc or .zshrc file
The homebrew version is quite behind though, it was 0.10.x when I checked earlier today, while the latest version is 0.11.x.
This is an awesome piece work. Do a "simple" thing extremely well! Well done
But I found one issue which might be a critical one:
When you start broot with "br --sizes", it shows you all the folder sizes. The tree than takes a while to render all the different files and folders, since they probably have to be recursively evaluated in size.
However, when you select a specific file, press space and then `rm` to delete it, the pointer might change to another file randomly. This is because the file list is still not rendered-out because of the file sizes beeing calculated, however, the pointer to the selected file should be persistant or you might accidentaly delete an important file.
In this case, I was flying through the file system like nobodies business in 1991 with Norton Commander
A rope and pulley attached to a vertically-moving platform existed for a really long time, and then someone bolted on a ratchet, and it became an elevator, which (with some iteration, and marketing) gave birth to skyscrapers. Another one is LXC, which existed for 5 years before Docker's confluence of features (and impressive marketing) made it ubiquitous and changed the [backend] tech landscape.
From ~1990 to now (yikes, 30 years!), I've used these:
- Amiga: Directory Opus (DOpus)
- MSDOS: Norton Commander (NC)
- Windows: Total Commander
- Linux: Midnight Commander (mc)
- MacOS: Tux commander
Looking back at old Directory Opus screenshots tickles the nostalgic bone. I miss the colourcoded buttons.
I wonder if Directory Opus was the first 2-split navigator, but probably not.
In answer to your question of which was the first, the answer appears to be PathMinder (1984) and Norton Commander (1986). Both were for DOS so it seems to be an original innovation from the DOS world. Directory Opus first came out in 1990.
I wasn't familiar with PathMinder before looking at the wikipedia article but I was familiar with Norton Commander, as I think nearly everyone who used DOS in the late 80s would be. I personally favoured XTree (1985) more. Xtree didn't originally have the two pane view, but added it in 1989.
Just as a data point, I tried that and I never could figure out how to populate the left pane and the right pane in such a way that it was helpful. (I.e. that copy and move did the right thing.) It just felt pointless to me.
I've used vifm a few times, but only after figuring out how to turn off the two-pane split :-)
De gustibus non disputandem, I guess.
I love how "FORMAT your disk without leaving your spreadsheet" is a feature
Being able to format a floppy disc and continue to do things on OS/2 without applications becoming seriously jerky was also a feature. (-:
CentralPoint PC Tools seems little remembered nowadays. It was quite an extensive toolkit, as I recall. File viewers for various types of database/spreadsheet/wordprocessor files. Disc and file hex editors. Repair utilities. Extended directory change. A uniform look and feel, and a fairly good manual.
The Graham Utilities was another one.
There seems to be no trace of things like InspectA (another OFM for OS/2) on the World Wide Web.
Indeed, up to the point that the name was usurped by some unrelated software.
It was very useful even in the later DOS era; it was a standard part of my travelling tech toolkit. It had one of the fastest floppy formatters around, and just about the fastest DOS disk-defragmenter I ever saw, nearly an order of magnitude quicker than Norton's.
The PC Tools backup/restore tool was also superb and extremely fast. It used an extended disk format, squeezing about 1.6 MB onto an HD 3½" floppy, and compressed data on the fly, so many megabytes of software or data could be squeezed onto the minimum number of floppies.
Unlike rival extended formats, if you tried to DIR the disk from DOS, you got a warning message:
What doomed Central Point software is that it did a licensing deal with Microsoft. Cut-down versions of PC Tools Backup and the separate Central Point Antivirus were bundled with MS-DOS 6. Microsoft promised CP that CP would make money from DOS 6 customers wishing to upgrade to the full versions.
In actual fact, people got by with the freebie versions and CP's sales of standalone products _and_ upgrades both stagnated.
MS tried similar tactics on STAC in the hope of bundling the Stacker disk-compression tool with MS-DOS 6. STAC, wisely, said no.
So Microsoft just stole the code and used it anyway.
STAC sued, won, and got $120M damages.
It used the money wisely, to diversify the company out of disk compression by acquisition, buying vendors of remote-control software (ReachOut) and enterprise backup (Replica).
Sadly, this was long before ubiquitous Internet connectivity, even by dial-up modem. ReachOut mainly worked by direct-dial modem-to-modem comms -- useful, but expensive, as each machine to be controlled needs a modem, a telephone line and its own phone number.
It wasn't enough and STAC ended up going broke. Central Point Software was bought out by Symantec, like Quarterdeck and Norton and others.
MS-DOS 6 was badly buggy anyway and MS had to release a free update, MS-DOS 6.2. (Note, at this time, product updates, service packs, etc. were extremely rare.)
Then, when it lost the STAC lawsuit, it released another update, MS-DOS 6.21, which simply removed disk compression altogether.
Then MS rewrote the offending code and released MS-DOS 6.22, another free update, replacing the infringing "DoubleSpace" with "DriveSpace" -- basically the same tool but with different compression/decompression routines.
This was the last-ever version of MS-DOS, and thus DOS 6 has the dubious distinction of being the most-patched release in history.
There are details of this on Wikipedia but it's been sanitised by MS PR so it merely mentions patent infringement, rather than the direct code theft involved.
It was insanely good.
Its available on FreeBSD so it must be available on Linux and macOS at least ... not sure about Windows.
It's (also) ActiveX (generic scriptig host, COM objects from/with scripts, etc.) scriptable and fully configurable. Just like in the good ole' days.
Idk what happened exactly, but now I can’t stand commanders at all.
I've used it as a replacement for Total Commander on the Mac.
Another posted posted Marta, which I just downloaded and it seems to have almost the same features as Total Commander but in a free/open source offering.
Forklift made some questionable choices in the version 3. The app became much slower.
To install - brew install nnn
The two-pane file browser (folder tree plus folder contents like Windows 95 Explorer, or two parallel panes like Norton Commander) was a compromise solution that has worked for decades.
But this idea of showing in context a limited view of representative items of each collection could be generalized and exploited in other generic data-heavy interfaces, where there's no business code to show the specific data loads in the best way.
I don't think there is a standard widget other than what's implemented by each solution. Broot is one way of looking at a volume at the expense of lots of disk reads (for every file on the volume). Ranger does that at a single depth and that's a design choice in Miller's view. nnn doesn't prefer to read within directories unless explicitly requested and that's a design choice too. There's nothing good or bad about these other than a choice to the user to pick the one that fits his use case.
A user always has the liberty to concentrate only on the current directory, just know where he is in the filesystem from the file path and do a fuzzy search to find a file deep in the subtree when he needs to do so. As you might have noticed, even with Broot there's no simple way to list the files marked "unlisted" without navigating to the dir and expanding it. It's a nice program and is a solution to people who likes to see a snapshot of the filesystem in a glance. But would everyone be always interested in the contents of /etc, /run, /usr and /var as shown in one of the sample images?
There are ways to avoid traversing the whole volume in each use, namely caching each directory content when it's updated.
As for always showing unwanted information, an interactive solution could allow an option to "fold and hide" specific folders so that their contents are not shown until the user specifically reopens them. A user-friendly interactive solution doesn't require the user to remember and choose among all the available choices for each use, it provides good defaults and reminders on how to access alternative options when those are needed.
I've also used Total Commander for a while. I haven't seen any directory or file manager that is better.
Far Manager is better, of course :)
Pictures illustrating exactly what it does, something many people/organizations cough oxide.computer cough don't do properly.
I'm not the most technical person but I could easily understand the purpose of the program by quickly scanning the webpage. The combo "clear headline + demo screenshot" is all that's required to explain what the product features are, and how I, as a user, can benefit from this product. There is even a blob of text available under each screenshot, for those who want to know a little bit more. (Reminds of "The obvious, the easy, and the possible" )
A lot of landing pages of SaaS products and other tech-related websites could benefit a lot from this "old" but straightforward approach, instead of trying to sell you a better lifestyle with "Be productive" or "Break free" or "Solve all your issues" marketing headlines.
As you can tell by most of comment I think this isn't the whole truth and that really things live somewhere in the middle and that the domain and scope of interaction greatly shift this spectrum one way or another, picking a doctor/lawyer vs picking and IDE comes to mind for myself, YMMV with that example and might even further drive home the point.
Long story long, marketing is hard and the people doing the marketing often aren't domain experts and have to rely on the information passed to them through a convoluted game of telephone via authors and experts that can't even communicate everything needed to be effective because they themselves aren't good at teaching.
Looking at oxide.computer... man... what DO they do? Do they sell servers?
My other pet peeve for these kind of websites is when the landing page is full of just release notes and links to tangentially related articles news articles and talks about the product, and it takes me 10 minutes to figure out where I can actually read about what the heck product I'm even looking at, and why I would use it over other products in its class.
This XKCD about uni websites gives the general gist of what I'm talking about https://xkcd.com/773/
Some Github repos are also awful. The README should summarize what the product is or link to a website that does.
The Kotlin and Elm websites are pretty good:
It's hard to find some really terrible ones right now...
Apache products tend to take some effort to decipher what it is they even do or how they'd be used. They have a nice summary description like the start of a man page, but that's about it.
The GitHub landing page is surprisingly worse than you'd expect. It's not terrible... but check it out in Incognito / Private Window and imagine you'd never heard of GitHub:
Compare the above, with how cleanly and clearly Travis-CI manages to express what it does, and why you would use them, along with a useful screenshot of what the UI looks like right near the top of the page, so you can get an idea of what it would be like to use in practice:
* lsd - https://github.com/Peltoche/lsd
* sk - https://github.com/lotabout/skim
* hx - https://github.com/sitkevij/hex
Have you compared `skim` with `fzf`? And `lsd` with `exa`?
Discovered `fd` and `bat` when I scanned this thread and immediately started using them too. :)
I'll try and evaluate and choose between `exa` and `lsd`. Already switched to `exa` but will still analyse `lsd` to make sure I am not missing out.
Can I ask... why?
What is the difference between a program that makes you feel "oh boy this looks so good" written is some XY language, and the same program with the same functionality written in Rust?
Every non-standard tool that you get in the habit of using is another piece of friction when switching machines or using a machine not configured as your own, where you may not even be able to install things. With Rust, I know I’ll be able to get it going easily, regardless of whether it’s in some OS-level package manager: it’ll be a single binary that I can just drop into my personal bin directory, and it’ll just work.
Seriously, the deployment story is just so good for languages that compile into a single statically-linked binary, when compared with dynamic languages.
So my threshold for “will I bother trying this non-standard tool out?” tends to be much lower for something written in Rust. I have several Rust utilities that I take the trouble of installing, and now only one non-Rust utility that I use in this fashion, git-revise (Python, and git-rebase is generally a tolerable alternative if I can’t set git-revise up).
Well then, back to my narrative. I wasn’t actually expecting it to be in Rust (though on reflection, why not?), but when I saw “cargo install broot”, I cackled aloud.
And I’ve just run `cargo install broot`.
It means the thing is lightweight and fast. And also - unlikely to crash or eat my drive because of sloppy UB.
"I sure hope this isn't written in Node."
Is this experience atypical? I've actually been running through the getting started guide for rust-lang as it left a positive impression on me. Something like this in C land seems unachievable.
Those of us who like to charge in to CLI tools all guns-blazing-like would appreciate it. Also, it would immediately communicate that the project is written in Rust, which some people may like.
Note that broot is far from new and is reliable on linux. I used it daily in the past 10 months. The only thing which prevented me from tagging it 1.0 is the rough edges on Windows.
I am not sure if you have something to do with the "brew" installer for this on MacOS? Or does someone else create that?
Anyways, looks awesome, I think I'll use this at least for listing files by size.
This could use some documentation imo. Like the essentials of what 'supported on Win10+' means (is it supported in powershell, or command prompt or bash running on msys or ... ?) and how to laucnh/install it. I only looked briefly, ran broot in cmd but the only thing I get out of broot is that it creates a file <AppData>\Roaming\dystroy\broot\data\launcher\bash\1 and a link (even when entering 'n' instead of 'Y' when it asks to install!!). So I figured it maybe needs to find a 'br' command and added a function 'br' in powershell and launched that, but it still says it's not installed.
Another developer already started to work on a `br` function for windows: https://github.com/Canop/broot/issues/78
"The easiest way to read and edit broot's configuration file is to go the help screen (using ?) then to type :open."
When I do that, I get "verb not found: "open"". Not quite sure what is supposed to happen here. I found the config file and editted it manually, but was some magic supposed to happen with the "open" verb?
Terminals have sped up, but the amount of terminal I/O to draw a screen has increased, too. Nowadays there are lengthy SGR 38/48 sequences for 24-bit RGB, plus the other SGR sequences for attributes, plus of course characters that are now commonly multi-byte UTF-8 encodings, including box drawing characters.
So the old considerations of optimizing terminal output still apply nowadays to full-screen TUI applications. Optimize out cursor motions that move to where the cursor currently is; replace absolute motions to nearby positions by shorter relative motion control sequences; optimize out superfluous attribute and colour changes; replace onwards horizontal cursor motions by just rewriting the relevant characters; skip unchanged cells; and so forth.
The Rust full-screen TUI code in Broot (and common Rust libraries) does not do any of this.
When it is a Win32 application, it uses console I/O and this does not matter quite as much, although it's still a waste of system call context switches to overwrite a console screen buffer with what is already there. But when it is using terminal I/O this matters significantly.
The Rust terminal handling is actually fairly poor overall. This list, for example, is in reality a lot longer. The terminfo database records a lot more terminal types that understand these escape sequences. "putty" for one egregiously missing example.
Personally, rather than treat lack of capability as the norm with a paltry list of exceptions, I prefer the opposite assumption that (except for "dumb") the world has nowadays reached 1976 capability levels. (-:
Overall though, great tool!
I've been told that the bash file path I use on mac is wrong though: https://github.com/Canop/broot/issues/84
Obviously replacing username with your username...
One of the downsides is that it calculates the space everytime with -s option which makes it slow in that mode.
If you seek for really fast tool for that purpose then try ncdu which calculates the sizes only once at start then then does that only on your request by pressing the 'r' key.
Here is how ncdu looks like:
1. `cargo install dirstat-rs` (binary is `ds`): Prints several lines showing the size of the directory and the top fattest children. Colored output.
2. `cargo install dua-cli` (binary is `dua`): Only prints one line with the specified directory size. Colored output.
Both are insanely fast (they use all CPU cores). Love them both.
The bit that's not done yet is rendering an overlay in the web player -
du -h | sort -hr | less
I sometimes find it amazing that we do computer science for decades now, but there is still a lot of room to improve very basic things.
The gnu target seems to be fully static and run everywhere with no dependencies.
That’s why he said static, although I’m not sure gcc will produce totally static binaries anymore.
Anyway. This look super cool. I'm a Windows guy but have been using terminal more lately with tools like https://github.com/BurntSushi/ripgrep https://github.com/sharkdp/bat https://github.com/sharkdp/fd and they work great on Windows (plus are easily installable by https://scoop.sh/). Hope the Windows story will improve for Broot to.
Some suggestions after very quick look (except not working Shift key on Windows).
* Screen refreshing and general experience is really slow. Hold arrow key for couple of seconds and see that refreshing can't catch up. The best performance is on standard windows cmd, a bit worse on new "Windows Terminal (Preview)", absolutely horrible on ConEmu (which I use daily :-( )
* I sort of expected that I can "scroll" current directory but I get "400 unlisted" text at the bottom. It makes sense for nested directories and looks like main feature of Broot. But for _current directory_ it would be great if it didn't "trim" entries at the end and you could just use standard arrows keys, PageUp/PageDown and Home/End to quickly glance and see what files are available when I don't know what file names I'm looking for. And when I would want to do the same for some nested directory I would just select it with Enter.
So basically it would be great if Broot was more like https://github.com/junegunn/fzf but not just for flat list of files.
- The backspace key quits the program. I've accidentally quit so many times after deleting my filter by holding the key down.
- The filter seems quite quick at first, but when I add a period it slows down massively. ie. Search for "xorg", then "xorg.conf", the moment you type the period it hangs for a good few seconds, even though it's in the top level of my home folder. A breadth first search should find it trivially, so I'm assuming it's some quirk of the fuzzy matching.
See https://superuser.com/a/496152 for screenshots.
* on a file it opens the file (in the same terminal if possible, depending on the system file opening)
* on a directory it does a cd to that directory and comes back to the terminal (if broot was launched with the br command)
I'd like Mac users to chime in and answer you now: I can't really test on mac.
Good job btw, Broot looks awesome!
EDIT: Found https://dystroy.org/broot/documentation/configuration/
and on macOS the config file is located at ~/Library/Preferences/org.dystroy.broot/conf.toml
1. support vim keybindings
2. support editing text files inside the terminal as ranger does
Can it be configured to just open file in vim or other eidtor? May be in a subshell, so you can return back to broot. Why reinvent the wheel...
on the other hand, grep/find GNU tools all should be upgraded to ignore .git/node_modules/pip-site-packages by default, and honor .gitignore,etc.
I don’t know if it’s faithful enough for you
Only dealbreaker for me unfortunately is that it forces me to use up/down arrows, i.e. leave the home row. I use ctrl+p/n everywhere (or ctrl+j/k in some tools), be it in the terminal or on macOS.
Given your workflow, you might want to give ranger a try?
Just for those who don't want to learn more ... you can get a lot of similar utility experience using:
`tmux` (for panes with mouse support) and `fish` (for autocomplete)
I prefer to handle lot of the additional function over `ls` or `tree` that is offered by `broot` in separate panes.
I just feel it is more manageable and interactive with a lot of flexibility.
"frontendaction" will match "frontendaction.txt" but not "frontend/action.txt"
"frontend/action" will turn the search into a regular expression and complain
It's quite beefy for such a tool.
but does anyone has an idea if there is a way to customise file sorting?
There's the "fat whales spotting" mode, which only displays one level and sorts by size, though, and I plan to extend this mode to other sortings.