3 ms·

> This is something we cannot easily do on the shell with the standard Unix utilities. Huh? All your examples are easily done in a shell. GNU find and fd suppo

by imiric 1y ago

> This is something we cannot easily do on the shell with the standard Unix utilities. Huh? All your examples are easily done in a shell. GNU find and fd support regex, xargs can be used for bulk operations, etc. This is more flexible and scriptable than anything dired allows you to do. It might not be immediately easier, but once you grasp how a few basic shell utilities work and how to combine them, using shell history, functions, aliases, and key bindings becomes part of your muscle memory. This workflow is even more transferable across systems and environments. I think dired is convenient if you're already using Emacs and want to do a quick operation, but the shell is far more generally useful in the long run.

roryirvine 1y ago
On top of that, BSD had a standalone 'dired' in the late 80s and Linux moreutils (not quite a standard, but certainly widespread) contains 'vidir' - which, despite the slightly misleading name, allows you to visually edit a directory with whatever your EDITOR env var points to. As you say, none of them do anything that can't be done with find and xargs (and perhaps a little awk and sed), but they're occasionally handy for one-off operations.
susam 1y ago
> GNU find and fd support regex, xargs can be used for bulk operations, etc. I don't see how this is comparable to arbitrarily browsing through a directory, inspecting files, and manually marking the ones you want to act on. The feature I was describing is more akin to how we browse directories in a graphical desktop environment. I use find, xargs, and similar tools as well, but they don't allow you to casually mark or unmark files and run operations on them later. With these tools, you need a fairly precise idea of what you're targeting. Then you have to write a glob or regex pattern up front, and then execute the command. That's a very different workflow from interactively exploring a directory, making ad-hoc decisions, and selectively marking files as you go.
- imiric 1y ago
  > I use find, xargs, and similar tools as well, but they don't allow you to casually mark or unmark files and run operations on them later. You might be missing fzf from your toolbelt. Running `fzf --multi` does just that, and allows you to pipe the selection further to anything else you want to do. This is why the shell is a more flexible environment. You don't need to adopt a large monolithic tool or drastically change your workflow to do something which you previously couldn't. You just need to insert another tool that does a single thing well into your existing pipelines, and your workflow can be improved with much less effort.
  - susam 1y ago
    I use fzf as well, but I don't think it's quite comparable to the kind of ad hoc browsing we can do in a GUI desktop environment or in Emacs. Yes, 'fzf --multi' lets us select multiple files, but it's not really the same as casually browsing through a directory. For example, we might find an image file and preview it, or open a PDF just to skim it, and then mark that file and move on, and continue browsing files in this manner until we've gathered everything we need. That sort of exploratory, flexible interaction feels quite different. Shell tools, Unix utilities, and 'fzf --multi' are definitely very powerful. But at least to me, they don't seem to offer the same kind of spontaneous browsing and editing experience, I'm referring to. To be clear, this isn't some sort of competition! I'm not claiming one approach is superior to the other. Every tool has its strengths. My comments highlighting the features of Emacs do not imply that other tools are inferior. Quite the contrary! I'm very fond of computing and I enjoy having a broad set of excellent tools at my disposal. The only point I disagree with is the claim that "all your examples are easily done in a shell". In my experience, the kind of random, ad hoc browsing, previewing, editing, marking and unmarking files, I'm talking about isn't quite as straightforward in the shell. It's certainly possible, but it doesn't feel as seamless or fluid as it does in Emacs. But again, this is not a competition. This is just an acknowledgement that different tools do different things! I regularly rely on commands like 'find ... -exec', 'xargs', 'fzf', etc. But I also use Dired (and Emacs, in general) extensively. I find familiarity with both styles of tools very useful and the knowledge of both types of tools are transferable across a wide range of systems and environments.
