Ask HN: What am I missing re: fascination with command lines

[mwdev]

I consider myself to be a hacker. A fairly good one in fact. But lately something has been bugging me. The command line is making a comeback.

Recently I've been really intrigued by node.js. It has been a freaking pain to get an instance up and running. Joyent? make a curl command line post(That doesn't seem to work). Git? Issue yourself a key via command line. Finally I get into duo stack and then I get a guide with about 25 steps of command line commands.

It is 2011. WTF? Back around the turn of the century we used to have these things called installers that would keep people from having to do the same damn thing over and over and over. Or type. We create these great clickable symbols that were organized into hierarchies that were great for both teaching by way of layout and for getting things done. I think we called them menus.

I've done some digging around and found this insightful post about it: http://news.ycombinator.com/item?id=1407278

...but you know what? I call phooey. As much as it is great that you can mix and match at the command line, a picture is still worth a thousand words.

So tell me hn, what am I missing. Am I fooling my self calling my self a hacker if I use gitgui? (three click and I see exactly what is going where...why is typing 5-6 equivalent lines into the command line better?)

[retroafroman]

The command line is the most flexible way to automate day to day tasks. Yes, a graphical installer makes things easy-once. Need to change the names of multiple files in a directory? Need to delete files that match a certain type, without hunting and pecking? Want to grab every jpg from a webpage? Doing these tasks on the command line is trivial compared to pointing and clicking for every single instance.

There are many benefits from using the command line interface to software. Often it is a trade off between flexibility and speed versus learning and thinking. It takes time to build up a solid knowledge of commands and options, and effort to recall them, but once that skill is acquired, it can save a lot of time.

[mwdev]

Ok...so where do I get started. I've seen a lot of command lines over the last few weeks and nothing in them gave me the impression that there was any sort of logic or automation going on. The all look like just one thing is happening. (And that is one of my strikes against them is that they seem to completely lack context)

[retroafroman]

Start looking into bash scripting, for one. Learning a scripting language like python or perl can do a lot of the same things and is valuable in other ways.

To your comment of looking like just one thing is happening, that is understandable to the untrained mind. Let's take an example where I want to delete all the .bak copies of my old configuration files. To do this I would enter the directory and simply type:

    rm *.bak

It's one command, but the star is expanding it to match every file that has a .bak ending. One command line entry, many executions of the 'rm' command.

Yes, context and a trained eye are everything. I like to think that working on the command line is one of many styles of working. It works very well for me in some situations, so I suggest to others to try it out and see if it would fit their needs as well.

[jpr]

Bash is probably the second worst thing unix has to offer, right after vi.

The command you demonstrated is only slightly faster than sorting the directory by type in a file explorer and selecting them with mouse and selecting delete from context menu, and much more dangerous, ie. when you mistype it as rm * .bak you just deleted everything in that folder permanently, whereas in a GUI you would've seen what you actually selected, and most likely only moved them to trash, not permanently deleted them right away.

[geophile]

A UI is great if it does exactly what you want it to do. But if not, and you want to customize at all, you're stuck. While if you're working on the command line, you can script any behavior you'd like.

A command line approach is also far superior for remote operation, repetition, combining with other tools, etc., because you can script the interactions and control flow.

[bediger]

If I might rephrase geophile, above: a command line (most of them, anyway) has a grammar, complete with flow-of-control constructs like if-then-else, while loops, for-loops.

You can express more with a grammar than without one. For example, you can express palindrome strings with a grammar, you can't with regular expressions.

We can tail off into philosophy by talking about "generative grammars" allowing you to create new ideas, and this may be what geophile says about "[G]UI is great if it does exactly what you want it to do. But if not, and you want to customize at all, you're stuck." I agree with this sentiment.

[mwdev]

I'll give you that the flexibility of the command line can be a help if you're really trying to do something outside the lines, but I'll disagree with the second. If we were in 1998 I'd agree, but with the remote desktop tools we have today there really isn't much of an advantage unless you are bandwidth limited.

[ptn]

Command-lines are faster and more flexible than GUIs, because you define your own workflow - you can chain commands together with the unix pipe, pass arguments to commands that are the result of other commands via the backtick and a lot more cool stuff like that. Also, you can type faster than you can point and click. I prefer to keep my hands on the keyboard where I need them rather than having to reach out for the mouse, which is really far away if you think of it - it's 20cm aprox.

Besides, there's a hacker component in using a cmd, because it teaches you how things really work instead of covering that up with a pretty interface that does the job for you.

If these reasons didn't excite you, then maybe you are simply not a cmd guy - which doesn't discredit you as a hacker, I guess. Hackers build things, no matter what their tool of choice is.

[timrobinson]

For me, command lines are like delegating a task to somebody else: "Find me all the temporary files older than a week and delete them".

In a GUI, I'm doing the task myself: "Hmm, where are the temporary files kept? OK, which are the old ones? I can probably delete these. Wait, here's some more, etc."

As with delegating tasks to people, both approaches have their uses (and pros and cons).

[timrobinson]

Also, I'm finding myself using Vim more, in preference to editors like Visual Studio. The Vim approach is to work out what you want to do, then type the sequence of codes that makes the computer do it for you. The traditional approach is to cursor and tab around, editing the file directly.

[mcotton]

I love the command line because I started at a unix hosting company. It is important to be able to work effectively on remote systems. I can't think of very many production servers that have the option of plugging a monitor and keyboard into (or remote desktop).

I consider command line skills to be a bare minimum for programmer competency.

[makecheck]

I think that whenever there is only a single likely goal (such as "having installed something"), anything more than one command is a problem, and installers are useful.

But any site that gives a list of 25 commands is Doing It Wrong. The whole point of a script is to perform sequences of commands, and a link to a script is just as useful as an installer GUI would be. Except that it's actually better:

- When a script is used, it seems more likely that someone has actually run it. (Who knows if they've updated their document?) There also won't be copy/paste errors.

- A script is transparent; an installer isn't (even when it dumps logs, they're usually a bit vague). It's easier to see that a script will work, and easier to explain what happened if it didn't work.

- Many people don't want step-by-step or excessive explanations, and a script nicely solves this through embedded comments and code. If you need explanations or details, there's a place for them that's out of the way. And if you don't, you can blindly run the script. It's a nice separation.

[sorbus]

Hmm. What's your workflow for reencoding every file in a directory with a name matching a certain pattern and then renaming the reencoded files with a number based on the order that the original files were in? For example, M2441j.avi (an MPEG) should be reencoded into H.264 and then renamed to 23.mp4. All files not matching M###j.avi should be ignored.

Yes, I know that this probably isn't something that you ever do, but humor me. Would you go hunting through, identify all those files and then reencode and rename them by hand? I certainly wouldn't, I would spend maybe five minutes writing and testing a script to do it for me, and then just invoke it every time I needed to do so again in the future.

Programming is all about automation, and the command line is perfect for making programs that do easily repeatable tasks. It's also far easier to debug. As an analogy, do you prefer writing programs by hand or putting together building blocks? It's the exact same thing.

[ms4720]

Well do you want a gadget or a toolbox? GUI's are gadgets, they do what the person who wrote it thinks is a good idea. There is nothing wrong with this. The command line is a toolbox, there is all sorts of stuff you can do to make uniq things happen.

Now from the POV of putting something out there for developers to use which is easier to publish and get out there:

* Several installer GUI's: mac, linux, windows

* about a page of instructions on how to get this done

Which would be the Minimum Viable Product and let you ship now?