How do you learn the command line?

[zapshe]

Experience teaches all you need to know. You just use commands so often that you don't need to look at documentation 99% of the time.

Personally, I rarely use command line. I've had a professor who would make us code programs to take in command line arguments where it was many times more logical to have those arguments given at run-time.

[keskiverto]

Plenty of programs have a "man page" and there is program man for reading them.
For example:

man man
man bash
man cp

Those manual pages can be found from online too, but then there can be a version mismatch, for online can have text for different version than what is actually installed in your system.

There are websites about the use of shell (bash, csh, ksh, ...) that might explain some cases better than the man page.


The command line arguments make non-interactive use and automation feasible. You can store a command and its arguments into a script file and ask the system to execute that script every night. You won't be there to give anything during the runtime and you don't have to remember what options to give every time.

[uplime]

> linux command line

Note that there isn't really a Linux command line.

> What i mean is, how do the people who are actually really really good at the command line learn it?

Usually by experience, practice, trial and error, and reading various documentation, like POSIX and OS manual pages. Your shell will also have a good manual. For Bash, the best resources documenting its behavior are:

https://tiswww.case.edu/php/chet/bash/bashref.html
https://wiki.bash-hackers.org/
https://folk.ntnu.no/geirha/bashguide.pdf
https://mywiki.wooledge.org/

Shellcheck is also a good tool: https://www.shellcheck.net/

If you're serious about learning Bash, I highly recommend not learning from most other resources on the internet, as they're usually full of errors and misconceptions in regards to shellscript. Namely:

stackoverflow.com
tldp.com
The Advanced Bash Scripting guide

[kbw]

As @zapshe said, experience.

I started with with a few to get started; man, find, grep, cat, ls, top, kill, and an easy to use editor. Then you just add to that toolkit and pick up new flags over time.

[jonnin]

use putty to connect to the target server. Now make it do things.
Its kinda trial by fire, but it works. I bought my first computer as a teen, fire it up, and it says c:\ ... now what? I think it took me like 2 days to get anything more out of it than a directory listing and 'blah is not recognized as a command, program, batch file, whatever' words.

[newbieg]

I love the terminal because there's always some way of doing 'X'.
If I do not know how to do 'X' then I google "how do I do 'X' on linux console terminal"
The first link is often the right link.

Things 'X' can stand for
'play videos in ascii' -> mplayer -vo caca yourvideo.mp4
'browse the internet' -> lynx yourwebsite
'download only certain file types from a website' -> wget and several commands
'video editing' -> ffmpeg -i yourVideo -many_options outputVideo
'Make changes to a batch of image files' -> imagemagick -many_Options

... and the list goes on.

I took a junior college class about unix several years ago which gave me several months to understand the basic toolkit that KBW is talking about. I feel that was worth while as I'd never touched anything but windows before that. Now I feel gross if I'm forced to use a PC.

[zapshe]

I feel that was worth while as I'd never touched anything but windows before that. Now I feel gross if I'm forced to use a PC.

Not only can you use the Terminal now on PC, but there's usually always a better and more convenient option. Running my code on the terminal for College is a pain compared to running it on Visual Studio. Especially when I can still do command line arguments, memory leak checking, etc. right from Visual Studio.

The particular list of things you've put of things you can do with the terminal doesn't really wet the appetite. I'd much rather do those things myself rather than ask a terminal to do them for me.

As you, I feel grossed out when I have to use something other than a Windows PC.

[keskiverto]

I'd much rather do those things myself rather than ask a terminal to do them for me.

No, not yourself. You rather use program X with UI Y than program Z with UI W, but you do use some program and you do feed it input somehow.

Command prompt in terminal is merely an alternative to icons and context menus of GUI desktop.


\begin{rant}
"PC" used to mean "Personal Computer". IMHO, that term in itself does not say anything about the operating system within the device.
\end{rant}

[zapshe]

No, not yourself. You rather use program X with UI Y than program Z with UI W

By "myself", I mean with my hands on the controls. The software I use for many things allows for more control, and you don't need to type out whole commands at a time to do them.

Command prompt in terminal is merely an alternative to icons and context menus of GUI desktop

