3 ms·
Different people will draw the line in different places. Take your example of file management: since I'm usually in a terminal, it takes far less effort to ent
by II2II 6y ago
Different people will draw the line in different places. Take your example of file management: since I'm usually in a terminal, it takes far less effort to enter a command than it does to open up a graphical file manager and navigate to the desired directories.
The other issue is that few file managers are as powerful as command line utilities. There are exceptions. I am quite fond of Directory Opus while using Windows since it feels like a program designed by people who understand the scope of file management. Alas, it is an exception rather than the rule. Most file managers facilitate basic functions then stop there. With the shell, that's not really an issue since you can always add another utility to your tool box.
- lupire 6y agoMac: open $dir Linux (whatever env provides this): xdg-open $dir
- II2II 6y agorm -rf scratch/ qmv -f do *.pdf find -name "*.epub" -exec mv {} ~/books/ \; cp *.c ~/remote/hostname/src # with sshfs The list can go on. The GUI may be better when you have to manually pick through a small number of files, but calling up a file manager to handle a single file or a bulk operation rarely makes sense (if you're already in a shell). EDIT: inserted line breaks
- elabajaba 6y agoWindows powershell: ii dir (eg. ii ./)
- cosmotic 6y agoThere's more than just effort to consider. Discoverability, confidence, error recovery, and consistency come to mind. You might be in a terminal, in the directory you're you want to copy a file within... $open ., type file name, command-C, command-C, command-W would do a great job, require minimal additional effort, but provide better visibility into the status of the copy, allow you to better handle file name collisions, allow you to retry, and be undoable. If you didn't know the correct program or arguments for zip, you could simply look around the menus and find 'compress'. Even scripting, you can use the best tool for the job. AppleScript or similar can be used to script GUIs and also for testing.
- fiddlerwoaroof 6y agoFor 90% of this stuff “discoverability” isn’t a problem anymore, I’ve already crossed the learning curve of the command line and I just think in terms of the available command line programs. For the next 5%, I tend to pipe a command like find or ls to a file and then use vim to quickly make a shell script that does what I need. I don’t know if it’s more efficient, objectively, but this just is the workflow that matches how I think.
- cosmotic 6y agoI've been using the terminal (admittedly not as my main interface) for 20 years and I still have to consult man pages, documentation, and google about 10 times a day. I'd say discoverability is certainly still a large problem with CLI.
- II2II 6y agoApple had an interesting take on discoverability with AU/X and MPW: you could pull up a dialog box with the available options and descriptions. Unlike man pages, you could select the desired options from the dialog box and execute the resulting command. It's not the sort of thing you would want to use often, but it was great for learning how to do things or to refresh one's memory.
- fiddlerwoaroof 6y agoIn zsh, I think Ctrl-/ pops up the manpage and then restores the command line when you quit (this may be just my config). It’s not as nice, but zsh’s line editor does implement everything you need to extend it with this sort of workflow