5 ms·

Every time I see interesting file managers it makes me want to try and like them but I always end up abandoning them after either a few minutes or a few hours.

by p4bl0 8y ago

Every time I see interesting file managers it makes me want to try and like them but I always end up abandoning them after either a few minutes or a few hours. I don't know why. I'm quite sure I could be more productive using a file manager, even a graphical one. But it's been more than ten years that the only file manager I actually use is Bash and the GNU coreutils.

dancek 8y ago
Moving or copying files a single time might be a bit faster using a GUI (or TUI). But when you factor in starting the file manager and navigating to the right place, it's not a big difference. And when you need to do a more complicated operation you're looking at a shell oneliner vs. multiple (possibly repetitive) manual steps in the UI. If simple copying of files made up a great deal of my daily work, I'd certainly use a file manager (if I couldn't write a script to do it).
- setr 8y ago
  The primary benefit of any GUI over a functionally equivalent CLI is the improved discoverability, especially for rare, one-off tasks. CLIs over GuI primarily offers better repetition. Any comparison between the two systems should stem from there: you’ve only offered half of it. Eg getting a remote virtual disk set up in OSX’s finder is much easier than on terminal, without googling/general research, for a one-off drive. Getting 50 such disks up and going is far easier on terminal. (CLI has a better O(), but worse constant factor.)
  - marmaduke 8y ago
    I disagree partly here: hitting tab twice in a shell usually lists available commands, possibly with some prefix. A GUI has the advantage of context, in that eg menu items of the disk utility make sense as you know they’ll be some operation on disks. On CLI eg I don’t remember the mkfs command for a file system, I type mkfs and hit tab twice. It could be better though, of course.
    - pjmlp 8y ago
      That is the problem right there, you need to know mkfs exists to start with.
      - kurtisc 8y ago
        apropos file system You'll be searching (or using previous knowledge) for what you need to format it as, anyway.
      - marmaduke 8y ago
        Well one needs to know the Disk Utility exists as well, or disk management thingy in Windows.
        pjmlp 8y ago
        Sure, but that is available on a simple right mouse click on the device. In any case you are focusing too much on mkfs, I can think of plenty of other examples, many of each aren't even portable across UNIX environments. While GUIs at least can offer navigation and visual cues as means to discover features.
    - vram22 8y ago
      A major issue with GUIs is that they are not scriptable [1], at least in the way CLIs are, like with a bash-like shell and all the stuff of the Unix philosophy [2] (I/O redirection, pipelines, wildcards, other Unix special characters that expand to, or mean, something (all of which you can use in your command pipelines). [1] I mean, I know there are some tools to automate GUI tasks, like AutoHotkey, AutoIt, etc., but due to various window-related issues, they are fragile, I've heard. Not saying that this makes CLIs superior for all uses, of course. Just better for some. [2]: http://www.catb.org/esr/writings/taoup/html/ch01s06.html http://www.catb.org/esr/writings/taoup/html/ch01s06.html http://www.catb.org/esr/writings/taoup/html/ch01s08.html http://www.catb.org/esr/writings/taoup/html/ch01s08.html
    - setr 8y ago
      One issue is that cli apps expect a man page to be available, and that you’ll be willing to read it, so options by name alone tend to be more obtuse. Better if you already know it, worse when you dont. Eg ffmpeg is confusing no matter what, but the cli is particularly obtuse in how options interrelate (or even the format string required for them!). A gui for ffmpeg will naturally have fewer options (less expressive), related features to an option will be grouped by windows, and might even do things like visibly disable options based on current flags set, or even a preview mode. You could probably get by to a certain degree, when new to the program, on an ffmpeg gui for simple operations; even the most basic action of cli will be difficult just reading the options appearing by 2xtab. There’s simply a lot more a gui can do to help the learning/interactive process than a cli can (tui is a different story: its just a gui that happens to be in your terminal, and offers the same positives/negatives that any other gui does).
  - dancek 8y ago
    I somewhat disagree. Yes, if the GUI has five possible actions and you're only familiar with one of them, it's much easier to learn to do the other four things with the GUI. But it's tedious to do something the GUI wasn't designed for. Once the GUI reaches hundreds of actions it's no longer easy to find the functionality you're looking for.
- Normal_gaussian 8y ago
  Very occasionally I use ranger to explore directories whose contents I've forgotten; but it is so infrequent that I'm often halfway through exploring with the shell before I remember it is better and faster with ranger
- gmueckl 8y ago
  I am surprised how fast I have become when using Double Commander. I really needed to learn the keyboard shortcuts, but that payed off. It is really made for keyboard control, not mouse based interaction. Seemingly minor details like searching by typing selection being a toggle (space bar) help me a lot.
- deleted 8y ago
  [deleted]
apjana 8y ago
Author of `nnn` here. It would really help if you let us know what you are looking for in a file manager. `nnn` is under active development for more than a year now and we are very open to constructive feedback and feature requests.
- p4bl0 8y ago
  I actually don't know what I'm looking for. I'm quite happy without one. It just feels strange as file managers seems to be most people main entry point to their computer.
- jasim 8y ago
  two of my most used shell commands are "j" (https://github.com/wting/autojump https://github.com/wting/autojump) and "fd" (https://github.com/sharkdp/fd https://github.com/sharkdp/fd) Autojump makes it easy to quickly jump into any directory I've visited and then I can open my editor or Finder (file explorer) from there. Would be great if I can be inside nnn and jump to directories using autojump. fd is very useful when I want to just directly open a file. I might be in a project's root directory and I'd want to edit a file a few levels nested. Currently I either use fd to locate the path of the file, and then copy paste it into the shell. If `fd` is combined with nnn, I can type in a few letters of the file I expect, and jump to its parent directory, with the file highlighted. Is this workflow possible in nnn, or can it be written using its scripting?
  - apjana 8y ago
    autojump: `nnn` comes with bookmarks for frequently visited dirs. You can look up the list anytime. fd: `nnn` integrates seamlessly with fzy (another blazing fast C utility).
z92 8y ago
I always feel the need to have an ncurses based sql database explorer. With list/search/add/edit/delete utilities. Always miss it. But never had the time to write it myself.
- ionflux 8y ago
  maybe try visidata (http://visidata.org http://visidata.org), it handles sqlite and postgres among others. But personally I've only used it for csv/tsv/excel files, it handles them beautifully, with vim-style bindings.
kristopolous 8y ago
Look into ranger. I occasionally use it to quickly look at file contents. It's a nice thing to use for 10 seconds a few times a week
- dgzl 8y ago
  I can recommend ranger, however I am not consistent with it.
WeAreGoingIn 8y ago
I agree, after 20 years end up with Bash and binutils. Some time I did a survey for a neat a nice terminal fm. Trying a lot of different kinds I ended up with vifm. Copying multiple files regularly I recommend using Python Fabric.
unwind 8y ago
If you're open for a graphical option, try "gentoo" (not the distro, the GTK+ file manager). Disclaimer: I wrote it.
BeetleB 8y ago
Use midnight commander. It has the command line embedded in it, so you can still use all your shell wizardry. You get the best of both worlds.
- apjana 8y ago
  You can fallback to the subshell in `nnn` with `!` or `^]`.
  - BeetleB 8y ago
    Will the subshell have all your shell aliases?
    - apjana 8y ago
      Yes.
  - v_lisivka 8y ago
    In case of mc, ^O switches to same background shell, even from editor. So, variables, functions, and command history is same. Moreover, I can run command in shell and return to mc or mcedit to continue work when shell command still works (with limitation that current working dir will not follow selection in mc). It feels like real shell, not a subshell.
    - apjana 8y ago
      In `nnn` selection works seamlessly between multiple instances. The shell in `nnn` is also a real shell with your complete env settings. So it remembers everything. I can't think of a workflow where you are working both in the shell and the file manager when you have selection in place. It's a convenience, yes. But both are exclusive in nature.

by p4bl0 8y ago

dancek 8y ago

Moving or copying files a single time might be a bit faster using a GUI (or TUI). But when you factor in starting the file manager and navigating to the right place, it's not a big difference. And when you need to do a more complicated operation you're looking at a shell oneliner vs. multiple (possibly repetitive) manual steps in the UI. If simple copying of files made up a great deal of my daily work, I'd certainly use a file manager (if I couldn't write a script to do it).

setr 8y ago
The primary benefit of any GUI over a functionally equivalent CLI is the improved discoverability, especially for rare, one-off tasks. CLIs over GuI primarily offers better repetition. Any comparison between the two systems should stem from there: you’ve only offered half of it. Eg getting a remote virtual disk set up in OSX’s finder is much easier than on terminal, without googling/general research, for a one-off drive. Getting 50 such disks up and going is far easier on terminal. (CLI has a better O(), but worse constant factor.)
- marmaduke 8y ago
  I disagree partly here: hitting tab twice in a shell usually lists available commands, possibly with some prefix. A GUI has the advantage of context, in that eg menu items of the disk utility make sense as you know they’ll be some operation on disks. On CLI eg I don’t remember the mkfs command for a file system, I type mkfs and hit tab twice. It could be better though, of course.
  - pjmlp 8y ago
    That is the problem right there, you need to know mkfs exists to start with.
    - kurtisc 8y ago
      apropos file system You'll be searching (or using previous knowledge) for what you need to format it as, anyway.
    - marmaduke 8y ago
      Well one needs to know the Disk Utility exists as well, or disk management thingy in Windows.
      - pjmlp 8y ago
        Sure, but that is available on a simple right mouse click on the device. In any case you are focusing too much on mkfs, I can think of plenty of other examples, many of each aren't even portable across UNIX environments. While GUIs at least can offer navigation and visual cues as means to discover features.
  - vram22 8y ago
    A major issue with GUIs is that they are not scriptable [1], at least in the way CLIs are, like with a bash-like shell and all the stuff of the Unix philosophy [2] (I/O redirection, pipelines, wildcards, other Unix special characters that expand to, or mean, something (all of which you can use in your command pipelines). [1] I mean, I know there are some tools to automate GUI tasks, like AutoHotkey, AutoIt, etc., but due to various window-related issues, they are fragile, I've heard. Not saying that this makes CLIs superior for all uses, of course. Just better for some. [2]: http://www.catb.org/esr/writings/taoup/html/ch01s06.html http://www.catb.org/esr/writings/taoup/html/ch01s06.html http://www.catb.org/esr/writings/taoup/html/ch01s08.html http://www.catb.org/esr/writings/taoup/html/ch01s08.html
  - setr 8y ago
    One issue is that cli apps expect a man page to be available, and that you’ll be willing to read it, so options by name alone tend to be more obtuse. Better if you already know it, worse when you dont. Eg ffmpeg is confusing no matter what, but the cli is particularly obtuse in how options interrelate (or even the format string required for them!). A gui for ffmpeg will naturally have fewer options (less expressive), related features to an option will be grouped by windows, and might even do things like visibly disable options based on current flags set, or even a preview mode. You could probably get by to a certain degree, when new to the program, on an ffmpeg gui for simple operations; even the most basic action of cli will be difficult just reading the options appearing by 2xtab. There’s simply a lot more a gui can do to help the learning/interactive process than a cli can (tui is a different story: its just a gui that happens to be in your terminal, and offers the same positives/negatives that any other gui does).
- dancek 8y ago
  I somewhat disagree. Yes, if the GUI has five possible actions and you're only familiar with one of them, it's much easier to learn to do the other four things with the GUI. But it's tedious to do something the GUI wasn't designed for. Once the GUI reaches hundreds of actions it's no longer easy to find the functionality you're looking for.
Normal_gaussian 8y ago
Very occasionally I use ranger to explore directories whose contents I've forgotten; but it is so infrequent that I'm often halfway through exploring with the shell before I remember it is better and faster with ranger
gmueckl 8y ago
I am surprised how fast I have become when using Double Commander. I really needed to learn the keyboard shortcuts, but that payed off. It is really made for keyboard control, not mouse based interaction. Seemingly minor details like searching by typing selection being a toggle (space bar) help me a lot.
deleted 8y ago
[deleted]

apjana 8y ago

Author of `nnn` here. It would really help if you let us know what you are looking for in a file manager. `nnn` is under active development for more than a year now and we are very open to constructive feedback and feature requests.

p4bl0 8y ago
I actually don't know what I'm looking for. I'm quite happy without one. It just feels strange as file managers seems to be most people main entry point to their computer.
jasim 8y ago
two of my most used shell commands are "j" (https://github.com/wting/autojump https://github.com/wting/autojump) and "fd" (https://github.com/sharkdp/fd https://github.com/sharkdp/fd) Autojump makes it easy to quickly jump into any directory I've visited and then I can open my editor or Finder (file explorer) from there. Would be great if I can be inside nnn and jump to directories using autojump. fd is very useful when I want to just directly open a file. I might be in a project's root directory and I'd want to edit a file a few levels nested. Currently I either use fd to locate the path of the file, and then copy paste it into the shell. If `fd` is combined with nnn, I can type in a few letters of the file I expect, and jump to its parent directory, with the file highlighted. Is this workflow possible in nnn, or can it be written using its scripting?
- apjana 8y ago
  autojump: `nnn` comes with bookmarks for frequently visited dirs. You can look up the list anytime. fd: `nnn` integrates seamlessly with fzy (another blazing fast C utility).

z92 8y ago

I always feel the need to have an ncurses based sql database explorer. With list/search/add/edit/delete utilities. Always miss it. But never had the time to write it myself.

ionflux 8y ago
maybe try visidata (http://visidata.org http://visidata.org), it handles sqlite and postgres among others. But personally I've only used it for csv/tsv/excel files, it handles them beautifully, with vim-style bindings.

kristopolous 8y ago

Look into ranger. I occasionally use it to quickly look at file contents. It's a nice thing to use for 10 seconds a few times a week

dgzl 8y ago
I can recommend ranger, however I am not consistent with it.

WeAreGoingIn 8y ago

I agree, after 20 years end up with Bash and binutils. Some time I did a survey for a neat a nice terminal fm. Trying a lot of different kinds I ended up with vifm. Copying multiple files regularly I recommend using Python Fabric.

unwind 8y ago

If you're open for a graphical option, try "gentoo" (not the distro, the GTK+ file manager). Disclaimer: I wrote it.

BeetleB 8y ago

Use midnight commander. It has the command line embedded in it, so you can still use all your shell wizardry. You get the best of both worlds.

apjana 8y ago
You can fallback to the subshell in `nnn` with `!` or `^]`.
- BeetleB 8y ago
  Will the subshell have all your shell aliases?
  - apjana 8y ago
    Yes.
- v_lisivka 8y ago
  In case of mc, ^O switches to same background shell, even from editor. So, variables, functions, and command history is same. Moreover, I can run command in shell and return to mc or mcedit to continue work when shell command still works (with limitation that current working dir will not follow selection in mc). It feels like real shell, not a subshell.
  - apjana 8y ago
    In `nnn` selection works seamlessly between multiple instances. The shell in `nnn` is also a real shell with your complete env settings. So it remembers everything. I can't think of a workflow where you are working both in the shell and the file manager when you have selection in place. It's a convenience, yes. But both are exclusive in nature.