"terminal Fear"

Grench said:
Tor said:
.. just don't try the atomicthumbs command and you'll be fine.

I'm still such a noob...

Doesn't that say he's going to concatenate the data stored in RAM to the first partition on the first disk but not to a named file? That doesn't make much sense...?
I'm replying to this older post because I think this is a good point to explain another bit of Unix basics.

First comes a bit of a tangent, some info about cat. cat really does concatenate things; the following line would print the contents of 1.txt, 2.txt and 3.txt concatenated:
cat 1.txt 2.txt 3.txt
However, cat is also the single most abused Unix command. Why? Because it's often used to simply print or redirect a file's contents without concatenating anything. So cat /dev/mem > FOO means that I want the contents of /dev/mem put into FOO.

Now let's take a look at /dev/sda1. In Unix (and Linux is a Unix clone) pretty much everything is a file. Your hard drive? A file. Each partition on that hard drive? A file. Other things that are files are your RAM, your mouse and even abstract things like two different pseudorandom number generators and a bunch of info about your system.

Everything in /dev is a device. You typically don't want to directly mess with the things in here; while the file representing your hard drive is here, the file system is somewhere else. You can, however, open (for example) /dev/sda1¹ in a hex editor and look at the raw partition data as it is stored on your hard drive. You can even write to it and this can be useful in an emergency when you really know what you're doing. I once saved data off a hard drive I couldn't cleanly mount anymore by getting an identical replacement and using an error-resistant bit-precise copying program to directly move data from the old hard disk to the new one.
It's still a phantastically easy way of losing all your data, though, and I wouldn't muck around with /dev/sd?? unless neccessary.

So the command atomicthumbs gave means "take the contents of the RAM and overwrite the beginning of the first partition of the first SATA drive with them". Contrary to what Rathum wrote, this doesn't neccessarily destroy your OS. Just usually. This is simply because while you can run Linux from just about any partition you feel like, most people will have it on sda1.

Oh, and do stay away from fork bombs. Those will just freeze your system but they're still annoying and Linux isn't meant to be cold-rebooted (just like modern Windows). If something looks like a random string of special characters, be suspicious.

¹ the "sda1" means:
sd = SCSI disk, also used for SATA and USB devices
a = first disk of such type; the second one would be sdb, then sdc and so on
1 = first partition

So for a disk with two partitions you'd see the following files:
/dev/sda - the disk itself
/dev/sda1 - the first partition
/dev/sda2 - the second partition
Last edited by a moderator:
Rathum said:
Also, ctrl+shift+v is paste.
Or middle-click. (much easier for me at least; not so much on the Pandora)

Oh, another fun one is "a(){a|a&};a" aka the fork bomb. You need a lot of cores or good system policies to prevent that one from crashing your system.

Then, a quick and painless death to your computer: "mv /* /dev/null" (much faster than "rm -rf ...")
Last edited by a moderator:
j6cubic said:
So the command atomicthumbs gave means "take the contents of the RAM and overwrite the beginning of the first partition of the first SATA drive with them". Contrary to what Rathum wrote, this doesn't neccessarily destroy your OS. Just usually. This is simply because while you can run Linux from just about any partition you feel like, most people will have it on sda1.


I actually worded that a bit wrong, but my excuse was I somehow got my keyboard to randomly output spaces so I was typing fast (I forget whether or not I did a cat > to anything...).

