Linux for Dummies

July 5, 2023 6:53 PM

I have to edit instructions that contain Linux commands but I haven't worked with Linux in my life. What's the best way to get up to speed?

My experience with Linux extends to using LibreOffice because I'm too cheap to buy a Word license. I'm editing instructions that involve installing scripts, moving files, and comparing language and I'd like to add some more value than checking spelling and formatting, but if I don't understand exactly what's going on myself, I can't describe the process to the user. What's the best way to get some rudimentary Linux knowledge so I can "translate" these instructions to myself in my mind? Ideally I'd be able to just play around with a Linux machine so I can figure out what's going on, but I probably shouldn't do that on my actual work hours or at least my actual work machine.

posted by kingdead to Computers & Internet (16 answers total)

One thing you can do is, if they are not proprietary, feed the text into chatGPY and ask it to give you an explanation of what is going on. I have found it pretty good at this, it explains it well. You can then ask how to change it to add or change functionality and it can do that too, but you would need to learn to run and test the changes to make sure that they were correct.
posted by procrastination at 7:16 PM on July 5, 2023 [1 favorite]

You very likely can play around with Linux on a random Windows machine, thanks to WSL. Install a virtual Linux environment, dink around in it, then make it go away.

For trying to parse an arbitrary shell command, give explain shell a try.

Bite Size Command Line and Bite Size Linux are two adorable zines for introducing folks to important concepts.
posted by zamboni at 7:43 PM on July 5, 2023 [11 favorites]

Well, tomorrow at work I'm scheduled to attend a meeting where we're going to take a vendor's instructions on how to setup ODBC on a Linux server to talk to an MS-SQL database on a Windows server. I expect this to be a difficult meeting even though I have about 15 years of off and on Linux experience. I have also been tasked in the past with providing documentation of existing Linux setup instructions for others since I'll be retiring soon. I'm not trying to discourage you, it's just that Linux is dense.

Ideally you'd use a VM or an old junk PC with Linux installed. Keep in mind that you need to know what shell language is in use, which can (although not usually) vary by what scripts are being run (ksh, zsh, Bash, etc.) Realize that Linux is case sensitive. It is also not forgiving and expects you to know if you are targeting a file or a directory. Scripts may not run if they do not have the proper file permissions or are not on the path (e.g., $PATH environment variable). Since you are "installing" there probably will be a need to drop into "the root" user. When doing it is much easier to destroy things. Conversely, things created while root may end up being owned by root and then not usable unless you also change their ownership and file permissions (chown and chmod) to what you really want before leaving root. I have also found creating/removing symbolic or hard links to be unforgiving of typos. In general you can do "man command" to find out details about a command, including the MANY switches which may be used to control their execution. If you are installing something you may need to extract the software from within a tgz (zipped tar ball) into some directory.

As I said my experience has been intermittent for 15 years, so I am not an expert, just somewhat experienced. If someone posts after me with better/simpler advice then please disregard this.
posted by forthright at 7:44 PM on July 5, 2023

I'm editing instructions that involve installing scripts, moving files, and comparing language and I'd like to add some more value than checking spelling and formatting

I'd like to know a bit more about the instructions. Are they instructions for entering things into the terminal? Do they look like?:

computer@computer:~/home mkdir TestFolder
computer@computer:~/home cd TestFolder
computer@computer:~/home/TestFolder touch file.txt

If some look like this, they're shell commands which are very well documented in what they do. If I search "bash cheat sheet", the first result I get is this page, which appears broadly accurate to me even though the site is trying to sell me something or other.
posted by solarion at 9:32 PM on July 5, 2023 [1 favorite]

Technically speaking any "Linux commands" are shell commands, and let's just say there are more than one shell available for Linux, much like you can get replacement command.com for DOS (and indeed, Microsoft themselves made Powershell, which has a bunch of admin-level stuff that can change registry, interact with Windows, and more). But most likely you'll see bash shell (which is a GNU replacement for Bourne shell). Allegedly it stands for Bourne Again Shell, hahaha. But there are plenty of others, like C shell, tcsh, zsh. But the differences among them are practically minutiae that doesn't really matter in actual operations.

I agree, the best way is to run WSL and see for yourself, or even do a bootable Linux environment on a USB drive. A lot of the rescue disks are basically Bootable Linux with a GUI.
posted by kschang at 10:05 PM on July 5, 2023 [1 favorite]

Yes, you need a Linux environment to test. You can put Linux on a USB thumb drive and boot to it on a PC.
posted by theora55 at 11:09 PM on July 5, 2023 [3 favorites]

If you have a Windows machine you can likely enable HyperV (free, part of your OS licence) and use a virtual machine on your laptop. HyperV was surprisingly helpful installing an Ubuntu VM when I used it a couple of days ago, though it will pull 2+GB from the internet while it does it. With modern data caps that is not the end of the world, but it isn't fast.

If you're on a Mac or you find HyperV won't work for you virtualbox will also do the job.

