brew install superfile
(ok)
superfile
(not found)
find superfile
(not sound)
cd /usr/local/Cellar/superfile/1.1.2/bin
ls
spf
This is mentioned in the tutorial but it's probably worth mentioning in the install section to save people 5-10 minutes of confusion. Once I found the filename I loved it.
ok i'm a bit late to this post but can you explain why you use a terminal file manager UI? I've never found myself using these except very early in my computing career before I knew the DOS copy commands to use.
The first thing this app does is connect to Microsoft servers to download theme files, which for some reason aren't bundled into the binary. If you block it from accessing the internet, it crashes.
That's pretty bad for a terminal utility and file manager. The thing should never, ever connect to the internet for anything unless explicitly told to by the user. I didn't notice this, thanks for pointing it out.
Why is that the standard for a terminal utility and not GUI software? Why do we accept GUI software that does update checks and phone-home telemetry without configuration or consent?
I’m really curious about this, not to derail the thread.
Well, I don't. I use almost exclusively FOSS software that has no telemetry whatsoever, and where there is any phoning home, I either turn it off or make sure I know what it's doing and am happy with it.
I think it should be the standard, but fact is most computer users are entertainment consumers and their computing devices are just a new and improved TV. It doesn't even occur to them to ask what's going on, hence the ubiquity of proprietary spyware. With TUIs and other nerdy stuff like that, the userbase is generally going to give a shit more, hence the higher standard.
"You can go to the latest release and download the binary file. Once it is downloaded please excrate the file after that enter the following in your terminal:"
Is excrate some new jargon meaning to take something out of a crate? Or just a boring typo for extract?
Looks nice. I dig the nerd font thing, I'd never used them because all of my TUI stuff is ncurses and the like, it's a nice thing to be able to do. I like the outline. I don't like a few things.
- Ctrl keys galore. I'm partial to vim keys, a lot of the keybinds on here are vim style, why not make it all of them?
- some of the defaults are weird or potentially dangerous. There's no confirmation for deletion for example, PageUp and PageDown don't work, cursor auto wraparound is a little confusing for something like this, and the cursor isn't a highlight, just a >.
- Bubbletea always seem to have a minimum terminal size which drives me nuts. Btop and other programs I've used have this problem.
All in all I like the ability to open multiple panes, the ability to open network drives, see ongoing/completed processes and see the clipboard. I find I virtually never need more than two panes though, and there are plenty of CLI utilities for FTP and stuff. I'm probably going to stick with an old school dual pane like vifm or MC. I'll keep this on my machine and test it out some more next time I need to connect to an ftp server or something, I like that it provides most of the functionality that graphical file managers like Nautilus have, I do miss some of that stuff in my terminal oriented environment, but not enough to go full mouse, so it's good to know I have an option that gives me some of both.
When did you try it and do you have an idea why it could have happened? I'm simply curious about it, but this doesn't sound great. I found this issue [1] which should have been fixed in version 1.1.1 [2].
Love all the terminal tooling that's come out in recent years. I'm this close to chrome and rofi being the only gui I'm using on my work machine. This looks great!
A lot of the new tooling is in Go, superfile included. Noticed this after I started using LazyGit (incredible tool btw, I can't go back to anything else even after being a die hard Magit user for years)
There's some stellar libraries in Go for terminal stuff, in particular anything from charmcli. They have an elm style TUI framework called bubbletea (which superfile uses), a styling library, prebuilt components, it's really incredible. I'm building a multiplayer tetris you can play through ssh, which is using bubbletea and another lib of theirs called wish.
they have a lot of stuff you can just use in regular shell stuff too: https://charm.sh
I don't know about Charm so maybe someone can check their Github, but there's a dark pattern where you market yourself as open source but not all your components are actually released to the public, so you have a nice GitHub icon on your front page that just leads to silly minor extensions but not the main software. ObsidianMD does it.
Where does Obsidian claim they’re open source? Where have they ever done that? And no, having a GitHub icon does not magically announce to the world “we are open source”.
In fact, their license page makes it abundantly clear they are not open source:
> We own and reserve rights to our content, including text, images, and code in the app, which is protected by copyright and other laws.
I get this argument if a company or product claimed it was open source and it wasn’t, but it just doesn’t work if the product in question makes it quite clear they are not, or even leaves it ambiguous.
So if they at no point claim they’re open source… what, exactly, is your critique of them? That they built a product that is so good it could conceivably be open source but isn’t?
> And are you suggesting that people normally click the license page?
As my comment says, I am suggesting that they explicitly say they are not open source. It’s not like that’s featured front and center on literally any other product’s front page, so I’m not sure what exactly your expectations are here. Do you want them to have in 100pt font “WE ARE CLOSED SOURCE!!!” plastered across every page? Would that be enough?
I think GP was referring to the terminal emulator, which normally has the minimal GUI decorations depending on the terminal emulator and your desktop environment.
For me its rofi and a tiny bar on top of (ne of my hyprland windows for basic information (clock,calendar,widgets for network/volume/screenbrightness) its awesome
Because terminal programs have limitations that limit the amount of annoying things programs can do.
The color scheme matches the color scheme I set. They cannot change the font size nor the the font. They cannot spawn windows that will steal focus. They can run inside tmux which has advantages for my workflow.
Hotkeys are a first class citizen and not an afterthought when it comes to terminal uis.
That being said, I don't hate GUIs. I just hate a lot of them for doing things that annoy me.
It's also usually inherently composable, since you can pipe and redirect and everything speaks a common language (plaintext, for better and worse). If you just naively implement a cli tool, you usually end up with something that can reasonably be chained or redirect into/out of or combined with xargs etc.
It's like if every single GUI program included easy recording of macros and had built-in tools for munging of data to input fields and from text information.
There is a really solid place for GUI tools though and that's where the task is inherently visual (nontrivial tabular data, anything with images or video, etc) or where discovering your features and guiding people through a workflow is more important than it playing a part in a text processing pipeline.
Honestly, file managers are probably a good example of something that really ought to be a GUI and I've always considered it a bit zealous of people to want a TUI for it. Just look at this thread alone - people accidentally deleting files because navigation and actions are so undiscoverable that if you don't just blindly copy vim, even highly technical people will have no idea how to use your tool.
CLI's are composable, TUI's usually aren't. They are just a GUI in a terminal with extra restrictions. I do prefer CLI's for most things over a TUI.
> Just look at this thread alone - people accidentally deleting files because navigation and actions are so undiscoverable that if you don't just blindly copy vim, even highly technical people will have no idea how to use your tool.
But is that even a problem? If you are going to use a tool for years, does it matter that in the first few hours it's not super discoverable?
I do wish though that terms had multiple font sizes (with some limitations to make it "work"), to allow larger text but smaller gutters, etc. Aside from the general inefficient use of space, i adore terms.
I do wish and hope more apps become like Zellij, though. With possible keybinds on the bottom, etc. I tend to avoid TUIs because i can't be arsed to remember the keybinds and prefer to just use CLIs since those are in my history.
I think emacs have multiple font sizes/weights/families support (called font faces) and that's a reason people love it. The thing I like about term is that you're not confined to a single computer. You only need SSH to replicate your workflow anywhere (and a VPN, maybe).
TUIs work better when you're committed to the workflow. Discoverability is not often one of the key features (although most seem to have great help pages and manuals). You chose one, take the time to learn it, configure it the way you want and it's better (not prettier) than most mouse based workflows.
Emacs is one of the best GUI programs because they add functionality on top of the terminal version, like image support, different font sizes at once, and the window separators not being part of the text so highlighting text quickly is easier, but it keeps the first-class keyboard support it's always had.
I think the average GUI was designed for mouse-first and the lowest common denominator, so it'll generally never be as good. It's similar to how irssi and weechat are top-tier chat programs, but nothing in the XMPP or Matrix world really seems as good.
Check out helix for a good example of this too. Not quite as visible, but entering certain modes gives you a list of available shortcuts you can use from there.
Space for example opens a list with ten or twenty commands that remind you how to open the file picker, open editor list, problems window, etc…
Not just that, there's also that you can run them via SSH, there aren't a zillion top heavy GUI frameworks, interaction is significantly less cumbersome, and let's face it, they look so much better.
For me, hotkeys are the main selling point. I don't want to operate my machine with one wrist and one finger. I have a panel of switches in front of me, why should it be a typewriter 100% of the time? Moving to keyboard focused interaction, particularly vim keys but anything really, it makes me feel like in operating my machine with my mind, it is orders of magnitude less cumbersome once you're past the learning curve, such that when I have to use a traditional stacking, mouse focused environment I feel like I'm on a dial up connection with my hands amputated and cataracts.
Because TUIs never change. No one removes useful options from a TUI because "whitespace is clean". No one is writing useless changes to TUIs so they can feel like their job means something or to chase some bonus.
Because GUI design today is very bad and only getting worse.
It's a slippery slope, once you've spent a year tailoring your setup it removes so much friction from those tasks you do 100 times a day. Sometimes I look at my macos coworkers and they have a single application on fullscreen and then they shake their mouse or whatever and 20 windows fly over the screen and then they scan them all to find the other window they are looking for, and I really wonder how they get work done.
I use i3 and have 5 credit-card sized terminals open at any given time without taking up much screen real estate, and it's so great.
In both cases during the "learn the tool" phase you end up spending time having to figure out how to do things, understand workflows etc.
In the TUI case though, you can usually tweak that workflow and configure it to match your brand of thinking. It costs a little more per instance up front, but after that year (or whatever time period), you get a much less frustrating experience, and the oddball things your particular workflow requires have been smoothed out - where in the GUI you'd still be frustrated and a bit fumbly or suboptimal, so you continue to pay the penalty for it over time.
It's really about how you amortize the total time put into using the tool.
I love the terminal and use vim as my primary text editor but I can't remember the last time Mac OS full-screened an app for me unless I told it to. I drive most of my mac through keyboard shortcuts and minimal pointer interaction. Perhaps a mouse-first Mac users are forced into full-screen? That still doesn't sound right though.
It doesn't force applications to be fullscreen, but it does have garbage tooling for managing multiple windows on the screen simultaneously. Even windows has better with hotkeys and gestures for snapping to parts of the screen.
Mac OS originally didn’t have the concept of full screen (expect for games, pro software) or tiling. Its floating, overlapping and spatially oriented windows blew people's minds. It was coherent and wonderfully executed, both powerful and simple, I miss it dearly.
During the OS X brain transplant and particularly after Lion it became a hybrid that’s neither here or there, unfortunately.
Sadly by the looks of some of the replies here, never will recover from, since people seem unaware that it never used to do that, and would delightfully size itself to the content. This is the #1 feature that I really loved about Mac OS window management.
I suspect most Linux users don't "hate GUIs" but hate the garbage that GUIs enable, like pointless/stupid transition animations, hard to see flat UIs, dumbing down of preference/setting dialogs, etc.
Most GUI design is focused on dumbing things down for first time and beginner users, and most Linux users don't fall into that demographic.
If a GUI helps me get my work done faster then I'm all for it. If the GUI gets in my way and wastes my time then I'm not going to use it.
It’s the animations for me. I know it sounds crazy but I am a little bit angry every time I notice an action that is measurably slower than it needs to be because some “UX designer” (should not even be a job based on the BS I’ve seen) needed to justify his salary by blocking the UI process with a whiz-bang animation. Especially an action I have to do many times in a row, or all day long. I wish I could set the iOS global animation time to 0 like you could do back when you could jailbreak. (And no, reduce motion doesn’t help, it just replaces them with crossfades but still wastes the same amount of time)
Precisely. I’d rather go back to plain old UI, informed by the decades of experience we have with what is usable, and give these fad-chasing artists an island somewhere where they can screw around in Figma all day long without access to anyone who can build anything from their mocks.
the difference between fumbling around a GUI file manager looking for the correctly named file and using one of the many solutions the terminal offers is night and day. GUI's are clumsy and prone to extremely odd failures where the only solution is to exit and reset. Greyed out buttons when they shouldnt be etc... The terminal doesn't have these problems, if something fails you can see the error, its immediately responsive always, its composable and scriptable. Consider cutting up audio clips in audacity, doing it by hand can take ages and the GUI can crash and screw you over. With the terminal you can just take 2 minutes to write a burner script and use it and be done in seconds. Its really hard to describe the positives of the terminal over a GUI because they are radically different things, and new users are going to have a tough time setting up a friendly environment, but if you can get past that its extremely easy to see why they handle certain tasks a million times more efficient and resiliently.
So in a good Windows file manager here is how you can fumble around looking for the correctly named file:
press a single key
enter part of a name
get a fuzzy match for any file on your system in a separate tab (which you can return to later if needed)
sort by path/size/image width to filter further
press a key to preview file content or copy a file or delete it
All that with immediate visual feedback
What's your terminal day solution to this?
> if something fails you can see the error,
Or you can't, it just silently deleted the wrong files and you're non the wiser since you don't even see that your filter mismatched
> With the terminal you can just take 2 minutes to write a burner script and use it and be done in seconds.
How would you pick the audio times? In audacity you can easily play on cut thresholds to hear that they're correct, what's your "seconds" solution to that?
Like, you can pipe CLIs together, and some TUIs accept a command and exit, allowing you to chain things together.
On the web, your best bet might be playwright, but that’s about it.
Imagine having GTK and QT applications able to be chained and exit automatically.
On MacOS/iOS it’s not much better, even if Apple Shortcuts can feel ok sometimes, assuming the devs thought about allowing some actions to be available through shortcuts.
On Linux, I think dbus was supposed to become the universal bus onto which all GUIs could provide services and do things together. It hasn’t panned out IMO.
None of the tools on display here are composable either, in fact almost all modern TUIs are literally indistinguishable from GUIs, using the same widgets and user paradigms you'd find in a desktop app, but reimplemented on top a text rendering engine, they're not CLI tools.
It's basically the same thing we did on the web where webapps sort of pretend that they're not sitting on a text protocol but at least there it's out of necessity. On top of a functioning graphic stack there's no point for TUIs to exist.
My default assumption about GUI programs: they'll either work locally on my macOS developer machine and nowhere else, or they'll work nowhere I can use them.
My default assumption about TUI programs: they'll work everywhere I work.
That's too much generalization. I like skeuomorphic GUI with proper shadows, separators, color gradients, 2.5D borders, menus, etc. Nobody is offering those these days, so I gravitated towards TUI; I also have a lot of nostalgia for the DOS days, and although terminal emulation is worse than a proper command line, I make do.
I came on macOS on Mojave, but have seen Maverick and Lion screenshots and I've used iOS 6 as well. Flat UI can be prettier, but the physicality of skeuomorphic design is better for interaction. There was something more when interacting with Winamp instead of the current batch of audio players we have today. Win7 was great.
Typically, because we find them inferior to CLIs/TUIs. A few possible reasons:
* Graphical programs tend to use more memory/CPU for the same task.
* Graphical programs are more likely to prefer/require the mouse.
* Graphical programs seem to change their interface more frequently.
* Graphical toolkits all seem to suck, in ways that vary by toolkit and version, and this suckage tends to make us actually notice more than ex. new versions of ncurses changing things under the hood.
Don't get me wrong, there are plenty of GUI programs that are great - some of them even better than CLI/TUI alternatives - but the odds seem to be stacked against them.
What doix said, but also if I tailor my workflow in the terminal, I can toss the same applications and configs onto my servers and use them the same way without installing a window manager and VNC onto it.
As someone that used to agree with you, I’ve come to admit there are benefits.
Information density and shortcut availability are two of the big ones.
But the biggest for me is composability. I can query any data using their cli and open it in visidata nearly instantly. Just pipe it in. The interface is awesome compared to other query viewers I’ve found. It makes it easier to drill in and see results. Quick pivoting, Filtering and more
This program is available for multiple platforms, not just linux. Anyway, many people prefer keyboard navigation and already have a shell open for other tasks. Navigation by keyboard alone is not generally a feature in most GUI applications (see things like Vimium to add that capability to Chrome, for instance).
I don't hate GUIs, but TUIs have their benefit. Most prominently it doesn't require display, which most servers don't have, and would take a lot of resources and latency if tunneled remotely.
However with material design being the norm in gui there is nowadays barely any visual difference between a TUI and a GUI so it only come down to preferences: app optimized for keyboard or mouse use.
GUIs are nice for exploration because you can (in principle) intuitively iterate through the application behaviors, but command line interfaces are far superior when you already know what you're doing.
Digging through menus can be pretty frustrating. A way to search available commands and options would be ideal. Something like Emacs's M-x prompt suggesting commands as you type, and if you see nothing relevant you can try a different term. Even the basic actions the default keybinds do have equivalent commands you can run.
I've heard of a setup relying on Unity's old global menu feature that then lets you use something like rofi to search all the menus in a GUI program at once, but sadly never got it working. Sounds like a dream. You didn't have to actually use Unity, just make programs think you were, presumably so they'd expose the information the right way.
True, but most GUIs are built with the mouse in mind, and at best slap some ctrl keybinds on as an afterthought. Hamburger menus and flat whitespace are cumbersome.
It doesn't have nothing. It has keybinds. There's nothing to click on, but still plenty to do, and you can do it with more than one finger.
Flat... Whitespace. In modern graphical applications, nothing is broken up in your field of view, everything is an object on a slate. There's no organization, no context grouping objects together that help you understand how to interact with them, they're not ergonomic. Contrast that with this, while it's not a perfect example, there are clear borders, clear sets of interactions, the mind can formulate a procedure by looking at the organization of everything in front of them. It's almost like fonts, some fonts are better for readability, others are just ideas people had that might help that don't work out, and others are just there to look fashionable. UI maps and interactive flows can be easy to understand at a glance or look pretty but not give the user much of a clue what to do with what they're looking at.
Which are invisible. Unlike with the menus that show you keybinds right next to a command, and have Accelerators where you can use keyboard to navigate the list visually with the keyboard instead of having to remember all of the keybinds.
(unless you mean web apps, but then this app doesn't run on the web, so that comparison is moot)
(by the way, "most" clis don't support any keybinds, they're using command line flags)
> Contrast that with this
I have, taking a very common app for comparison - Windows File Explorer. It has borders (and nicer ones at that as they don't need waste the width of the whole char of space because they're not text), and also same groups (left pane)
> clear sets of interactions
Can you list a clear set of interactions with the Clipboard panel in the bottom-right (can you rename a file from there? drag&drop it away? delete a file / delete from the clipboard), and where this clarity is coming from
> Flat... Whitespace
Seriously, this file manager is a flatly designed app!, just go through the checklist:
Flat design is a modern design style that consistently maintains minimalist, 2D features. Here are six signs that what you’re looking at is flat design.
Contrasting colors: often bright colors, flat design relies on distinct contrast to send visual cues to users.
2D styling: simple shapes and no realistic images.
Simple typography: typically sans-serif fonts are the choice of flat design. It loads fast, it fits with minimalist style, and it’s easy to read.
White space: negative space helps designers indicate which part of the page they want users to focus on and makes the website more readable.
Grid-based layouts: usually flat design is symmetrical and uses a grid for the layout and hierarchy.
Simplicity: symbolic icons, abstract forms, no textures, and no gradients.
TUIs, in general, are more amenable to keyboard navigation than GUIs are; id est, even if GUIs offer keyboard navigation, they are simply not, on average, as good as those of TUIs. I'm not sure how that is controversial in the slightest.
It's not controversial, just wrong and different from what you were arguing for before about some innate TUI benefit ("mandatory"), which simply doesn't exist.
Now, "on average" does all the talking here, like, even putting the cli vs tui categorization aside (otherwise the "average" would support no nav, just some text flags), you can't really pick a small niche of TUI apps and compare it to the whole GUI, pick the same niche, and then you'd get categorically comparable keyboard support
No, on average, GUIs are simply better for most people than TUIs. Now if you cannot accept that elementary fact, there is nothing more to discuss with you, as we have wholly different world experiences. Having accepted that, TUIs are better than GUIs by some margin. Now, I can empirically show that there is a better benefit to TUIs than GUIS such that if you don't believe it, (wherever you seem to be in the Islamic world, I pity you) thank you, and have a good day. I am not even Muslim and even still I understand a-salamu alaykum.
I'm actually upvoting you. Not because I agree, but because this sentiment is so pervasive I need that responses highlighted instead of buried.
Linux users don't hate GUIs. I say this as someone who's used Linux as a daily driver for 15 years! GUIs have their place, but they aren't for everything. There's are two main issues here
1) The terminal is far more flexible and lightweight. I can do so much more in my terminal and get far more done in less time by using the terminal. Learning a little bash can greatly increase your productivity. And on top of that, I can do this with little cost to resources. I live in the terminal not because it is pretty but because it's faster and more efficient. Yes, there's a learning curve but it pays dividends.
2) customization. Don't confuse this for aesthetics. Those do matter but you should see yourself as an expert craftsman. Your carpenter, engineer, etc all build tools, jigs, and other things to help them, especially with organization. Like them you should create the best environment for you. I know you were told I'm programming classes that the magic is to not keep writing the same lines but to wrap those up. This is the same thing. The aesthetics are so I can see the things I care about the most, not because it's pretty. The aliases and scripts I built are to prevent me from wasting time relooking up things I do intermittently but not frequent enough to memorize. Customization is incredibly hard in GUIs. Dragging and dropping things and half the time the whole fucking screen scrolls because it's hard to not do this. And even then, it gets corrected cluttered and you end up with this long tree of menues. But wait you say, just give it a macro! And at that point, what's the difference? In the terminal we recognize something fundamental: to know it's name is to have power over it.
Yes, this isn't everyone. Every person is on a different part of their journey. And like I said, the customization is about making you productive not trying to find the most optimal, because that idea is laughable. There are good defaults but optimal is personal.
This is why I'll always trust someone more when they live in the terminal. The GUI person might be faster at times but they're limited. The person who will fuck around and find out is the person who will eventually understand more about the complex things they work on. They're more likely to dig deep. And this is the thing silicon valley has lost, the sense of creating what can be, not what is, not someone else's vision but yours.
A well-made TUIs is really ergonomic and clutter-free. It can be maintained to high standard by one person. It doesn't take a lot of efforts to make composable tools, ie pipes. It uses little resources even for fancy TUIs.
GUIs can be fine, but they are hard to get right, most are meh or just bad, and they are human resources sinks.
For anyone else (considering) switching file manager: Check if it depends on the gvfs package or not. You either want it (virtual filesystem support, stuff working "out of the box", background daemon, DE integrations) or you don't.
So there's one factor to cut the search-space in ~half :)
I'm recently trying out worker[0] and so far it's great.
This reminds me of a Windows 3.5 app called List (IIRC) that one day I lost the floppy to and as a 7 year old kid was completely lost without. So I installed bsd and broke my dads computer instead.
so I don't understand what the usecase for a terminal file manager is. I've always felt comfortable using cp/mv/mkdir/etc. but I feel like I'm missing out. Can someone explain how and why you'd use this ?
Three advantages I realized, having done a lot of cd/ls/cp/mv/rm and also having used a file manager:
- power user workflows may differ from typical dev workflows. Imagine things that a point-and-click file manager solves quicker than the command-line. Example: manually organizing a bunch of .mp3s, or cleaning out misc downloads. A TUI file manager makes these tasks quicker too.
- quick directory navigation. cd is slow. There's solutions for a better cd, involving z or fzf or whatever. But a file manager should solve it too.
- a file manager, especially a two-pane view, is cognitively easier. Better UX. Example: Having a src/ pane on one side and dst/ on the other, selecting a few src/ files, then performing a copy command. You get instant visual feedback to confirm that the files appeared in dst/. Compared to ls, cp file1 file2 file3 dst/, ls dst/. I always feel the need to ls after commands because the command-line doesn't give much feedback.
tldr: speed, ux, comfort. But if you're already comfortable with your tools, I think that's the most important thing.
Hardly speed or UX. Type a quick command on the CLI yo do any of that stuff and it's finished before you can even use you arrow keys to move between various regions of the screen and move your eyes around the work area to confirm everything and select your actions and move your gaze again to confirm the result is what you expect.
It's all about what you're used to and what you know. If you grew up in the age of the point-and-click GUI you might feel more comfortable using visual metaphors and stateful UIs for your intended actions. Others prefer to issue orders and have them obeyed without the song, dance, and lightshow.
I agree that looking around multiple panes is slow and arrow keys are slow, and that typical UI ceremony is unnecessary. But there's a benefit to seeing state changes and holding less state in your head. Kinda like `ed` versus `vim`. Someone comfortable with both editors would acknowledge vim makes some edits easier.
Of course, issuing orders still has its advantages. And yes, growing up with GUIs makes a big difference.
Thanks. That makes sense. I guess I'm just super entrenched - very comfortable with my tooling and would generally write a one-liner for something like the above.
The way I do it is a bit nuts though, and you're right, the above is much more consistent and has its advantages
With long filenames with characters like spaces, it can be easier to see them in a list, pick the ones you want, and operate on them in a GUI or TUI (same principle applies to Emacs Dired) than in a CLI. I can use the CLI and stumble around running ls multiple times and using tab completion, but the GUI or TUI can just be easier.
This did send me down a rabbit hole, and I ended up installing nnn (n³), only then to land on their GitHub page and staring at the keyboard layout and testing stuff out in the terminal. It is interesting and I wonder how it's getting used.
This looks pretty nice! I like the ability to add multiple file panels versus tabs that are common with nnn and ranger. Going to give this a spin today.
$ spf
spf: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by spf)
spf: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by spf)
Your version of glibc is too old. Mint 19 is based off Ubuntu 18.04, which ships glibc 2.27, whereas this binary seems to require symbol versions first shipped in glibc 2.34.
You'll have to compile from source, or update your distro to a maintained version. Ubuntu 22.04 ships glibc 2.35, and so Mint 21 should work.
Mostly commenting because while this isn't really a tech support channel, being able to identify glibc version mismatch errors comes up extremely often, even in this day and age.
This is a linking issue (you're missing a specific version of a dynamically linked standard library), and probably best in the issues on the repo, not Hacker News.
Is it though? I can run Windows programs from 20 years ago on my Windows machine just fine.
Issues with Linux binary distribution meanwhile are ubiquitous, with glibc probably being the single biggest offender. What's worse is that you can't even really statically link it without herculean effort. I've spent an inordinate amount of my life trying to wrangle third-party binaries on Linux libraries and it's just a sorry state of affairs.
Try taking a binary package from a vendor from even just 5 years ago and there's a non-zero chance it won't run on your modern distro.
You are talking about backward compatibility, the parent thread is about forward compatibility. You won't have much luck running a modern executable on XP unless the vendor went out of their way to make that happen.
> What's worse is that you can't even really statically link it without herculean effort.
The program we are discussing happens to be written in Go so it's trivial to build a statically linked executable.
With Go on Linux libc is only needed when the libc DNS resolver is used (instead of Go's built-in one) or if C libraries are used. superfile doesn't need either of these so it's very simple to build it as a pure Go executable which will be statically linked and contain no C code at all.
It's an interesting comparison. I agree that five years is well within the expected period of viability of an operating system. Some points to consider:
- any given release of a Linux distro will probably work on hardware released five years earlier -- one factor that reduces the cost of upgrading the OS (there are many more obvious factors)
- Microsoft is highly motivated to get customers to upgrade to the new Windows at the time. The legacy support is well-known as a "bone" (or: "a factor that reduces the cost of upgrading the OS")
- binary backwards/forwards compatibility is less of an issue in an environment that doesn't treat source code as a secret
- why run old versions of software? In other words: xterm is older than Windows and also as new as Windows
Also, I've always found it amusing that I have much less trouble running old windows software on a Linux (wine) than on new versions of windows.
I very well might be in the minority of Linux users, but I don't particularly care about the answers to most of these questions. I just want it to work. Give me solid defaults[0]. I'm not saying you shouldn't be able to override those defaults. That's an important feature of Linux.
My first experience running a cool-looking TUI file manager yesterday (I actually ended up trying yazi first) was that I got a lot of blank squares in place of missing icons and emojis due to missing fonts. I had to spend 20 minutes figuring that out before I got a good experience.
Interestingly, I also tried wezterm[1] in the process. It actually ships with the required fonts as fallback, but the version from my distro's package manager didn't work (the AppImage did). I'm guessing my distro removed them, maybe for some of the reasons you cited. I started installing the nerd-fonts group for my distro. 6.5GB... no thanks. After manually poking through them and some googling I finally installed a couple and it's working now.
My overall point is that it's possible for app developers to provide good defaults like wezterm does. It's also possible for distro's to break those defaults. Also, if size is a concern then at least detect that I don't have a working font and offer to download one for me.
Regardless of wanting sane defaults, this is not something superfile can do on itself: it runs in a terminal, and normally terminal programs do not get to choose what font is used.
So the "best" it could do is bundle the font file, but then you would still have to configure your terminal to use it. At that point, it's easier to just tell you you need a nerd font and link to their repo.
That being said, I kind of agree that, since NerdFonts are pretty good and by now quite widespread, it wouldn't be a bad idea for major distros to patch their default monospace fonts so that you get NerdFonts out of the box in the default terminal.
But, in general, if you go out of your way to install a different terminal emulator, it's unlikely you'd have much trouble changing its font anyway; still, getting everything to look nice and pretty is sometimes harder, so I suppose wezterm is commendable for including fonts and colorschemes.
(The above really mostly applies to fonts as they are an additional dependency and also highly dependent on user preference. For pretty much everything else I agree that good defaults are under-emphasized in CLI/TUI utilities. Probably because options usually get added incrementally and breaking historical defaults is not a good idea.)
Besides, you still have to set your terminal to use that font. Not as if typing `spf` on the command line can reconfigure whichever terminal you are on.
I find most ergonomic to write file manager as a vim plugin, I can just open things directly as buffers, only need to hit one key to toggle between file editor and file manager.
Nerd Fonts contain glyphs that allow things like the git strip you see at the bottom of code editors ("powerline"), along with ligatures (e.g. if you type <= it merges so it looks more like the math symbol of a less than sign and a single line at the same angle just below the < sign...)
And here's an example of ligatures (see the image on the right - you type what's on the left, and the right image is what shows in your editor):
https://hilton.org.uk/blog/fira-code
I think but am not sure as I haven't looked in a while, that the folder and file icons are part of the nerdfonts as well, that regular fonts would just show as the generic "missing glyph" symbol.
There's no technical reason the font couldn't be shipped in/with the binary. The main reasons this doesn't happen are probably:
- this is what a package manager is for
- installing the font/s (from the application?) would be a bit of a dick move and also presents a technical challenge (in other words: that's what a package manager is for)
- concerns about the efficiency of many applications all shipping duplicate assets (package manager again)
- concerns about distribution rights
- not all users will want to use the same font and this is an unsolvable problem -- do you ship: no fonts | one unwanted font | the user's preferred font that they already have installed plus all the other user's fonts
My first experience running a cool-looking TUI file manager yesterday (I actually ended up trying yazi first) was that I got a lot of blank squares in place of missing icons and emojis due to missing fonts. I had to spend 20 minutes figuring that out before I got a good experience.
Interestingly, I also tried wezterm[1] in the process. It actually ships with the required fonts as fallback, but the version from my distro's package manager didn't work (the AppImage did). I'm guessing my distro removed them, maybe for some of the reasons you cited. I started installing the nerd-fonts group for my distro. 6.5GB... no thanks. After manually poking through them and some googling I finally installed a couple and it's working now.
My overall point is that it's possible for app developers to provide good defaults like wezterm does. It's also possible for distro's to break those defaults.
> not all users will want to use the same font and this is an unsolvable problem -- do you ship: no fonts | one unwanted font | the user's preferred font that they already have installed plus all the other user's fonts
For me, I would absolutely prefer one unwanted font instead of losing those 20 minutes. If I don't like the font it ships with I should be able to override it. If size is a concern then don't ship the font, but detect that I don't have a working one and offer to download a default for me.
On Linux you can just chuck fonts in .local/share/fonts in your home directory. You can keep them in folders in there so just unzip the whole nerdfont archive there.
very first impression after <30 sec: having to press ^F or any key to enable filename/folder search in a folder creates friction vs. MC's approach where typing automatically starts search of current folder so you can hit a couple of keys, press enter, etc. Would be nice if that were a mode here too.
This type-to-search-immediately functionality is why I still have Launchbar installed on all my Macs -- there's nothing faster for navigation/moving/operations, even in the terminal.
The same project has an application called Gum which exposes primitives from their UI framework via a single CLI binary. It's intended to be used from a normal bash script and I've found it really quite pleasant to use.
For example, you could write 'gum choose foo bar baz' to get a nice picker over the three provided options.
If didn't read the docs, noticed hkjl moved around, and accidentally deleted 3 folders with ctrl+d seeing if I could scroll down faster. Scary defaults if you have Vim muscle memory.
It really weirds me out how many people use a sprinkling of vim keybindings but don't use more. Like how many vim users don't know <C-[> (esc) or contextual completion like <C-x><C-p> (:help ins-completion). I see so many people use plugins for things that already exist in vim but people never discuss.
One that bites me a lot is when a vim keybinding is implemented, has insert mode, and they don't also rebind <C-w>. Go from trying to delete a word (backwards) but end up losing a whole session. It's such muscle memory I sometimes do it on webpages, but maybe that one is a feature instead of a bug lol
This is my biggest complaint with keybindings on Linux/Windows, that Ctrl means “escape codes” in terminal emulator applications and “window/UI operations” in every other application.
By contrast, in macOS all the window/UI keybindings are typically Cmd (Cmd-W) which means that GUI applications attempting to layer on vi keybindings don’t have to also audit all the Ctrl keybindings that might be doing something wildly different compared to what vi users expect.
Cmd for UI and Ctrl for terminal just makes for such a nice default convention.
I agree— having switched back to Windows five years ago, this is one of the biggest things I miss about the Mac hardware. Having a separate key just avoids the whole drama around whether Ctrl-C is "copy the thing" or "shut it all down", and which of those functions is going to get remapped to Ctrl-Shift-C and all the fallout from that.
Configurable windows managers on Linux let you code a “super” key. I like the Window key, since it serves no other purpose, and never overlaps with default bindings on Linux.
So the Cmd/Ctrl split on Mac maps nicely to the Win/Ctrl split on Linux.
While I do this too I understand the above complaint. I think naturally linux should have more of a system similar to what OSX does. I mean I'm constantly switching between OSX and Linux machines but more and more recently I've been at at mac computer while inside a linux system and that is very seemless because it is the GUI that fucks shit up. But now there's so much momentum that I'm not sure they can go back. I think the only way to make this correction is for a big distro like Ubuntu/Pop/Manjaro/Endeavor to switch to a default with alt or super as they windowed operating key but have the option to switch back (should be implemented in the install process and made clear and easy to undo. But without making it the default it'll always stay the other way. (first introduction should be non-default)).
Super is the "Windows" key (or the Command key), it's the "mod key" that can then be set to super or alt/meta or whatever.
For the reasons you suggest (WMs often heavily using the super key), I would not want it to be used in the macOS way as I have a few dozen keybinds I'd lose or have to remap then. Stuff like focusing or moving windows or workspaces. Emacs can also make use of the super key, though I don't know if it has anything bound using it by default.
The macOS approach is cool and makes some sense, but I wouldn't want it forced on me, and I'm kinda glad I didn't imprint on it.
This isn't true though. Control + arrow keys for example navigate desktops on MacOS.
On Linux I can at least restrict my desktop environment's shortcuts to super, leaving the other mods open for applications. MacOS uses every single modifier, sometimes together.
When you use EXWM (Emacs X Window Manager), this is actually a blessing! It means you can bind Super keys only in Emacs and have them do exactly the same thing every time, while the other X apps (terminals, browsers...) get the Control key to themselves.
>and they don't also rebind <C-w>. Go from trying to delete a word (backwards) but end up losing a whole session
This is literally why Vim binding for Jupyter doesn't work for me and also why the "terminal" in Jupyter Lab is worse than not existing -- I can't help but press C-w
I don't think old means better. I agree that you should use whatever is best for you and makes you more productive (why I doing care about vim vs emacs debates) but I think you're giving up a lot. You're given and unless color blind then you are missing the added dimensions you searching with things like syntax highlighting. All your commands exist in vim, but come on, you've had the last 33 years to update. My configs update as I change too, so I hope that you aren't stuck because I don't like vi for the same reason I don't like GUIs: not all holes are round and not all pegs are square.
In ranger, dd is cut/mv and dD is delete, but dD on one file spawns a command with :delete typed in so you have to hit enter to pull the trigger, and doing it with multiple files has the same behavior plus adds a y/N prompt asking if you're sure you want to delete those specific files. This is enough friction to prevent most mishaps, but not enough to be annoying. I would suggest taking inspiration from this.
I used vim for 5 years and never knew about C-d for scrolling until after I had switched to Emacs and one day, on a whim, decided to install and activate evil and look what various commands were bound to. I removed evil immediately afterwards as 5 years of vim taught me to hate modal editing with a passion.
Yes those defaults won’t really work for vim. Escape exits the program, without even using it, I already know I am going to exit a zillion times once my brain thinks I am in Vim.
But the good thing is they are just defaults. Hopefully there are already no legions of users resistant to any changes to defaults.
what's even the point of downloading something so banal & not read the docs; comment at the post WITH the warning of it not complaining with Vim shortcuts when it's clear that Emacs is ballparks better?
/s
No, fix the issue and open a PR. This is a personal project. They need contributions, not a pile of discouraging issue reports for which they'll never have enough time.
I don't have to be a doctor to know something is wrong in my body, but I would have to be a doctor to fix it. Put another way: just because you figured out something is wrong does not mean you have the ability to fix it.
As a maintainer that just makes it worse. Familiarity with the code base is typically necessary to make a good quality contribution. Issues are a sign of love, imo, because they don’t want to stop using your project, they want it to improve.
Of course there are also entitled and rude people. But we should not set the standards based on a-holes.
> not a pile of discouraging issue reports
This is such a strange way to look at software development. Discouraging?
To be honest, if I'm developing a small project I'm excited about and I'm getting an issue report from someone I'd be happy to see that someone actually cared enough to spend time on writing something (Either in the comments here, or as a quick issue on GitHub).
I would not expect someone to get familiar with my young code base and fix the issue themselves.
I think it's fair to ask of any new program why to use it rather than an existing option. And there can be lots of reasons - more active development, new features, less buggy, smaller program (uses less disk/memory, easier to be less buggy), easier to install, easier to use, whatever. And the author of a program doesn't necessarily need to have an answer, especially not early on; programming is sometimes its own reward, and sometimes advantages only become obvious later. But as a user, yeah it's useful to know what advantage this thing has over all the other things that do the ~same stuff.
I won't say that mc is really buggy, nor that it's large. But even if it were, it's weird to not even mention it, let alone compare with it, while likely most of the target audience has been using mc for years (or decades, like me).
Based on the comments here about weird inconsistent keybinds and accidental file deletions, I won't be trying this for now, but I will keep an eye on it. I use ranger very heavily every day, but it being slow pythonware is sometimes a problem with extra large dirs and when changing the sort mode often. lf is too barebones for me, I don't know how to recreate everything I'm used to from ranger. Something fully-featured but faster than ranger would be ideal.
If you're taking suggestions, making file copies use rsync under the hood would be great. I used to copy files over sshfs with ranger a lot and then found out the hard way that it was occasionally failing/being interrupted and then silently moving on in the transfer queue, so I had partial and corrupted video files it took months to notice. I do also use rsync for transfers a lot of the time, but sometimes you wanna move a bunch of files to different directories, and something like ranger is just faster and easier. Especially when you don't want everything from the source on the destination for space reasons, so can't just rsync whole dirs to grab the new stuff.