That's not how I would put it. The terminal is a counter-intuitive way of doing things. Why instead of firing up the program to directly do X, you instead fire up the terminal and then type in a bunch of stuff to do X?

How would you even do ANY GOOD "video editing" using the terminal? There's no comparison to be made. The terminal has it's pros, but mostly limitations for my experience. Using it takes longer than using any software or IDE for code. If I have to remember the terminal usage I had to go through in my assembly class again, I'll have to suicide. And dear God if I encountered an error with the terminal. I could probably have troubleshooted 10 other programs in the time it takes to figure out and fix a terminal error - which seems to always be something deep rooted.

\begin{rant}
"PC" used to mean "Personal Computer". IMHO, that term in itself does not say anything about the operating system within the device.
\end{rant}

I agree, which is why I specified Windows PC. Though now PC is synonymous with Windows Computers.

[uplime]

That's not how I would put it. The terminal is a counter-intuitive way of doing things. Why instead of firing up the program to directly do X, you instead fire up the terminal and then type in a bunch of stuff to do X?

why fire up a heavy editor to find all of the lines i need, then cut them out, when a quick, short grep will do?

There's no comparison to be made. The terminal has it's pros, but mostly limitations for my experience.

Assuming you meant your shell, its usually only limited by misuse. I do almost 90% of my work in a terminal, and most of my colleagues do as well. I use to mange a fleet of wordpress servers with only a terminal to access them.


edit:

Using it takes longer than using any software or IDE for code. If I have to remember the terminal usage I had to go through in my assembly class again, I'll have to suicide. And dear God if I encountered an error with the terminal. I could probably have troubleshooted 10 other programs in the time it takes to figure out and fix a terminal error - which seems to always be something deep rooted.

that definitely depends on how comfortable you are with it and your experience. I never use an IDE because half of the time I can never figure out why a project fails to build. It definitely takes me longer to configure everything for it

[Albatross]

Somewhere along the way, zapshe, you have fundamentally misunderstood the purpose of the terminal. The point is not to act as an all-in-one interface to all forms of software. At best, it's an all-in-one interface to pure textual forms of software, where the text in question has limited formatting requirements.

Does that mean nobody's going to try and hammer square pegs into round holes, and make a terminal emulator do things it's not optimal for? Like displaying video without underlying support from the terminal emulator itself, and thus having to watch it as ASCII art? Sure, but pointing those instances out doesn't make for a good argument against CLIs as a whole.

It's also worth noting that what's "intuitive" or not is highly subjective. Oftentimes, "intuitive" is code for "what I've had personal experience with". And yes, CLIs are a huge paradigm shift from your typical Windows GUIs. This is most obvious when you realize that most CLI programs are single-purpose (barring scope creep that inevitably happens). You absolutely could use a shell as just a simple program launcher, but that would defeat the point. Instead:

* Most REPLs run in terminal emulators, making it easier to experiment with programming languages.
* Shells give you the ability to create text processing pipelines, tersely.
* Batch operations on files, even complex ones, are fairly trivial with shells.
* CLI programs, where they're interactive, typically have very terse keyboard shortcuts or commands of their own which, once learned, are far more efficient to use than hunting through menus.

There are more examples, of course, but those are the most obvious (and hardest to argue) that come to mind.

And finally, I'll finish by saying that my terminal code editing experiences have been largely more positive than my IDE editing experiences, now that LSP is a thing and we can integrate language support into almost any sane editor. Keep in mind:
* Modern build systems are not tied to any particular editor.
* Debugger devs often implement CLIs first, leaving GUIs to them to the editor devs, who are left playing a game of catch-up.
* In my experience, most GUIs to version control systems are either severely limited, or non-free.

-Albatross

One thing I'll concede on in this discussion is that terminal programs are bad at being self-documenting. That's why modern shells have autocompletion, and why we've had searchable man pages for decades.

[zapshe]

why fire up a heavy editor to find all of the lines i need, then cut them out, when a quick, short grep will do?

Everything has it's pros/cons and situations they work best for. I'm only saying that my experience tells me that the cons out weight the pros.

I never use an IDE because half of the time I can never figure out why a project fails to build

