Determine your BogoMIPS

Yeah, BogoMIPS are bogus, but it's a lot of fun to know how much you have in your computer. Usually you'll find this line to tell you how much you have:

dmesg | grep - 'bogomips'

(or something worse). This is a bad command line because if you happen to have an big uptime (today my uptime is 48 days, which is quite low), this command will not work as most of the kernel's logs have been flushed somewhere else. This is a bad command line because it's not fun at all!
I like dc a little bit, and here's how you can add a lot of numbers using dc:

gniourf@somewhere$ dc <<< '[+]sa[z2!>az2!>b]sb1 2 3 4 5 6 6 5 4 3 2 1lbxp'
42
gniourf@somewhere$ 

Cool eh? Please, read man dc to learn about registers and all that in dc.
To determine your BogoMIPS, you just can do this:

gniourf@somewhere$ dc <<< '[+]sa[z2!>az2!>b]sb'"$(sed -n '/bogomips/Is/.*://p' /proc/cpuinfo)"'lbxp'
10374.47
gniourf@somewhere$

If you want the average BogoMIPS per processor, do:

gniourf@somewhere$ dc <<< '2k[+]sa[z2!>az2!>b]sb'"$(sed -n '/bogomips/Is/.*://p' /proc/cpuinfo)"'zsclbxlc/p'
5187.23
gniourf@somewhere$

I wrote this note because I stumbled by accident on the most terrible command line you could think of. Just for posterity and as an example of something you should never ever do, here it is:

dumbo@moronity$ echo $(echo "print ((($( cat /proc/cpuinfo | grep bogomips | awk '{print $3}' | tr -s '\n' '+')0)/$(echo 4))+($( cat /proc/cpuinfo | grep bogomips | awk '{print $3}' | tr -s '\n' '+')0))/2" | python)

By respect to the author of this junk, I will not give you his name.


Exercise.

1. Count how many pipes, subshells and process forks there are in the previous command line.
2. Count how many Useless Uses of Cats there are.
3. Conclusion? (Hint: look at the login)

Cheers!

True fullscreen for gvim

Note. This note is a rewriting of the 2011/11/11 original. The original worked with gvim<7.3. Now, with version 7.3 we can use a very simple method. Everyone should by now use a recent version of gvim, so I'm rewriting the note with this simple method.

So you're editing your wonderful files, and you feel that you could get more concentrated on what you're doing. In fact you realize there's a lot of junk on your screen that distracts you from this pointer-to-pointer-of-array-of-pointers-of-functions. You only wished gvim could get in full-screen mode!
Well, vim is great, the GUI version (with gtk+) of vim is great (provided you mention set go=aci somewhere in your .gvimrc file to get rid of the gui clutter), but there's no out-of-the-box full-screen mode, as far as I know. No problem, if you're using a smart Window Manager, it will help you: a possible answer to this problem is to use the very nice wmctrl program, that will work provided your Window Manager uses the NetWM standard, which is probably the case if you're using a recent and decent WM on Linux. We'll go along these lines. wmctrl is standard and should be in your distribution package repository. If not, change Linux distribution!
Put the following in your .gvimrc file, and you're done:

function! ToggleFullScreen()
   call system("wmctrl -i -r ".v:windowid." -b toggle,fullscreen")
   redraw
endfunction

nnoremap <M-f> :call ToggleFullScreen()<CR>
inoremap <M-f> <C-\><C-O>:call ToggleFullScreen()<CR>

Now, whenever you're in insert mode or in normal mode, typing Alt-f will toggle full screen mode.

Cheers!

A new bash implementation of ed

You know ed, right? Sure you do, because ed is the standard Unix editor! Last night I was working on a computer that didn't have ed installed, so I quickly wrote a bash implementation. It's not that hard after all! Check it out:

gniourf@somewhere:~$ while ((1)); do read; echo '?'; done

All right, apart from saying stupid things in this note, I'd just like to say that ed can be really cool to format files from a bash script. Most people use sed quite fluently, and are always tempted to solve some problems with it in scripts. ed can be useful because it's the standard Unix editor a genuine text editor after all! In a script you'll use a here document. For example, if you want to change the 40th line of a file named file to hello, gniourf_gniourf you'll probably do:

ed -s file <<EOF
40c
Hello gniourf_gniourf
.
wq
EOF

The -s option so that the sucker remains silent.
If you liked ed, you'll probably also like ex!

Cheers!

What are the groups I don't belong to?

So you're running your nice linux box, and everything is fine. Everything? No. All of a sudden you really wonder what groups you're in. No problem, just issue

gniourf@somewhere:~$ groups