When you've created it take a checkpoint. You can always roll back to that checkpoint and try again, useful if the instructions are for installing something.
posted by How much is that froggie in the window at 12:10 AM on July 6, 2023

This is the tutorial I followed for installing Debian inside Windows box using WSL2 last time I needed to use some Linux tools on a Windows box.

The version of Debian you get after following those instructions doesn't include any GUI support by default, and is good for messing about with command line stuff. You can install graphical packages using Debian's own inbuilt package manager afterwards, if you want.

The entire Debian file tree ends up in its own subfolder from Windows's point of view (the C: drive can be made to appear inside that tree, but doesn't by default) so you won't mess up your Windows installation by fooling about with the Debian command line.
posted by flabdablet at 2:13 AM on July 6, 2023 [1 favorite]

I'd suggest some reading. Then set up a basic virtual machine, or find one you can use remotely on the Internet. (Not some Windows compatibility layer.) The cheapest shared-hosting account on Linode is $5/mo ($0.0075 hour).

In The Beginning Was the Command Line (by Neal Stephenson, you can get it in bound form too)

The Linux Users Guide (2019 edition) - chapter 4 talks about the shell

The Art of Unix Programming - note that Eric Raymond is a dick, but this still has good material on the 'Unix way.' I'd say skim the intro ("I. Context") with a focus on "3. Contrasts," and the second part ("II. Design") with a focus on "5. Textuality."


The other thing to do would be to find Linux tutorials from learn-to-code sites, they usually have a module that teaches the basics — enough to set up a basic development or server environment, configure Git and etc. Or search youtube for tutorials.

Here's one on how to install VirtualBox and Ubuntu on Windows.

If you want a physical book, the one to buy is the UNIX and Linux System Administration Handbook.
posted by snuffleupagus at 4:40 AM on July 6, 2023 [1 favorite]

Best answer: The Linux Command Line by William Shotts — either physically from No Starch Press, or as a free download from the first link — is the best intro to command line work I've seen so far. It doesn't condescend, it doesn't get too heavily into commands you're unlikely to use, and the author is responsive to comments and updates the book frequently.

> … I probably shouldn't do that on my actual work hours

If this is required for your work, then you absolutely should do it in work hours.
posted by scruss at 5:28 AM on July 6, 2023 [8 favorites]

No need for virtualbox on Windows. You can easily install an Ubuntu VM using HyperV in Windows (HyperV comes 'in the box' with Win 10 and 11). Or use WSL.
posted by Jessica Savitch's Coke Spoon at 5:50 AM on July 6, 2023 [1 favorite]

Righty-ho. Installing Ubuntu using HyperV on Win10 Pro. (Not in the Home edition.)
posted by snuffleupagus at 6:04 AM on July 6, 2023 [1 favorite]

There are a number of free systems that one can get an account, log on and run any basic unix command. Setting up a specific environment, you said "install scripts" ranges from trivial to really hard.

https://sdf.org/
https://tilde.club/
https://tildeverse.org/members/ (big list of systems)
AWS and Oracle have a "free tier" where you can stand up a system and do anything within some broad limits.

There are a huge number of free and very cheap linux virtual servers available on the internet.
posted by sammyo at 7:28 AM on July 6, 2023

I agree that you should test the commands out in an actual shell environment (use whatever is simplest to set up, whether it's WSL or a VM or something else), and that this is a perfectly reasonable thing to do during working hours if you're doing it for work. I would in fact suggest (at work) that access to such an environment is a requirement for you to do this work effectively, and find out if you can get an IT person more familiar with Linux to set it up for you (ensuring that it has the correct specifications), so that you can dive right in.

For this use case it may be best to use some kind of barebones virtual environment that you can repeatedly destroy and restore to its pristine original state (a VM, a docker container, etc.,) -- that way, you can repeat the instructions from scratch whenever you correct something and be sure that they're not being affected by things that you changed previously.

Please don't attempt to use a chatbot to explain code to you. You will have literally no way of knowing when it's correct and when it's making up complete bullshit (it's going to make up complete bullshit).

I would like to add that someone with zero to little familiarity with a system is often the ideal person to test technical documentation which is supposed to be a complete step-by-step guide. Documentation can get out of date, or it can skip steps which seem "obvious" to everyone more experienced. More experienced proofreaders will completely fail to see these problems because they're "obvious". It takes someone for whom it's not obvious at all to notice that a step is missing, or the behaviour of a particular command has changed in recent versions, etc..
posted by confluency at 9:41 AM on July 6, 2023 [3 favorites]

For a given line, you could try explainshell.
posted by Pronoiac at 6:18 PM on July 6, 2023 [1 favorite]

If you're familiar with Windows command line prompts, SS64 is a great reference. Look up commands you know (or don't know) for explanation and examples. Scroll to bottom and look at "Related Commands" to find equivalents or similar in other shell environments.
posted by caution live frogs at 1:36 PM on July 7, 2023 [1 favorite]