I've seen my friends in college using the terminal as they're taught to, and they end up with some issue that would be easily solved using an IDE - especially Visual Studio in many cases.

To me, a terminal wastes time. You have to look for the appropriate written command which can so many times be hidden behind a wall of other commands you used. Nothing beats just Ctrl+F5 and having your code run.

It definitely takes me longer to configure everything for it

It's a set it and forget it kind of deal. Once you set up the IDE once, you likely never have to again. The terminal pales in comparison to this. Even if you have a bash script that you have handy to run all the time, it's not as fast as an IDE in terms of how long it takes to go from coding-to-testing.

Surely, if access to the terminal was the only upside to not using Windows, then you'd flock to Windows now that it's so easily accessible.

The point is not to act as an all-in-one interface to all forms of software. At best, it's an all-in-one interface to pure textual forms of software, where the text in question has limited formatting requirements

I was not under that impression. My rebuttal was to the post claiming the terminal is useful for doing "X". I'd much rather use intuitive and control-filled software rather than a terminal. The reply to that by others seemed to say that the terminal and software are somehow interchangeable.

My argument overall is about using the terminal for coding. The view saying the terminal is useful for doing what any software can was a side argument that I shot down.

[uplime]

I'm only saying that my experience tells me that the cons out weight the pros.

Again, that depends on how comfortable you are with one vs the other

I've seen my friends in college using the terminal as they're taught to, and they end up with some issue that would be easily solved using an IDE

That goes both ways. I've never successfully compiled a project with boost. Everytime it just failed with mysterious errors, whereas on my command line I just make sure they're installed in the proper LD library path and pass -l.

You have to look for the appropriate written command which can so many times be hidden behind a wall of other commands you used.

That still goes back to being more comfortable with one than the other. There's plenty I'd have to look up in an IDE, hidden behind walls of documentation. It not being on the command line doesn't magically make it easier (for everyone) to use.

Once you set up the IDE once, you likely never have to again. The terminal pales in comparison to this.

It doesn't. I've setup my shell just the way I want it years ago, and hardly ever need to change. Only when my tastes change (for example, I recently decided I liked a new prompt style) do I actually edit it. I'm sure its the same for an IDE.

Surely, if access to the terminal was the only upside to not using Windows, then you'd flock to Windows now that it's so easily accessible.

The last time I used Windows, the first thing I did was install a terminal (I believe it was called MinTTY) and Bash.

I'm just not sure how an IDE is magically more efficient, when almost all of its advantages you're talking about come with familiarity with it, just like with a terminal and a shell

[zapshe]

I've setup my shell just the way I want it years ago, and hardly ever need to change. Only when my tastes change (for example, I recently decided I liked a new prompt style) do I actually edit it. I'm sure its the same for an IDE.

I meant more in terms of running code. You link libraries once, #include them, and forget about it. If one day you decide to use a library you haven't in a few days, you have to either look up the terminal lines again, or lookup the text you need to run the library. On an IDE, you just write the code and #include as normal.

I'm just not sure how an IDE is magically more efficient, when almost all of its advantages you're talking about come with familiarity with it, just like with a terminal and a shell