and you'll be okay. Hey, but wait, in fact that was not exactly your question. In fact, after a deep thought, you realize that your question was the opposite! You were wondering what groups you're not in! If you know a little bit of sed, and if you know how the entries of the /etc/group are formatted, you realize that this one-liner will do the job!

gniourf@somewhere:~$ sed "/\b$USER\b/d;s/:.*//" /etc/group | tr \\n ' '; echo

The piped tr is just here because you don't want to have only one group per line, and the echo to have a new line after all this junk.
You could even add an alias in your .bashrc, or make a function, depending on your needs.

Cheers!

In vim, don't use the escape key to go back to normal mode!

No, don't, it really sucks, it makes you move your left hand way too much! Who decided to put this stupid escape key all the way over there anyways? Why aren't all the keys right under my fingers anyways? Who designed the keyboards? Ok, that's enough ranting for today.
So, you don't want to move your left hand to much and you don't have an über stretchable pinky finger to reach that key? Then you'll be glad to learn that you can use Ctrl-[ instead. From vim's help (see :h i_CTRL-[), you'll learn that

<Esc> or CTRL-[
End insert or Replace mode, go back to Normal mode. Finish abbreviation.
Note: If your <Esc> key is hard to hit on your keyboard, train yourself to use CTRL-[.

All right, it's all written there! This just makes me wonder why, when we first learn to use vim, we learn it's the escape key that makes you go back to normal mode... Now you'll be more efficient using vim!
Oh, you can keep on reading :h insert.txt while you're at it!
In fact, it's probably a better idea altogether to remap the stupid CapsLock key to the Escape key in your window manager and use it in vim. It's so comfortable to have this under your left pinky finger!
Another possibility (which is probably better since it's the one I'm using) is to use your window manager to remap your caps lock key to the escape key (but this doesn't work in tty's, so it's good to learn to use Ctrl-[ anyway).

Cheers!

N shaal ivz srngher: ebg13

I know the title is weird. Or is it really? Caesar wanted to send messages to his friends and girlfriends, but didn't want his enemies and Cleopatra to be able to read these messages in case they intercepted them. He came up with a wonderful cipher algorithm, nowadays called rot13.
In this note I just want to briefly talk about an amazing and ever so useful vim feature: yes, vim can encode and decode rot13! Just it can, out of the box! I know you can't believe it, so let me just show you how: The command is (in normal mode) g? followed by a movement. This will encode (or decode) the portion between the cursor and the endpoint defined by the movement.
For example, I have this stupid message to decode:

N shaal ivz srngher: ebg13

and I really want to know what it means. It's probably very important. So I just copy it on a line in vim and then (in normal mode) type g?ip (you know the movement ip, right? if not, try :h v_ip) and I obtain the decoded message!!! It's amazing, and it was really important, indeed!

Purref!

Don't use backticks in bash!

No, don't, it's very ugly. And I don't know how I would read something like this:

gniourf@somewhere:~$ echo `echo `echo hello``

You know, in more modern bash, we use $(...) instead of `...`. So what do you think of the previous line? Which of the following two possibilities is it?

gniourf@somewhere:~$ echo $(echo $(echo hello)) # Possibility 1
gniourf@somewhere:~$ echo $(echo )echo hello$() # Possibility 2

You'll figure it out by yourself, but you probably understand that the $(...) is more robust, since it doesn't leave any ambiguity whatsoever: nestings are neat!

Cheers!

Never parse the output of ls, ps, etc... Use globs or find or something else!

It's all in the title!
So, you want to delete all files that end with .back, and (because you read a terrible advanced bash guide) you're tempted to do this:

gniourf@somewhere:~$ for i in `ls *.back`; do rm $i; done

The problem is that this will miserably fail whenever a filename contains a space. (Try it!). Also, the backticks are ugly (but it's not the worse thing here). Instead, do:

gniourf@somewhere:~$ for i in *.back; do rm "$i"; done

(also observe the quotes). You should realize that bash's globs are infinitely better than parsing the output of a program. If you want to use something like this in a script, maybe you should shopt -s nullglob or shopt -s failglob. For example, try:

gniourf@somewhere:~$ echo *hello # assuming that there's no file ending with hello

The output will be something like:

*hello

Because when a glob doesn't match, it is used verbatim. If you want a non-matching glob to expand to nothing, you must set nullglob on thus:

gniourf@somewhere:~$ shopt -s nullglob

Now,

gniourf@somewhere:~$ echo *hello

outputs nothing.
If you want a non-matching glob to generate an error, you must set failglob on thus:

gniourf@somehwere:~$ shopt -s failglob

Now,

gniourf@somewhere:~$ echo *hello
bash: no match: *hello

Cheers!

Welcome to gniourf_gniourf's blog!

All right, this is the very first post ever. Nice, eh?