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.
Occasionally that better execution is overlooked because it looks like just a bunch of features, but a confluence of features often changes the game.
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.
And before them both, chroot jails... at a high enough level of abstraction this reminds me of "there are only six plots", but occasionally a book will change the world.
These types of file-managers are called 'Orthodox file managers'. [1]
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.
"Double Commander (https://doublecmd.sourceforge.io/) is a free cross platform open source file manager with two panels side by side. It is inspired by Total Commander and features some new ideas."
> _Once you get used to two panes, it's hard to go back._
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 :-)
In the days of applications with no concept of standard file dialogues, running on single-tasking operating systems, for platforms where disc media were sold unformatted, and needed low-level formats, it really was.
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.
> CentralPoint PC Tools seems little remembered nowadays.
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.
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.
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.
I can't believe DOS Navigator [1] is not mentioned - true MDI in TUI using Turbo Vision. Ran circles around Norton Commander. Even had a freaking spreadsheet built-in!
for the current windows platform there is far manager: https://www.farmanager.com/ Unlike Norton it has plug-ins and there are a lot of them available.
Counter data point here. NC/VC since 90-ish, TC, MC, Far. Then suddenly it all lost fit and explorer/finder felt much better, with many windows and quick access pins. Explorer still lacks Finder’s inplace folder expanding, but that’s bearable.
Idk what happened exactly, but now I can’t stand commanders at all.
Fixing the number of panes at 2 seems a little arbitrary. I used dired in emacs and open precisely the number of panes I want: most of the time 1, fairly often 2, once in a blue moon 3, and I've never needed 4.
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.
Double Commander seems to be the most popular and featureful among cross-platform two-panel managers. However, its integration with the rest of the system is rather lacking on Mac.
Forklift made some questionable choices in the version 3. The app became much slower.
There's a significant underlying principle there. Commom UI widgets are not prepared to deal with collections of widely varying sizes.
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.
It's the zero/one/infinity rule. Programmers don't even know what it's called, they just absorb it by osmosis. But in the real world there are so many lists that will never have more than 20 items.
Well, I'd say the rule should be upgraded as zero/one/small-sample/expand-for-infinity, at least for user interfaces (not for coding, although doing it for coding is what lazy evaluation is for).
> Commom UI widgets are not prepared to deal with collections of widely varying sizes.
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?
Anything listed at https://en.wikipedia.org/wiki/Graphical_widget#List_of_commo... does count as "standard widgets". There may be variations in different GUI libraries, but anything that deviates too much from common user expectations will be perceived as broken.
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.
One of the guiding principles of nnn is minimum disk IOs so probably it's not comparable in this respect. Reading through a complete volume on a stuffed microSD or SD card attached to a RaspberryPi to list the filesystem and then supporting dynamic events may not be very simple. nnn development is driven by minimum resource availability and usage.
Yes, but that's a less informative solution, as you can only see contents of one directory at a time. Broot provides a more comprehensive view of the file system.
I assume you all know Midnight Commander (mc) - because of my Norton/Total Commander past, this is still something I always install on my machines (although using it less often)
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" [1])
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.
I think the reason this happens is because there is a belief that, and who knows maybe it's the truth, people buy emotionally. Business and marketing books (E-myth and How to win friends come to mind specifically) constantly parrot that "sales studies" and "marketing research" show that people buy, or this case download, with their feelings. This seems to lead people to add vacuous fluff to marketing pages to "appeal" to someone's emotions.
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.
Yeah, love this! I hate when I can't figure out what a software or service does from their homepage.
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.
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.
https://ant.apache.org/https://hadoop.apache.org/
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:
https://github.com/
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:
https://travis-ci.org/
I had this immediate assumption that this was implemented in Rust when I saw the landing page. Didn't know for sure until I checked Github, but lo and behold it was which I think is funny. I sense a trend where new and interesting projects are usually implemented in Rust.
I used to use `skim` a fair amount, but over time I've gradually found myself defaulting to `fzf`, but YMMV. I haven't personally used `exa`, but I do like `lsd`. I would also vouch for the other three tools mentioned by eerrt (`ripgrep`, `fd`, and `bat`).
Was reading and thinking "oh boy this looks so good, I wish it was written in Rust..." and then reached the "Installation Instructions" just to see "cargo install broot". HERE WE GO
> Was reading and thinking "oh boy this looks so good, I wish it was written in Rust..."
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?
When I saw the landing page, I reckoned it looked good, and then I thought these very words to myself as I went to the installation page: “ah, but is it written in Rust?” Because if it is, then I know I can install it both quickly and easily, and expect it to run fast as well. Command line tools written in Perl, Python, Node, JavaScript are always more effort to get going, and much more effort if you’re (a) using Windows, or (b) unwilling to pollute /usr or equivalent with things that won’t be managed by the OS’s package manager.
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.
I think it's a brain shortcut from "Oh nice, this thing won't startup a VM that fill my RAM and peg my CPU". Would you run `ls -l` if it were written in Java or Javascript ?
Maybe they are one of those people that can't help but comment that things should be rewritten in rust, but is also aware that doing so is annoying. Someone like that might want software to be already written in rust so they don't have to annoy anyone.
Is cargo known for build problems? I've never used it before now and I took a shot in the dark with `sudo apt install cargo`, then `cargo install broot` went off without a hitch. I just had to add ~/.cargo/bin to PATH and I was good to go. This was in WSL no less.
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.
I wish the Github UI had an user experience like this. I do a lot of directory tree navigation in the GH interface these days, while searching for algorithms and examples for a new project and it's horrible how much time I'm wasting on clicking into and stepping back out of folders trying to get a glimpse of whats in them. The lack of file sizes and filetype icons make it even worse. GH file navigation feels like a step back from where we already were in 1986 with Norton Commander.
Loving everything about this. You really knocked it out the park. It's so much more ergonomic than cd + ls (which feels like a caveman solution by comparison) Congrats on bringing directory navigation into the 21st Century. I have installed it on all my servers and I will use it forever. Long live Broot!
Don't want to downplay broot, but fzf has been around for a while and when I first discovered it I had the exact same idea 'YEAH finally directory/file navigation for the 21st century' :) Mainly because of the fuzzy matching, and because of the ways to extend it and because it works on most platforms. Possibly there were already predecessors though, not sure.
I don't think interactive tools such as broot are meant to replace standard shell commands. Interactive tools are more user-friendly, but classical shell commands are easier to script and pipe together.
pro-tip: I think a lot of people would really appreciate it if you put a quick blurb about installation at the top of the GitHub README and on Broot's landing page. It took me about 30 or so seconds to find the installation page, which gave me enough time to think that this was still new enough that you don't want to hand it out like crazy yet.
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.
Author here: thanks for the tip. I'll do that. edit: done.
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.
As a Mac and brew user I would have needed to see "brew install broot" somewhere - since there is no Mac binary I was not sure how to test this until I looked at the comments here.
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.
The problem is I don't know exactly what works or not on windows... I'd need an involved tester/coder familiar with Windows to help me for that (you can volunteer on miaou: https://miaou.dystroy.org/3).
broot looks really useful - thanks! One comment: on the configuration web page, it states:
"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?
I love it, but it's REALLY slow in Windows on the new MS Terminal, which is typically actually quite fast. Noticeably laggy and I can see the screen redraws. Anyone have any idea why, or how to speed it up?
In the 1980s, full-screen TUI programs did significant work to optimize terminal output. A complete redraw of an 80 by 24 screen at 300 BPS was not quick. So applications normally only wrote changes to the screen, only performing a full redraw when requested by a Control-L input (or some such).
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.
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. (-:
Loving it, but it's very slow on refresh on Linux over ssh as well. Looks like it's doing full screen refreshes on every change instead of just using delta's that tui apps should be doing.
Judging from the landing page, it seems to be a file manager and not an alternative to tree(1). If so, another one that's also handy and shows you a preview of the files one level up and down the directory tree is ranger(1) --- and it has vim keys which makes it extra great.
Does your release process include publishing to brew? I ask because brew only has 0.10.3, whereas crates and github show something a few versions ahead (0.11.3). Looks awesome!
I really liked broot after using it for several minutes.
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.
I did in the past but the problem of asccinema for applications like vi or broot is that people don't really understand: you hit two or three keys and the stuff is magically done.
I tried it and think I'll keep using it mainly for the "See what takes space" mode (I haven't encountered an alternative that works in terminal, but I haven't looked, either).
Just a quick remark but for a simple command line utility, I really like a static binary you only need to download, drop into a directory in the path. I am always wary of tools that need to install either a python or node.js distribution, because this seems unnecessary bloat, and might mess with local install if you are not careful.
Strange that Chrome doesn't appear to trust broot.exe. When that binary is downloaded, the downloaded file message is: broot.exe is not commonly downloaded and may be dangerous.
But they only work with a subset of architectures (only x86_64 in this case) and a subset of OSs (Windows with GNU installed, Linux with GNU libraries including libc and libgcc)
Rust on windows has targets for msvc or gnu. The MSVC integrates better with Visual Studio and other Microsoft libraries for development. One downside I've found is that it dynamically links against a msvcrt DLL. Which means you may need to download and install a Visual C++ Redistributable package to run.
The gnu target seems to be fully static and run everywhere with no dependencies.
Looks like really cool and useful project. Is it usable on Windows though?
I can't press Shift key to enter ":" for commands. Seems like a dealbreaker. I tested it on WSL and Ubuntu on VM and Shift works there.
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.
Really cool. For some reason when I opened the webpage I was like "this seems like it's written in Rust" and it is! I'm using Rust as my main language for the past 6 months now so it makes me happy :D
This is really great! Two things that could do with improvement:
- 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.
Is it something I'm not understanding or a bug, but alt-enter does the same thing as plain enter? (macos, zsh, iterm2, fi-locale. Installed through cargo, the executable installed the br thing)
MacOS Terminal and iTerm users need to configure their terminal to use the Option key properly. You need Option-Enter to output either Esc+Enter or Meta-Enter.
I tried, but sometimes I actually need the Alt key to behave like it does by default, to enter modified characters such as ~ (which is not on my keyboard). Any other ways?
It's not supposed to do the same thing. alt-enter closes vim:
* 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.
You need a new idea! I suggest making a brown tree shaped tree with shades of green for the leaves and a monkey to navigate it using a controller. Brown leaves for deleted files. The monkey shakes the tree and you catch the leaves you want to keep. It can also chew off branches.
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.
In order to install this you'll need 200mb rust + 100mb in .cargo dir it will drag along and then wait like 3m until it compiles this, jesus christ cli app.
Agreed, but I don't see a use-case for it given that we have ranger[1].
I find the two-pane navigation + embedded preview + easy opening of files when moving into them to be a perfect combination.
Given your workflow, you might want to give ranger a try?
bat is another nice rust utility, a kind of combination of cat and less with line numbers and colors. If there's more than a screenfull of text it acts as a pager, otherwise like cat.
Anti-GUI developers can now get the benefits of GUI visualization while still being cool enough to stay in the terminal. See also: dired-subtree for Emacs: https://www.youtube.com/watch?v=z26b8HKFsNE
Super nice. Here's an issue: why when you search the cursor is not the first in the line ? it makes no sense when you make enter when you already know the path and want to go fast
Was anyone able to make this work in WSL? I can run the broot binary if I specify the path to it, but even after running the install script, trying to use br doesn't work.
I miss my Far Manager, working on Linux now...
Just remembering how quickly I was doing stuff in directory structure, people couldn't even follow with their eyes...
thanks to this i looked at Rust again. Going over the Rust book: https://doc.rust-lang.org/stable/book/. The concepts of ownership and borrowing made instant sense whereas before I had ignored Rust after hearing that it was way too complex. I think I just might take it up as a hobby.
Works for me. The "Installation" page includes the phrase " (supported shells today are bash, zsh and fish)," for it in the section on the shell function.
tested with mosh with black-on-white color scheme and it doesn't play nicely with that combo - text it prints is color-on-black; i'd rather have it redraw the whole terminal or (better) keep to the terminal color scheme
thanks for thinking about that! do you think there's a way to identify that the terminal is black-on-white and use something like that by default? i don't really care that much about specifics as long as it can pick one automatically depending on terminal settings.
They aren't quite there yet. Still need to realize that having 2 panels side-by-side would eliminate any need for typing when copying and moving stuff around.
Also an XTree-like info panels around the tree itself would help tidying the layout and increasing info density.
you can just vim into a dir and get a collapsible tree. i don't see any reason to invent yet another tool for something tree -f | grep foo can do. More supply chain hell, more useless tooling, more bloat IMO, prob for some junior dev's "portfolio"/"resume".
How I did it (though not using CentOS, should be identical):
Install rustup from https://rustup.rs/ (download & run the shell script).
Then `cargo install broot` to download and and install this. Then run `broot`, and restart the shell. After that it can be invoked via the `br` command.
I'm one of those skeptic people who always criticize just because I'm a negative person. However... I LOVE THIS PROGRAM! I really, really, really love it!
I don't care if it's been done before. I don't care if <insert name here> exists and does a similar thing.
Awesome because:
- 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!
Please accepts my sincere congratulations and appreciation for your work on broot too! (Et bonjour de lyonnais à lyonnais pendant qu'on y est!) And I see you work for this french group now, and I'm pretty sure one of my plant management software is deployed at one of their plants - the world is small!
It never occurred to me before, but it'd be great for GitHub et al to have a way to leave kudos and thank-you notes. As things stand, the only affordances are for leaving issues and complaints, so it's not surprising that that's what get left.
I'd be happy to use a first-party system designed for simply saying why I like something. However I'm not willing to create a Twitter account just so I can thank someone when we've never met (and likely never will), and are likely never to speak to each other again. Same deal with signing into other services through GitHub (like gitter), that might start sending me emails (when signing in via GitHub, the service gets your email address; so far as I know, gitter doesn't use it for anything, but other services might).
I've done that a few times, and always felt anxiety before hitting "submit". So far I've had mostly good reactions to it, but I've also had it ignored and the ticket silently closed.
Unclear, I think. I tend to use GitHub stars as bookmarks, which implies interest but not necessarily hearty approval.
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.
Besides the thing sibling commenters mentioned about GitHub Stars acting like bookmarks, I also feel that GitHub Stars are more intended to be used to indicate interest in the source code itself—which is a bit different from indicating interest in the product you get by compiling said source code.
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.
Strongly agree. Keyboard interfaces can be very fast and efficient, but their weakness is having to learn a separate keymap (or set of options) to use a new program.
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.
That was first thing I did - check if I can navigate vim style. However it has different philosophy. It has fuzzy search, so that you just type name of directory which you want to enter, it will be filtered out and hit enter. Now you can explore it.
Same. It seems like it could be useful, but I'm virtually handicapped after decades of vim mode in a sense I cannot efficiently use any software that doesn't support vim keystrokes (well, nobody really can, they just don't know that).
I too agree with strength that is strong. Just yesterday I was googling how to get tree to respect my git ignore. The universe heard and responded with broot!
But without first class support for vi navigation, be will end up replacing tree as my directory preview pane in vifm.
I second this. This has replaced nnn for me and solves so many devops headaches. Excellent work!
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.
> This has replaced nnn for me and solves so many devops headaches
Can you please elaborate? Is that specifically because nnn[1] 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.
You know, I hadn't considered that. This distinguishes nnn from Broot. I would revise my comment if I could, but in the absence of that ability, consider this my correction.
At the risk of embarrassing myself: The ":s" verb for easily viewing the size of directories / files, the overview of multiple directories at once, the gitignore handling, at a glance. There might be more, but I would have to spend more time with it.
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 :)
+1 I use a combination of Linux tools all day to achieve this: ls, tree, ranger, ncdu. Thanks so much for writing a tool built primarily for directory exploration. This deserves to ship in Ubuntu ASAP :-)
#1 ask: please add a Vim mode for j/k navigation and / search.
I can't agree more. I don't understand why other software developers think (or don't care) that it's okay to have tedious installation instructions and or controls. I'm a developer and I want to get my new tool and start playing with it, not spend hours with configuration and setup.
I was unable to cagro install it, had a bunch of build errors. Decided to brew install it instead, and although its a major version behind the github release, it works as advertised!
Is there a way to make Broot respect the terminal theme's colors? If I have a light theme running, br doesn't care and uses a dark background, and when I run it with --sizes half of the screen has a dark background and the other half is light.
Hmm .. I wish there was an IRC or Gitter chat. If I try to select some files with a regex like /SomeTVSeries(.*)mkv .. it selects everything, but then a space mv and new path only moved the currently selected directory or file.
There is a section in the help about using verbs on a selection, but nothing to indicate how to turn a regex search into a multiple file selection (can't tell if this is supported or not) ... I guess if it's not it would be a neat thing to see if I could add.
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.