Command breakdown / ps aux | grep gedit explained

Breakdown of "ps aux | grep gedit"

'ps' is the actual program/application

'aux' is actually a set of three flags, a, u, and x. You could order them any way you want, such as "xua", but since "aux" is the most pronounceable (like the word "auxiliary", pronounce "awks" or "awgs", or just "a-u-x"), it's easier to remember it that way.

You could also write it as "ps xua" (or other variants), "ps -aux", or "ps -a -u -x". But since ps is one of those awesome programs that lets you put flags without the dash (another such program is tar, e.g. "tar xf file.tar.gz", which will extract any tar file, whether it's .tar, .tgz, .tar.gz, .tar.xz, or .tar.bz2. Go ahead and try it next time you wind up with a tar file on a linux system), "ps aux" is the nicest choice. Remember that, too; whenever you see a command like "df -h -i -u -o -v" (df is a real command, but half of those flags are made-up. You can expect h (human-readable) and v (verbose output) to work, though), you can combine all the flags together into a "flag clump", the following command is equivalent: "df -hiuov"

From the man page:

a: select all processes.

x: something about a "BSD-style must-have-tty restriction" (tty is TeleTYpe, or the "fresh install of arch linux terminal" I was talking about earlier. Access via Ctrl+Alt+F[1-6], get back to GUI via Ctrl+Alt+F7, sometimes F8), so I take it this flag is just use to prevent errors on weird/idiosyncratic systems.

u: select by user id, rather than weird stuff like daemons and terminals. I'm not completely sure what this does, actually, or why not including it will fail to bring up gedit's process.

'|' is a pipe. It's used to redirect output to input, so you can chain commands together in neat ways.

In this case, the output of 'ps aux' is being redirected to the program, grep. Grep's name is funny. It comes from an old perl expression used commonly to search for text using regular expressions, and print it out. That is, g/[re]/p, where g means "global", re means "regex", and p means "print".

This actually works in vim. You initiate like a normal command, via ':'. Type in some gibberish like "dfggsdkljdhfl" on multiple lines, then include one or two lines that say something coherent, like "hello" on one line and "hallo" on the other, and then, from normal mode, enter :g/h.llo/p

You will get the following or similar output:
:g/h.llo/p
6 hello
8 hallo

So now you can start to see how grep works. Grep is a whole lot simpler, though. Because this use of regex was so common, someone decided to just make a program that does it by default, and thus the name is grep. You could also just remember it by mentally linking it to that one episode of Game Grumps, when Arin randomly says "next time on grep", and then Barry draws a title card for it after Jon laughs about it. That's strangely how I remember it.

Anyways, the use of grep is as follows:

$ grep regex file

Where file is the file you want to rummage through, and regex is the search term, or regular expression, that you want to find in the file. Grep is neat because in addition to finding and printing each (and only) line, it highlights the match found in red.

That's all well and good, except nobody ever uses grep like this. Even I forgot the order of the arguments and had to guess in the terminal to make sure it was right (it wasn't, which is why file is explained first in the description--I was too lazy to reorder the description). The way most people use grep is in a pipe. some command or output | grep regex.

And that's where 'gedit' comes in. It's the search term.

So here's some actual output of that whole line (ps aux | grep text , since my current system doesn't have gedit, but scratch instead)

$ ps aux | grep text
braden    4876  0.0  0.9 157328 18064 ?        Sl   09:50   0:01 scratch-*text*-editor
braden    5434  0.0  0.0   4412   784 pts/8    R+   10:43   0:00 grep --color=auto *text*

As you can see, the pid of scratch-text-editor (although I was using gedit as an example, it was actually scratch) is 4876, so you could do some interesting stuff with that, like '$ kill -s STOP 4876' to freeze it, and the same command but with CONT instead of STOP to unfreeze it.

Also, the attentive reader will know from the above output that I currently have a lot of terminals open. At least eight of them. Can you guess where that information is?