syene 1y ago
If you prefer the command-line and Unix shell, that’s one thing, but it’s no more “flexible or scriptable” than Emacs and Lisp. Dired can filter files with regexp; you can even fall back on GNU ‘find’ (‘find-dired’). And you can execute shell commands on filtered files in Dired (‘&’), it’s like xargs without the confusing syntax—but, of course, you can just run ‘xargs’ from it, if that’s what you prefer. A graphical file-manager is, I find, a much nicer interface for file-management than the command-line. I see all filtered files, and I can view and edit them anytime, as I please. With the command-line, it’s like I’m working with blindfolds on. Dired can be a nice refuge even if you’re a command-line junkie, because in-spite of its own commands (abstracting the shell), you can always drop back to the shell, as you please. Funnily enough, my usage of Dired vis-à-vis the shell is kind of the inverse of what you described, I use the shell for either quick or really complicated operations and Dired for everything else—which ends up being over 95% of my use.
- imiric 1y ago
  > If you prefer the command-line and Unix shell, that’s one thing, but it’s no more “flexible or scriptable” than Emacs and Lisp. Preference is definitely a factor, I agree with you there. But while a programming language is obviously more flexible technically, most people don't want to write a program to perform a task on their computer. My point is that the shell is easier to script than writing Lisp (for most people; I'm sure Lisp nerds would disagree), and is more flexible than whatever facilities dired provides out of the box. To be fair, I haven't used dired more than a few times even though Emacs is my primary editor, but even if it emulates xargs or allows you to drop down to shell commands directly, it will never be as flexible for file operations as just using the shell. The shell is not just a file manager. That's one of its primary features, sure, but it allows you to operate on files in an infinite number of ways. This is because it exposes fairly simple primitives that allow you to combine programs in ways that even their authors hadn't anticipated. This is why the do-one-thing-well philosophy is so powerful. The famous Knuth-McIlroy story illustrates this well. Knuth created a sophisticated program to count words, which McIlroy replicated in a one-line shell script using a few UNIX tools. Knuth's was probably more correct, better documented, and handled edge cases better, but McIlroy's obviously required far less effort and would be easier to understand and expand. I don't think any tech geek or programmer would prefer writing a program for such relatively simple tasks.
Ferret7446 1y ago
It's hard to explain thoroughly, but Emacs is basically doing exactly what you say, except interactively. Instead of typing up an entire command pipeline all at once, or running sections of the pipeline into temporary files that you examine/edit with a text editor, Emacs lets you run that same pipeline interactively in a text buffer (basically a temporary file). Being able to see the results as you work on it interactively is a huge advantage (compare ed vs vi).

by imiric 1y ago

roryirvine 1y ago

On top of that, BSD had a standalone 'dired' in the late 80s and Linux moreutils (not quite a standard, but certainly widespread) contains 'vidir' - which, despite the slightly misleading name, allows you to visually edit a directory with whatever your EDITOR env var points to. As you say, none of them do anything that can't be done with find and xargs (and perhaps a little awk and sed), but they're occasionally handy for one-off operations.

susam 1y ago

> GNU find and fd support regex, xargs can be used for bulk operations, etc. I don't see how this is comparable to arbitrarily browsing through a directory, inspecting files, and manually marking the ones you want to act on. The feature I was describing is more akin to how we browse directories in a graphical desktop environment. I use find, xargs, and similar tools as well, but they don't allow you to casually mark or unmark files and run operations on them later. With these tools, you need a fairly precise idea of what you're targeting. Then you have to write a glob or regex pattern up front, and then execute the command. That's a very different workflow from interactively exploring a directory, making ad-hoc decisions, and selectively marking files as you go.