Another tip for linux newbies:
Split your file system into different partitions. This may not be an issue on the Pandora, but it will save you a lot of headaches over time on other systems. Linux will allow you to mount different partitions as directories in your filesystem. The minimum you should do is have "/home" on a separate partition from "/". This will let you keep all your personal data and config files for programs when you have to do a reinstall (I don't care who you are, but you will end up reinstalling your OS eventually). I do the same thing on Windows, but it isn't as convenient. Since I installed linux on my laptop, I have done a complete OS wipe about 10 times and I still have intact data from when I got it.

My laptop is divided into four partitions (smaller hard drives mean less room to grow if you split into a ton of partitions).
I have sda1 as my Windows partition and it's set to mount as "/windows". I gave it about 40GiB initially, but I boosted it to 60GiB to install more programs.
sda2 is where I put all my files and is mounted at "/home". It was 185ish GiB initially, but it's down to 160GiB to increase my other partitions.
sda3 is my swap partition. It's at 3GiB currently, but I've never seen it use anywhere near that much.
sda4 is my actual filesystem and OS that mounts at "/".

gparted is an excellent partitioning tool that can be run from a LiveCD or LiveUSB to let you partition your drives easily.
http://www.fs-driver.org/index.html will let you use ext2 or ext3 filesystems from Windows. Some limitations apply, but it works. I can't seem to grant administrative rights to programs running from my "/home" directory, however.
Last edited by a moderator:
j6cubic said:
Oh, and do stay away from fork bombs. Those will just freeze your system but they're still annoying and Linux isn't meant to be cold-rebooted (just like modern Windows). If something looks like a random string of special characters, be suspicious.
Fork bomb:
 :( ){ :|:& };:
On the other hand, a random string of characters could also indicate the presence of a regular expression. :p
Last edited by a moderator:
Tom` said:
Fork bomb:
 :( ){:|:&};:
On the other hand, a random string of characters could also indicate the presence of a regular expression. :p
Aww, they look like smiley faces! Run little smileys, run! wait, what's a fork bo<disconnected>
Last edited by a moderator:
Just wanted to add that while i agree and manpages are mostly an incomprehensible waste of time (google IS your friend), many commands have a useful help trigger (often -h or --help) which should give a nice idea of syntax.
Rathum said:
Another tip for linux newbies:
Split your file system into different partitions.

Linux makes it fairly easy to do some nifty things. I once had /boot (guess what that does) on a CF card in a CF-to-IDE adapter. Why? That way I could just remove the card, rendering the computer unbootable. Well, unless the attacker used such devious tools as a live CD. I actually just did it because I could.

Essentially you can take any part of the filesystem and just put it on another partition (save things like /dev or /proc which already are special partition-less filesystems). As long as you keep the programs needed to mount filesystems on the root partition you're good.

As for manpages (in case it hasn't been mentioned, they're accessible through man <command>): They're a mixed bag. Usually the problem is that they explain the entire command while you just want one particular piece of information. grep is your friend if you're looking for something specific. grep does a regular expression search on its input. Sounds complicated but can be very easy: Essentially, grep is given one parameter and searches its input (either coming through a pipe (see below) or a second parameter pointing to a file) for that. Everything else is just fancy stuff.

Note: I worked out this example on an OS X box, which is similar but not quite identical to Linux. So don't be scared if you try it on Linux and the text is different. The basic functionality of grep is still the same.
Also note: The code blocks show what happens on the shell. Lines that start with a $ denote me typing something and everything else is what the computer says – this is a usual Unix convention (unless you're root (= the superuser), in which case # replaces $).

Let's say you want to find out what cp -a does that cp doesn't. You could use cp --help...
$ cp --help
cp: illegal option -- -
usage: cp [-R [-H | -L | -P]] [-fi | -n] [-apvX] source_file target_file
       cp [-R [-H | -L | -P]] [-fi | -n] [-apvX] source_file ... target_directory
...but that doesn't give you greater insight. You could look through the manpage but that takes time. Or you take the manpage and feed it to grep, like this:
$ man cp | grep -- -a
     cp [-R [-H | -L | -P]] [-fi | -n] [-apvX] source_file target_file
     cp [-R [-H | -L | -P]] [-fi | -n] [-apvX] source_file ...
     -a    Same as -pPR options. Preserves structure and attributes of files
Okay, let's go through this step by step. We first called man cp. The vertical bar, or pipe, following that means that we take its output and, instead of displaying it, pipe it through to the command following the pipe, grep -- -a.
Now what does the double dash mean? Well, we need to tell grep that the "-a" I just gave it is the string it's supposed to look for and not a switch. Double dashes mean "everything after here is not a special parameter but just a string". So now grep gets fed the manpage, looks through it for occurrences of "-a" and gives you just the lines matching that.

Now you know that cp -a preserves file attributes, which cp normally doesn't.

Another nice thing about grep and the command line is that it allows you to quickly look through many text files. For example, I have accumulated 87 megabytes of IRC logs in about thirty files. If I want to find out when someone has said something I can just do grep something ~/.xchat2/xchatlogs/* and all files in XChat's log folder are searched. Takes about three seconds if I get hundreds of matches and much less than half a second if I only get a few. grep even tells me which file each line is in.

Oh yeah; you'll encounter lots of paths that start with ~. That's a shorthand for your home directory. Most Linux programs store their data in hidden directories in there – that's what the dot in ".xchat2" is for: In Unix any file that starts with a dot is hidden.

I get the feeling we might be overwhelming the Linux newbies a bit. Maybe I should hold back with my trivia avalanche...
Last edited by a moderator:
mindlord said:
All all of that is why you should trust your source. Just like Windows users should never "format -U -Q" or "deltree Windows" etc.
Some might say that these are the best things you could do to a windows box. :D
Last edited by a moderator:
mindlord said:
Can you Alt-Ctrl-F1 on the Pandora? Is it Alt-Ctrl-Fn-1? Does that even work?
It's easy enough to set it up yourself if it doesn't do that already. Well, if the kernel has been compiled with virtual console support at least, because then it's just a matter of setting up getty or mingetty listeners (in e.g. /etc/inittab) on some additional consoles.
Someone else said the kbd could to 3 keys at the time so that shouldn't be a problem either (and I would be surprised if it couldn't - the N900 can do them).
Last edited by a moderator:
Hmm, how about wireless from the command line (assuming wlan0 is your wireless):

  • log in as root
  • Code:
    ifconfig wlan0 up
  • Code:
    cp /etc/wpa_supplicant.conf /etc/wpa_supplicant.conf.back
  • Edit your wpa_supplicatnt.conf to remove all but one 'network' block (or leave a couple if you're going to connect to more than one network)
  • Edit that 'network' block with the appropriate information for your router then save and exit the file
  • Code:
    iwconfig wlan0 essid <ssid>
  • Code:
    wpa_supplicant -Dwext -iwlan0 -c/etc/wpa_supplicant.conf -B
  • Code:
    iwconfig wlan0
  • verify that the SSID is <Your Router>
  • wait 10 seconds
  • Code:
    dhcpcd wlan0
  • Code:
    and see if the wlan0 entry has a valid ip address
  • Code:
    to log off of root
See how easy that was? :p
(I encourage nobody to try this. Although it should eventually work, it may require hours of frustration with little explanation of why things are not working. I recently talked my friend through this over the phone and it took about 3 hours all together, and that was after I had already spent a couple of hours setting it up on a different network to make sure it was working.)

And just to reassure the noobs who may have read this and then started to think ohhh this is what I'm scared of, I don't even want to learn the basics, or type any off this stuff.
Like what the OP said, 9 times out of 10 shouldn't need to open up a terminal window! (Even if sometimes it may actually be easier to do something) ;)
9 times out of 10 you don't need the terminal window – but once you've gotten used to it, 9 times out of 10 you do open the terminal window it's for something like moving or renaming files.
Yea, my above post was half-joking. Yes, it's really complicated, and way too much for a beginner. But, I was able to talk my friend through it, and he has had very little interaction with the Linux shell. (I was helping him set up a server, we didn't want to run X on it, and he only has wifi access in his apt.)

I posted it because it's handy to know, and up until this weekend, I'd never needed to do it. Also, setting up wifi from the command line is not an easy task, so for a few people it might be good to file away.

I think it has been over a month ago that ED announced that the wireless had a working UI, so it's really very unlikely that this will be necessary.
Ok, how bout some text editor help. I use vim a lot, I don't know emacs or anything else that well. For those who don't know, vi is a text editor that has two modes, there is the insert mode and then command mode. In insert mode, you can enter text and it will act like a normal text editor. In command mode, it will do functions like cut, copy, paste, search, save, quit, etc. I like it because it's a powerful little editor that is installed by default on almost any Linux distro. It's also great for writing code. Here's a couple of hints on using vi (or vim):

i - insert mode, needed to start putting text into your file
[esc] - escape, stops insert mode or other action

When not in edit mode:
/<search term> - search through your file for a search term
n - find next match
N - find previous match
yy - copy line
2yy - copy two lines
p - paste (line or other)
dd - cut line (p will paste it)
x - cut character (use this instead of backspace!)
10x - cut ten characters
:w - write/save
:w <new name> - save as <new name>
:q - quit
:q! - quit without making any changes
:wq - write, then quit
k - up (when not in edit mode)
j - down
h - left
l - right
b - jump to beginning of word
e - jump to end of word
gg - jump to top of file
G - jump to bttom of file
:23 - jump to line 23 of file
If you find vi too cryptic and/or have ever used the old MS-DOS EDIT.EXE I recommend nano. Essentially the least powerful but most approachable of the usual Linux text-mode text editors. Most distros have it installed by default (in fact most distros ship vi, nano and emacs, covering all bases).
On the subject of man pages, yes, they're sometimes cryptic and a little verbose, but then again, they're a manual. Just like your lawnmower manual has 4 pages on the bagging attachment you never use, and sparkplug specs you'll use once every 3 years, and oil viscosity charts that may baffle the casual landscaper, man pages usually contain a lot of useful information. The --help switch is usually better for everyday use (think of it like a quick-start guide), but reading through the manpage -- really reading it, not just skimming through -- on some of the more common commands can yield all kinds of useful nuggets.

I'd say a bigger complaint is that some man pages are vague or incomplete, in which case google is a great fallback.

As an alternative to grepping your man pages, might I suggest using less?

man grep | less

Of course, many implementations of man do this automagically. In any event, once you're in the lessed output, you can search by typing '/<search term>'; in our grep example above, try typing '/extended' and hitting enter. You can then hit 'n' to find subsequent instances of a previous search term. This approach is great for getting not just the term you're searching, but also it's context. Of course, 'grep -C' is good for this, too, but I figure you can check the man page for more on that. :p

One last thing -- I had a great object lesson in the 'trust, but verify' mentality recently when I was looking for the command to add a user to a group. I found it in an Ubuntu wiki posting as 'usermod -G <group> <user>' which looks close enough to right until you run it. Then you remember it should be 'usermod -aG <group> <user>' and you've just wiped out all group memberships for that user. And it's your only login on that box with sudo access. Time to boot into single-user mode and fix it. Luckily, your years of work in systems administration have hardened you, and you know you have a daily backup of /etc/group on every machine you've ever owned, and, wait, what? Backups? Crap.

So yeah, even crusty old command-line veterans sometimes need to slow down and do some additional research before executing commands they find, even commands they've used in the past that are posted on a supposedly trusted source.