We could go into a million things, like stepping through your code, looking at real-time memory usage, better assistance with coding errors, better optimization of compiling code (If you change a single line of code, the compiler won't have to recompile all your code before running it), etc.. Could probably write a book about how much hassle you don't go through with a good IDE.


It comes down to preference, but I've yet to find any meaningful way that using a terminal is better than an IDE other than being light weight and maybe more expedient when dealing with a single program with unchanging parameters. However, with an SSD in my rig, VS opens in almost exactly (just under) 3 seconds. Loading a new or already started project takes roughly the same amount of time. Unless you're editing code on the terminal or something like VSCode, you're going to open up the terminal and a text editor, switching between them to go from writing to running code.

I'm impatient, and using the terminal feels like grunt work that I should be leaving up to my IDE.

[Albatross]

zapshe, I mean this with as little offense as possible, but it's becoming increasingly clear that you're arguing from a point of ignorance of what's possible with a shell. You're not entirely to blame for it. Academia is weirdly bad at teaching people actual real-world practices.

Most of what a GUI IDE (which is worth emphasizing; one can also turn a CLI editor like vim or emacs into an IDE) actually does is implemented by tools that, guess what, have full CLIs. Visual Studio might be the main exception to that rule, but for most of the common tasks you'll do in an IDE, there is a featureful way to do that using a CLI program. Don't believe me? Let's go over your list:

* gdb and lldb have learning curves, but their CLIs both have full support for setting breakpoints, incrementally executing code, watching variables, all that jazz.
* Real-time memory usage depends on how you want it displayed. If you just care about looking at the amount at the current time, then every sane terminal process manager lets you focus on one process. If you want a chart, then sure, displaying that in a terminal would be a mistake, but that does NOT automatically mean "I have to use a GUI IDE".
* Let me reiterate. Virtually every modern build system (except maybe for Visual Studio's) can run in a terminal. In practice, very few people actually write shell scripts to invoke a specific compiler for every single file in a build, and when they do, they're often told by people who know better to upgrade. Hell, even GNU make supports incremental building (to a degree). And yes, those build systems are configured by actual files, meaning one doesn't need to mentally keep track of what libraries they're using and what flags to use to link them. You've straw-manned.
* For that matter, one doesn't need to leave the terminal to edit code either. Even if modal editing isn't your thing, nano and emacs still exist. And yes, robust code analysis features exist in those editors as well.

That said, is it for everyone? No, and to be fair, shells have their issues (just ask uplime). There is also a learning curve that can get very, very steep. For beginners, I'd argue that most of the time, it's unreasonable to expect them to deal with learning to use a shell AND their programming language of choice, and so I would tend to recommend an IDE.

And yes, the out-of-the-box experience on your typical IDE will be better. That's expected. For people who are heavily into terminal stuff, however, a good out-of-the-box experience is good to have, but what really sells them is the flexibility, the ability to tailor their experience until it works best for them. You're not bound by whether a specific tool is supported for your IDE or not (which I have been burned by before). There's also a certain beauty in using one's ability to code as part of the process of developing something, rather than using an interface that almost has to be cluttered in order to be both self-documenting and featureful.

Anyway, food for thought.

-Albatross

I'm handily ignoring the fact that many IDEs have integrated terminals. In a way, one might consider it telling.

[kbw]

As always, these threads tend to spin out of control.

I can't see how bashing development in a terminal helps you to learn how to use a terminal. Someone asks for help and provided with a host of reasons why they shouldn't have asked for help. Really helpful.

[zapshe]

it's becoming increasingly clear that you're arguing from a point of ignorance of what's possible with a shell

How so? I've made breakpoints and such with a text-editor that had a terminal - and I couldn't have missed my IDE more. I didn't know that you could see your memory usage with the terminal though.

My wording may have been a bit off, but my whole argument is a matter of convenience and expediency. An IDE is wildly convenient.

I'm handily ignoring the fact that many IDEs have integrated terminals. In a way, one might consider it telling

Yes, an IDE caters to everyone. And there are a few benefits the terminal has. I liked how with the Ubuntu app I could easily download libraries. But that's about the only point where it was a bit more convenient than an IDE.

what really sells them is the flexibility, the ability to tailor their experience until it works best for them. You're not bound by whether a specific tool is supported for your IDE or not

I've found VS to be flexible, and I don't really run into trouble with compatibility.

This is all just opinion in the end as I've said - personal preference. Simply, uplime's points have just not made it past my skull.

[kbw]

An Integrated Development Environment is for development. There's more to using a Unix box than developing code.

You're focusing on a very narrow use and missing the beauty of Unix. The beauty being; you don't need to write apps for everything, you can combine existing tools to get stuff done.

[zapshe]

There's more to using a Unix box than developing code

Well in this context..

I'm sure I don't know as much as most here, but I can't imagine myself using the terminal if it can be avoided.

[jonnin]

Not only can you use the Terminal now on PC

now as in 1993? I know I was connecting to unix boxes on dos 5.x ... nothing new there.
I need to find one that has windows paste though. Putty paste gettin on my nerves, I don't use mouse much.