I am broot: The Reg chats to French dev about Rust tool that aims to improve directory navigation Rust developer Denys Séguret, from Lyon, France, wanted a better way to view and search directories, so he coded his own, sparking interest from others with similar frustrations. Broot is a command-line utility for listing and manipulating files and directories – basic functionality that you would have thought could hardly be …
Yeah, right. Just had to write a script to generate a bunch of local users on a Windows[*] machine, together with passwords generated by a certain rule. Good luck doing that as a mouse jockey.
[*] work. Only run different flavours of Linux at home. Really grateful for my boss, who used to be a real Windows Sysadmin - he has tons of scripts to do this type of things.
And in which way does an "interactive", semi-graphical command-line tool help you in writing your scripts, opposed to - say - a true graphical one?
Hands are on keyboard.
It's not that a graphical interface is wrong, it's just that graphical interfaces have a tendency to add a tool bar and demand mouse interaction, which is good because of discoverability, but bad because it's much slower than just pressing keys (muscle memory works with the latter but not the former)... and yeah, you have keyboard shortcuts in GUI apps, but often, they're a bit of an after-thought.
But honestly, just use what you like! Command line things are often not so great if you only use them very occasionally because then the lack of discoverability is very much a negative.
Me, I like command line for certain tasks, such as file-management because they're fast, and I can use them over SSH. Plus, startup time... command line stuff is usually pretty instant. Starting even a light-weight GUI app typically takes at least the best part of a second, which is annoying slow when you're in flow.
"muscle memory works with the latter but not the former"
My muscle memory works just fine with a gui. In fact, given the various strengths (spacial and layout) and drawbacks (memorising strings) of my memory in general, I'd say I works best with a gui.
When I say muscle memory, I'm talking about the ability to (in this case) press a key or combination of keys, without even having to engage the conscious mind. If you need to use a mouse to click on something, it may certainly be something you don't think about, but you *do* focus your mind simply be virtue of *having* to look where the mouse pointer is to click on something.
Things like walking, running or riding a bicycle are things that end up in muscle memory. GUIs certainly get easier once you are familiar with them, but I'm pretty certain that isn't quite muscle memory.
But... it's possible your (and other peoples) minds are wired different to mine.
Yes, from the 1980s people started to think GUIs and IDEs were a good thing to manage large projects, but then Linux opened the door to all the loonies who believe you are a true computer user only if you use the command line only and type arcane commands.... and the strange idea you have to suffer to get anything done or it's not a good way - which is strangely akin to what religions do and say.
Really, that was a problem I had with DOS 3.1 before I bought Norton Commander... someone is still almost fifty years late.
Personally, I never warmed to NC, or mc, or tree, or ISPF member listings, or OS/400's WRKF, or any of those other full-screen filesystem navigators. Or to their GUI equivalents. ls and find, on their own or as part of a pipeline, have always seemed more straightforward to me.
But to each their own, at least as far as incidental use goes. For system-administration tasks that need to be audited or repeatable, I think anything other than a script (in whatever language) is pretty daft.
On the development side of things, at least command line tools offer the benefit of avoiding to design a graphical interface, with all the bikeshedding that comes with it.
And it's easier to repeat a basic task with command line tools than with a GUI
That is a shame, since Broot can do something the Windows File Explorer cannot, which is to show how much space is occupied by a directory including all its sub-directories.
How about right click, Properties? That gives you the total logical and physical sizes of all files plus a count of files and subfolders. Well, at least on Windows 7 it does...
Even more so - there are extensions, which do this if you wish. They even come with options to exclude slow (network) devices and whatnot. One such tool is called "Directory Opus" (https://www.gpsoft.com.au). This software came from the Commodore Amiga, which tells us how old the solution to his problem is ...
Yep. Current fave is XYplorer which does well even in the face of millions of files on multi-terabyte arrays. Everything for finding things, set to list in directory order. That combination works on the graphical end. Naturally, I'll be looking at broot for console. Pattern matching. Yum.
This is probably the most useful tool on the Amiga once you have a HDD (and even for floppy disk file management).
I still have it on my real and virtual Amiga's, though I never got on with version 5, which was almost a replacement for Workbench, and hence stick with version 4.something.
For the creators of all versions of Directory Opus -->
How about right click, Properties? That gives you the total logical and physical sizes of all files plus a count of files and subfolders
But will overcount when symbolic and hard links are present. (Which NTFS does support and Windows makes heavy use of in places.)
Whether Broot takes these into account I have no idea, but given a Linux background I would hope so...
How about right click, Properties?
That works if you want to see how much space a given folder is taking up, but if you want to know, at a glance, which of the 50 folders in your directory holds the most data then you'll need a pen, paper and patience.
Hence the reference to TreeSize Free, which is an incredibly useful tool.
Hence the reference to TreeSize Free, which is an incredibly useful tool.
[cough] WinDirStat. [/cough] :)
I just use
$ find src
And get a recursive listing of the entire folder. Great!
Too many files? Then if you do:
$ find src | less
You can use arrow keys and page down. Then in the pager (less), just use '/' to search for specific files.
It honestly is very easy. You get a much better overview than even a GUI file manager.
You do understand the word arcane, right? It's easy when you know how...
I prefer command line purely because its repeatable and I can save a command to do exactly what I want, vs. mind numbing repetition.
Still a crap solution for those who have typical jobs/purposes
Just sounds a lot like people arguing in favour of their paper based filing systems - sure *you* can find the file quickly in *your* filing cabinet - what about the rest of us?
You do understand the word arcane, right? It's easy when you know how...
Why is having to learn such a bad thing these days? Many of the GUIs in the 90s fell into that category too, you learnts how to use them then transferred the skills between apps. (eg, learning that the middle button woukld bring up a context menu for example).
Still a crap solution for those who have typical jobs/purposes
If your job requires you to do a 'thing' then learn to use the tools to do that 'thing'. I want some building work done I hire a builder, they know how to use all the oh so fun but dangerous building tools that I'd merely make a mess with. Computers are complex and sometimes require a bit of knowlage. (ie, if you learn about 'man' you can usually figure out most commands on a BSD...) We tried working with the assumption that everything is easy in the 90s which resulted in Wizzard hell. Great the first time, but those 94 screens to set things up are sure annoying the 1000th time through.
Most people would be better served learning that it's okay not to be able to do something the first time and having to learn isn't a bad thing or something that stops after childhood.
Yes, learning should be encouraged... but I dont think we should encourage everyone to learn what you know, or what OP knows. This article is about a better tool. If you hire a builder a hes using medieval wood scaffold instead a rig/crane/modern scaffold.... yea its bad, there is a better way
Usually once people know one way of achieving a goal they are not interested in a better way. So rather than sharing arcane knowledge and lamenting "these days", take an objective look and decide for yourself, but I dont think 3 commands piped together beats one for any standalone goal ( "thing" ), even if it is easy to do after acquiring the knowledge. You've got to read 3 man pages instead one. Better tools should be desirable, lots of damage is being caused by unsafe practices which are not helped by people following their traditions instead of learning a better way.
So, in short, you may object to my flippant tone but you've failed to convince me that the original poster had a valid complaint.
"I can save a command to do exactly what I want, vs. mind numbing repetition"
That's the main distinction for me between a CLI and a GUI. If you have to do the same (or very similar) thing over and over again, CLI (and scripting) is usually easiest.
If you're doing different jobs each day, the discoverability of a GUI will help.
Personally very little of my job could be scripted.
Who created this abomination based on a tree. Why not remove the filesystem and the horrible path, which isn't part of the object (unlike its name), and yet is integral to locating and manipulating the object? Someone should take a chainsaw to it.
For a minute there I thought you were talking about one of Larry's yachts. No that was a complete disaster because it tried to add a POSIX interface. You know the usual tree operations, graft lop, uproot, trim etc. It had no chance in the forest of file Operating Systems.
But it bothers me how few people nowadays are trying to build tools to do system administration tasks, but then their eyes gloss over when you mention xargs.
But, also, if you have to use special tools to look at your source code, then either your project is a badly planned flaming pile of shit, or you are trying to just do far too much. I do a lot of kernel development work and I've never had a problem moving around it. And sure, that's largely because I only work in precious few spots, but I don't know of anyone who has the skills to intelligently touch more than a small section anyway, I wouldn't even trust Linus touching a lot of the kernel's code, he's brilliant, but he isn't an expert in everything (And if he is touching a lot of stuff, its going to be stuff that can be automated with doing a find / xargs line and he's smart enough to just mark problems rather than trying to fix them all himself). I've found that people that make sweeping changes across a large project tend to be incompetent idiots that think they know better, but just leave giant messes in their wake.
I am also extremely leery about developers that try and work on a thousand different projects at once. Quality programming involves swapping a lot of state in and out of your mind, which takes time and effort. Time and effort that could normally be used to actually code. That is, unless the code is just so trivial that you can just bash away without thinking...
... I'm rather fond of one of the few useful tools that have been ported from DOS to the un*x world. That would be Midnight Commander (or mc, home page), which is a Norton Commander clone. It handles probably 98% of all my file management needs. Give it a try if you're unfamiliar with it. Something that has been around for over a third of a century must be doing something right ...
Second this. Midnight Commander is incredibly useful, and seems to have crept on to all my Linux systems somehow...
When I was using DOS, I preferred XTree Gold - but have grown to prefer Midnight Commander over the various XTree clones that *NIX has seen over the years.
I'm not sure why, other than the two pane paradigm is incredibly useful...
Broot is coded in Rust, of which Séguret remarks, “There's this thing quite new in Rust: when you make your code compile, it works and usually does what you wanted it to do.” Ho ho.
This is quite common in languages with a very strong type system (not the limited type systems of C, .NET and the JVM). Once it compiles, it just works. It does mean embracing the type system for maximum effect which is definitely a move away from languages like JavaScript.
It is possible to extend JavaScript to include strong typing.
JavaScript suffers from where it is in the eco-system and any language that is easy to use in the browser will suffer the same problems. I've seen lots of people writing why strong typing should not be added to JavaScript but none that really stand up to the problems not having it causes in the wild.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
