3 ms·

Ahh, these responses... (This space reserved for further passive aggressive comments.) You didn't say how you arrived at the conclusion that shells are "so suc

Ahh, these responses... (This space reserved for further passive aggressive comments.) You didn't say how you arrived at the conclusion that shells are "so successful". How are you measuring that? > ...a command we wrote to group image sequences together. This makes finding missing images in a sequence, knowing the range, and dealing with 1000's of files in a folder trivial. These are technically possible with a gui... Those things are eminently possible with a GUI without writing your own file browser since most major file browsers offer a range of extensibility options. Also, GUI automation is a thing and it works well. Just last month I wrote a simple script to automate image extraction from a program that didn't provide any API for it. As a matter of fact, I didn't even have to write most of the script because the computer aided me by recording my mouse clicks. > Jumping to the mouse does slow things down. Looking up commands and configuration protocols slows things down way more though. > Someone who has never used a computer would be equally confused at how a mouse or scrolling worked. Equally as confused as they'd be when presented with nothing more than a blinking cursor? I don't think so... Once you move the mouse and see the pointer move, it's pretty obvious how movement works. Sixty seconds is enough time to accurately convey complete operating instructions for a mouse. Teaching someone how to use a shell would take much more time I imagine. Anyway, I use a shell when it suits me and a GUI when that suits me, but most importantly, I am not a bigot or an elitist about it. I don't think that there is one true way to do things.

pfranz 12y ago
"Ahh, these arguments." was actually intended for both sides (gui and cli) since I don't particularly care which people prefer. Like I said, they both have pros and cons. It hasn't been explicitly said, but all of these arguments are implicitly about file browsing and file management. I can't imagine anyone exclusively using commandline tools for things like audio editing, browsing the web, etc. I'm genuinely interested, how would you write something like that for a file browser on any platform?
- WorldWideWayne 12y ago
  > ...how would you write something like that for a file browser... A GUI program can do everything that a command line app can do and more, but unless we discuss exact requirements I can't answer the question very precisely. In terms of input and output I think there are generally more options with a GUI though. Funny story on this topic - last night I was playing around with Fedora 21 + Gnome 3 and when I used git (in a terminal), whenever it needed a username or password it would pop up a GUI with a single text input. It's called askpass and I still haven't found out what exactly necessitates such a workflow, but I thought it was pretty hilarious. > ...on any platform. Command line programs don't work on every platform. Far from it. They don't even work on every Linux distro and especially not with normal usage on variants such as Android. So that's a bit of an unfair requirement to add just for GUI apps, don't you think? I think we're in agreement that they both have pros and cons. It certainly can be easier to write a command line application that works on all platforms. I wasn't arguing against that - I was arguing with the guy on this thread who seemed to think that command lines are the single best way to interface with the computer. The guy who responded to almost every dissenting point of view...(not you). I didn't realize that it was not you at first, but my first response was to that person.
  - pfranz 12y ago
    By any platform I meant "a platform of your choice." Like I mentioned in my first reply, I'm not aware of any OS's file browser with a plugin system to do something like what I described in any scope. I'm curious the tools someone who had their choice would gravitate to. There are a lot of things I like with a terminal; history, tab completion, man pages (all OS help pages are generally useless. The only aspect I've ever liked is OSX's searchable help menu that will hightlight menu options). On the gui end you can't beat the discoverability, window management, but a big win is an undo stack. I feel like touchscreens are a step back in discoverability (but they have their own merits). I think terminal people really latch on to the composibility of Unix apps that are provided via pipes. I've seen people try to come up with a gui equivalent (copy/paste is the closest), each gui feels like a walled garden (almost as bad as iOS apps). Something like AppleScript or D-Bus tries to address this, but I feel like if you're writing a script its basically a less-interactive shell. Automator seems like a decent take on this, but not too many apps expose an api for that and I've struggled trying to get it do what I wanted.

pfranz 12y ago

"Ahh, these arguments." was actually intended for both sides (gui and cli) since I don't particularly care which people prefer. Like I said, they both have pros and cons. It hasn't been explicitly said, but all of these arguments are implicitly about file browsing and file management. I can't imagine anyone exclusively using commandline tools for things like audio editing, browsing the web, etc. I'm genuinely interested, how would you write something like that for a file browser on any platform?

WorldWideWayne 12y ago
> ...how would you write something like that for a file browser... A GUI program can do everything that a command line app can do and more, but unless we discuss exact requirements I can't answer the question very precisely. In terms of input and output I think there are generally more options with a GUI though. Funny story on this topic - last night I was playing around with Fedora 21 + Gnome 3 and when I used git (in a terminal), whenever it needed a username or password it would pop up a GUI with a single text input. It's called askpass and I still haven't found out what exactly necessitates such a workflow, but I thought it was pretty hilarious. > ...on any platform. Command line programs don't work on every platform. Far from it. They don't even work on every Linux distro and especially not with normal usage on variants such as Android. So that's a bit of an unfair requirement to add just for GUI apps, don't you think? I think we're in agreement that they both have pros and cons. It certainly can be easier to write a command line application that works on all platforms. I wasn't arguing against that - I was arguing with the guy on this thread who seemed to think that command lines are the single best way to interface with the computer. The guy who responded to almost every dissenting point of view...(not you). I didn't realize that it was not you at first, but my first response was to that person.
- pfranz 12y ago
  By any platform I meant "a platform of your choice." Like I mentioned in my first reply, I'm not aware of any OS's file browser with a plugin system to do something like what I described in any scope. I'm curious the tools someone who had their choice would gravitate to. There are a lot of things I like with a terminal; history, tab completion, man pages (all OS help pages are generally useless. The only aspect I've ever liked is OSX's searchable help menu that will hightlight menu options). On the gui end you can't beat the discoverability, window management, but a big win is an undo stack. I feel like touchscreens are a step back in discoverability (but they have their own merits). I think terminal people really latch on to the composibility of Unix apps that are provided via pipes. I've seen people try to come up with a gui equivalent (copy/paste is the closest), each gui feels like a walled garden (almost as bad as iOS apps). Something like AppleScript or D-Bus tries to address this, but I feel like if you're writing a script its basically a less-interactive shell. Automator seems like a decent take on this, but not too many apps expose an api for that and I've struggled trying to get it do what I wanted.