
Learn just enough Linux to get things done - shrikant
http://alexpetralia.com/posts/2017/6/26/learning-linux-bash-to-get-things-done
======
yoran
_One example of this is the popular version control system (VCS) called git.
Developers could have written this software to work on Windows, but they didn
't. They wrote it to work on the command line for Linux because it was the
ecosystem which already had all the tools they needed._

I think the real (and even stronger) reason is that Linus Torvalds
specifically built Git to serve as the VCS for the Linux codebase.

~~~
recursive
And git _does_ work on Windows. There's even a windows logo on the official
download page. [https://www.git-scm.com/downloads](https://www.git-
scm.com/downloads)

~~~
bunderbunder
Git for Windows relies pretty heavily on MinGW, though. And it's best used
from the included bash shell.

~~~
lelandbatey
I do want to point out that Git being built with MinGW doesn't do anything to
affect its compatibility. MinGW is basically just the GCC compiler suite
ported Windows. It doesn't do anything about making C code written for Linux
compatible with Windows.

Now typically, when you install MinGW it also installs some tools that let you
operate within Windows a little bit more like you're working under Linux, such
as by installing a more sane terminal emulator and Windows-compatible ports of
some popular programs e.g. grep. But all those tools and such are _ports_ of
Linux programs running on Windows, not standard Linux programs running atop a
compatibility layer to allow them to work on Windows.

I mention the above because this was an unclear distinction to me originally.
Additionally, this was based on my experience with MinGW some five years ago,
and I don't know if everything I've described is still true. Hopefully this
slight aside clarifies things for someone.

~~~
geezerjay
> MinGW is basically just the GCC compiler suite ported Windows.

That's where you get it wrong. MinGW is a compatibility layer that helps port
unix apps to windows. Yeah, it comes with GCC, but it also comes with support
for POSIX, including a unix shell and other standard components.

Claiming that MinGW was just GCC would imply that to run Git on windows would
be just a matter of recompiling the source code. But it isn't.

------
grx

      This is not a surprise - the Windows ecosystem simply wasn't designed with software development in mind.
    

Aha? What is C# and Visual Studio? Or .NET? Was Linux designed for software
development?

This article is so bad, I'm really getting mad over here. Stop publishing such
crap, you feed a lot of people's resentment against all those hipster
developers who don't want to learn by RTFM, but want to have handled
everything.

Articles like this are a real hurdle on the way towards making Linux and
programming in general more approachable to non-techies. Just stop, please.

~~~
ajross
> Was Linux designed for software development?

Linux was designed to emulate Unix and run the pre-existing Unix-like
userspace from GNU.

And _absolutely yes_ , Unix was "designed" for software development. That's
exactly what it was in its early days: a hacker playground for the geeks at
Bell Labs to try new ways of doing things.

And windows wasn't. Early windows development (for years after it became
popular) was done at a DOS command line. Eventually Visual C++ because the
dominant product, and certainly you can't say it wasn't innovative. But it
remained a separate product. "Windows" wasn't for development. And we still
suffer from this in, say, the way windows basics (like the standard C
runtime!) typically need to be shipped per-app and are only vaguely compatible
across OS and toolchain changes.

~~~
vvanders
> Early windows development (for years after it became popular) was done at a
> DOS command line ...

I could just as easily flip this and claim that Linux development is all
backwards because it's still done on the command line.

Given Microsoft's commitment to tooling, backwards compatibility and extensive
documentation I think it's pretty lame to try and paint windows as not
targeted towards developers. The difference is that windows has actual users,
as opposed to the eternal horizon of "the year of linux on the desktop".

~~~
stevenwoo
Effective early Windows development required a surprisingly thorough knowledge
of DOS and x86 memory management/pointers that one had to get through books
(unless one was poring through Intel chip specs). Even though Petzold's books
were/are sold through Microsoft in my opinion is it's a stretch to call it
documentation. For a long time, the best debugger was a third party tool -
Soft-Ice. Their documentation/tools for XBox was pretty great, though, they
had to do well there being new kid on the block. Microsoft had the benefit of
90% of PC market share at that time so we all had to learn it if we wanted a
piece of that pie.

~~~
hackits
Those books where widely published from the start from Microsoft and
Developers. There was aspects of the API were not released to the general
public but it didn't stop a developer from knowing about them.

You also has the MSDN subscription that did cover a lot about the development.

