

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.<p>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.<p>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.<p>I've done some digging around and found this insightful post about it:
http://news.ycombinator.com/item?id=1407278<p>...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.<p>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.

------
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?