imiric 1y ago
> I use find, xargs, and similar tools as well, but they don't allow you to casually mark or unmark files and run operations on them later. You might be missing fzf from your toolbelt. Running `fzf --multi` does just that, and allows you to pipe the selection further to anything else you want to do. This is why the shell is a more flexible environment. You don't need to adopt a large monolithic tool or drastically change your workflow to do something which you previously couldn't. You just need to insert another tool that does a single thing well into your existing pipelines, and your workflow can be improved with much less effort.
- susam 1y ago
  I use fzf as well, but I don't think it's quite comparable to the kind of ad hoc browsing we can do in a GUI desktop environment or in Emacs. Yes, 'fzf --multi' lets us select multiple files, but it's not really the same as casually browsing through a directory. For example, we might find an image file and preview it, or open a PDF just to skim it, and then mark that file and move on, and continue browsing files in this manner until we've gathered everything we need. That sort of exploratory, flexible interaction feels quite different. Shell tools, Unix utilities, and 'fzf --multi' are definitely very powerful. But at least to me, they don't seem to offer the same kind of spontaneous browsing and editing experience, I'm referring to. To be clear, this isn't some sort of competition! I'm not claiming one approach is superior to the other. Every tool has its strengths. My comments highlighting the features of Emacs do not imply that other tools are inferior. Quite the contrary! I'm very fond of computing and I enjoy having a broad set of excellent tools at my disposal. The only point I disagree with is the claim that "all your examples are easily done in a shell". In my experience, the kind of random, ad hoc browsing, previewing, editing, marking and unmarking files, I'm talking about isn't quite as straightforward in the shell. It's certainly possible, but it doesn't feel as seamless or fluid as it does in Emacs. But again, this is not a competition. This is just an acknowledgement that different tools do different things! I regularly rely on commands like 'find ... -exec', 'xargs', 'fzf', etc. But I also use Dired (and Emacs, in general) extensively. I find familiarity with both styles of tools very useful and the knowledge of both types of tools are transferable across a wide range of systems and environments.

syene 1y ago

If you prefer the command-line and Unix shell, that’s one thing, but it’s no more “flexible or scriptable” than Emacs and Lisp. Dired can filter files with regexp; you can even fall back on GNU ‘find’ (‘find-dired’). And you can execute shell commands on filtered files in Dired (‘&’), it’s like xargs without the confusing syntax—but, of course, you can just run ‘xargs’ from it, if that’s what you prefer. A graphical file-manager is, I find, a much nicer interface for file-management than the command-line. I see all filtered files, and I can view and edit them anytime, as I please. With the command-line, it’s like I’m working with blindfolds on. Dired can be a nice refuge even if you’re a command-line junkie, because in-spite of its own commands (abstracting the shell), you can always drop back to the shell, as you please. Funnily enough, my usage of Dired vis-à-vis the shell is kind of the inverse of what you described, I use the shell for either quick or really complicated operations and Dired for everything else—which ends up being over 95% of my use.

imiric 1y ago
> If you prefer the command-line and Unix shell, that’s one thing, but it’s no more “flexible or scriptable” than Emacs and Lisp. Preference is definitely a factor, I agree with you there. But while a programming language is obviously more flexible technically, most people don't want to write a program to perform a task on their computer. My point is that the shell is easier to script than writing Lisp (for most people; I'm sure Lisp nerds would disagree), and is more flexible than whatever facilities dired provides out of the box. To be fair, I haven't used dired more than a few times even though Emacs is my primary editor, but even if it emulates xargs or allows you to drop down to shell commands directly, it will never be as flexible for file operations as just using the shell. The shell is not just a file manager. That's one of its primary features, sure, but it allows you to operate on files in an infinite number of ways. This is because it exposes fairly simple primitives that allow you to combine programs in ways that even their authors hadn't anticipated. This is why the do-one-thing-well philosophy is so powerful. The famous Knuth-McIlroy story illustrates this well. Knuth created a sophisticated program to count words, which McIlroy replicated in a one-line shell script using a few UNIX tools. Knuth's was probably more correct, better documented, and handled edge cases better, but McIlroy's obviously required far less effort and would be easier to understand and expand. I don't think any tech geek or programmer would prefer writing a program for such relatively simple tasks.

Ferret7446 1y ago

It's hard to explain thoroughly, but Emacs is basically doing exactly what you say, except interactively. Instead of typing up an entire command pipeline all at once, or running sections of the pipeline into temporary files that you examine/edit with a text editor, Emacs lets you run that same pipeline interactively in a text buffer (basically a temporary file). Being able to see the results as you work on it interactively is a huge advantage (compare ed vs vi).