~~~
stevenwoo
Yes the MSDN subscription which seemed like kind of a racket at several
hundred dollars ( it was up to $1000+ by 2001 depending upon support
level/media ). Also they would frequently have documentation about something
in one year, then drop it from the CD's/DVD's and if you got lucky you had
those or someone was really nice and posted it on the internet. I remember
having to figure out the IME's for Far East/etc input circa 2000 from a usenet
post then handing that information down to a someone else on usenet so they
could implement it as well.

------
AlexB138
Mentioning strace in an article titled "Learn just enough Linux to get things
done" seems so out of place as to be absurd, even in an "Advanced" section.
Anyone who needs the rest of this advice is going to be absolutely baffled by
strace.

Otherwise, decent little primer.

~~~
luord
I've been a linux user for almost eleven years now, and a professional
software developer for four, and I wasn't even aware that strace existed until
just now.

~~~
laresistance
I've been tinkering on Linux as a hobby for about 2 years now and was made
aware of strace a couple of months after starting to dig a bit deeper. You
make me hopeful of my future employment.

~~~
empath75
I’m 100% telling the truth when I say I got a job as a Linux sys admin at a
massive tech company on the basis of knowing a little bit of bash scripting.
And this wasn’t even that long ago. Learn some devops stuff and you’re golden.

------
carlosrg
This article should be named "Learn just enough Unix to get things done".
Almost everything explained can be done on any Unix-like system like macOS and
it's not exclusive to Linux.

~~~
eitland
Disagree.

It could be mentioned early in the article.

However for its target audience (I assume) that would be far less useful.

("This looks great but seems to be about Unix and I know this is a Linux
thing.")

------
reacweb
In my project, I maintain 3 documents. The first one is a similar list of
basic linux knowledge that people should learn when arriving on the project.
The second is "UnixTipsAndPitfalls" where people should add new entries when
they encounter usefull commands. The third one is about tar.

~~~
ivanhoe
Over years I've heard a lot of complains on tar being hard to use, but in
real-life I really ever had to use only these two commands: tar zcvf and tar
zxvf. It's actually quite easy to remember: tar Zip Compress Verbose File, and
tar Zip eXtract Verbose File.

~~~
nerdponx
It's even easier than that! Less memorization, more understanding.

You can think of Tar arguments as either _subcommands_ or _options_. The
dashes are optional

The "subcommands" are x (extract), c (create), t (list), among others.

The "options" are f (read from named file rather than stdin), v (verbose
mode), and z (run gzip on the archive before processing).

The fact that these options can be written without leading dashes, and all
smashed together in a single argument, is legacy silliness for saving a few
keystrokes. Don't confuse yourself with it, and don't confuse other people by
teaching it to them, instead of teaching them how to actually use the command
(which is really not hard at all).

So when I write Tar commands, I like to think along these lines. Instead of
"tar zcvf foo.tar.gz", I write "tar -c -zv -f foo.tar.gz". After doing that
about 3 times, it all sank in. Nowadays I'm much more intimidated by Git than
Tar.

In the version of tar on the machine I'm posting from (GNU tar 1.27.1), this
structure is obvious from right there in the man page:

    
    
        SYNOPSIS
           Traditional usage
               tar {A|c|d|r|t|u|x}[GnSkUWOmpsMBiajJzZhPlRvwo] [ARG...]
        
           UNIX-style usage
               tar -A [OPTIONS] ARCHIVE ARCHIVE
    
               tar -c [-f ARCHIVE] [OPTIONS] [FILE...]
    
               tar -d [-f ARCHIVE] [OPTIONS] [FILE...]
    
               tar -t [-f ARCHIVE] [OPTIONS] [MEMBER...]
    
               tar -r [-f ARCHIVE] [OPTIONS] [FILE...]
    
               tar -u [-f ARCHIVE] [OPTIONS] [FILE...]
    
               tar -x [-f ARCHIVE] [OPTIONS] [MEMBER...]

~~~
gandreani
Thank you! That was very useful

------
frabbit
In place of the "tabview" command (which is a non-standard, pip-installed
program) a simple "column -t" would be less trouble for most users.

~~~
otterpro
Thanks. I was looking for tabview but it wasn't easy to find, and in python
(not that it's bad, but it wasn't a native tool). Rather, column -t is
definitely a better choice, since it is a native posix tool.

~~~
jwilk
column(1) is not in POSIX.

It originates from BSD, but it's also part of util-linux, so it should be
available on most Linux distros.

------
lain
I don't think I could disagree more with having `man` at the bottom of the
advanced/infrequently-used section. Learning how to read and search through
the documentation that comes with the system is a very beneficial thing to
learn how to do.

~~~
Bartweiss
I think I agree with the placement. It's definitely a good skill, I wouldn't
dispute that, but it really is advanced/infrequent by the standards set here.

Historically that wasn't true, but Stack Overflow has made it vastly easier to
answer simple questions ("Which 'ls' flag shows permissions? How about hidden
files?") without ever using a man page. You can go a long time without ever
touching that and not have problems, while jumping to man pages without
experience tends to be an overwhelming jumble of flags and conditions.

Which isn't to say it's low value! Learning Linux well beyond "good enough" is
still an enormously worthwhile project. But I do think it's correct to say
it's no longer an entry-level step.

------
alexpetralia
Hi everybody - author here.

Surprised to see this on the front page. I agree with most of the feedback and
criticism here.

Hopefully some readers found it helpful regardless.

~~~
emmelaich
It's ... pretty OK :-). My points/suggestions...

1\. I've never heard of tabview and it's not on MacOS or Fedora.

2\. Add ctrl-D to your possible exits. It's actually more common than ctrl-C.

3\. Some of those commands are not installed by default on many systems; e.g.
htop or dstat. And they require sdvanced knowledge to properly interpret. But
they can be very useful. I'd suggest standard `top` and things like iostat
instead.

------
misterioss
[https://github.com/jlevy/the-art-of-command-
line](https://github.com/jlevy/the-art-of-command-line)

~~~
plupf
[https://linuxjourney.com/](https://linuxjourney.com/)

~~~
mediocrejoker
[https://www.learnenough.com/command-line-
tutorial](https://www.learnenough.com/command-line-tutorial)

------
dsfyu404ed
Learn Just Enough Linux To Make QA, Ops, Security Hate You.

Learning to do a thing and learning to do a thing well enough to create a
production quality result that isn't a liability to the company are very
different. That said, improving Linux knowledge among those who had
little/none before is a net win in the long term IMO.

~~~
Finnucane
>Learn Just Enough Linux To Make QA, Ops, Security Hate You.

Hey, that's me!

------
SaltyBackendGuy
And not even one mention of man pages... That is was my main resource for
learning new (remembering old) commands. Maybe it's out of date now due to
google, but if you're already in the terminal man is the way to go. Also, I
feel like cat and less should have separate explanations as they have
diverging utilities.

~~~
SquareWheel
There's two mentions of man pages.

~~~
SaltyBackendGuy
<Apologize> I missed in my initial skim

------
dahart
I’ve always felt there are two different kinds of Unix/Linux: sysadmin vs
user. While Linux distros have been getting better and easier for many years,
installing and maintaining Linux on my own machine still requires sysadmin
Linux knowledge to this day.

I personally believe this is why Macs have been so popular since OSX, it’s
really the only machine out there that comes with Unix but doesn’t require
_any_ sysadmin knowledge to use productively.

As soon as Linux truly reaches that same point where users can install and
maintain it without needing sysadmin Linux, I think it could take over Mac’s
position. And I wish it would, OSX seems to stuck in old version limbo.

~~~
wutbrodo
> While Linux distros have been getting better and easier for many years,
> installing and maintaining Linux on my own machine still requires sysadmin
> Linux knowledge to this day.

I'm not sure that's true. You can buy a few computers (including from Dell)
with Linux pre-installed, and maintenance doesn't take a lot more than
clicking on the upgrade button with the daily update-manager prompt.

I _do_ have sysadmin knowledge and find the shell more efficient than the GUI
in 99% of everyday-use cases (I can't remember the last time I opened a file
browser). So it's entirely possible that there's some day-to-day work required
that I'm not even thinking about.

But my dad is running a Linux Mint system and I switched him to it (about ~10
years ago) because it required so much _less_ maintenance than running a
Windows machine did. The number of phone calls for tech support I got from him
plummeted from twice a week to zero when I switched him from Windows: I did so
because I got tired of fielding constant questions about antivirus software,
defragmentation, startup programs littering his systray, possible viruses
installed, etc etc etc etc. It's really beyond me why anybody thinks that
Windows is an appropriate OS for a non-technical user (er, or for a technical
user, or really anyone who doesn't need specialty software).

~~~
Bartweiss
> _I 'm not sure that's true. You can buy a few computers (including from
> Dell) with Linux pre-installed, and maintenance doesn't take a lot more than
> clicking on the upgrade button with the daily update-manager prompt._

Is it really that good these days?

I can definitely appreciate the constancy of Linux, it feels like
Windows/Chrome/etc stacks move under my feet constantly. But my experience
with Linux is still that when problems _do_ arise, I have to escalate to shell
commands and arcane sysadmin-ry for all but the simplest problems. Windows and
OS X still offer a lot more hope of an accessible fix via the GUI or even an
automated troubleshooting tool.

It's totally possible I'm dealing with the wrong distros, or am resorting to
Linux for weirder tasks and therefore seeing harder problems. But I don't have
the sense that Linux is more painless, only that it's less chaotic.

~~~
wutbrodo
> Is it really that good these days?

Honestly, I constantly doubt myself on this because other people keep claiming
you need to be some sort of tech-savvy god in order to use Linux: but I've had
various Linux systems as my primary and only OS since 2007 and I pretty much
haven't had any problems to speak of since like, 2012.

To the extent that I can take myself out of my own head and try to model
someone not that tech-savvy, I find Windows _much_ harder to use on a day-to-
day basis. This is further validated by the experience of my dad: I went from
1-2 tech support calls a week to maybe once a YEAR.

> But my experience with Linux is still that when problems do arise, I have to
> escalate to shell commands and arcane sysadmin-ry for all but the simplest
> problems.

I actually prefer the command line for pretty much everything (I haven't
opened a GUI file browser in years), so I'm leaning primarily on the
experience of a few friends/family who switched to Linux when they saw how
awesome my system in college was (where awesome = not plagued with the
ridiculous problems that every Windows user has to rationalize out of
existence). I've tried to evangelize the command line to most of them and they
remain pretty firmly uninterested. And yet none of them ever really _have_ any
problems with their system[1] to speak of: clicking "install now" on the
Update Manager pop-up is the only interaction they have to have with their
system beyond usage. They usually tend to be on something like Linux Mint,
which has all the GUI-heavy config tools pre-installed already. When they feel
like dipping a toe in the water of customization, they can do so to the
precise extent that they're comfortable and think that the trade-off is worth
it (e.g. re-arranging their panel).

AFAICT, all the work in Linux is upfront and pretty quick: make sure that you
buy hardware that supports Linux well (an easy Google search) and either buy
pre-installed or spend 20 minutes installing it.

[1] These include my best friends and girlfriend, people I've talked to almost
literally every day for the last decade.

------
indescions_2017
Great list for starters. But getting real work done requires much more.

Having just walked through some basic steps with a novice, I can concur,
modern linux is impossible without "recipes".

Just setting up a hello world web app can involve: ssh login to running
instance, using curl to download the gcloud sdk, tar to unpack, sudo to
install, systemctl to start local processes, useradd dedicated www, chmod and
chroot to allow access, rsync to tranfer files, netcat to manage ports, etc.

For beginners, without a trusted hand to guide them, its beyond intimidating.
These systems must become more accessible to the average human.

~~~
jmiserez
> _These systems must become more accessible to the average human._

I disagree. Firstly, all the commands you mentioned are pretty simple to
understand given that they have a manpage and lots of help available online.

Secondly, not everything needs to dumbed down for the average user. A large
part of the power comes from all the tools and flags available and the
combination possibilities. Dumbed down tools are limiting and frustrating.

I’d expect any software engineer worth their salt to not be an “average user”
and grasp a few simple commands the same way they approach a new project or
programming language, i.e. they should be able to pick up the basics even if
it’s a complex system. That’s a prerequisite for programming and understanding
a project’s code well anyways.

~~~
eitland
Problem is, as I've already mentioned elsewhere, that the manpages do a pretty
poor job in a number of places.

Yes, I do use them but I guess most Linux users learned most of what they use
from colleagues and Internet, not the official documentation.

~~~
nlawalker
I rarely use `man`. Most of the time I find what I'm looking for with --help,
and if I don't, I end up doing a web search. Sometimes I end up at the HTML
version of a man page, somewhere like linux.die.net, which is much more
comfortable to read than the terminal.

------
davexunit
Learn just enough GNU coreutils and bash to get things done.

~~~
thomastjeffery
Learn enough _literally every modern OS that isn 't Windows_ to get things
done.

------
jheriko
> Basic tasks, like file parsing, job scheduling, and text search are more
> involved than running a command-line utility

This seems backwards. Going to the command line for these things is a horrible
workflow. It’s not necessary in Linuxes either ...

------
nasirmaziz
Another pretentious thought leader spewing misconceptions.

------
nixpulvis
The key is the text stream. Both for computer interaction, and for
communication in general. The rest are just names.

------
alg_fun
This article is about bash and not linux

------
mardiros
Something is wrong.

Quitting is ctrl+d

Ctrl+c is for interrupting the current job.

Some repl like the mysql cli does not rrspect that and it is a PITA

