commandliners

Hi there,
First things first: Happy New Year! :)
One task I usually perform when I am writing code is grepping the code for a certain string. In order to do that, I used to exit Vim (either with :q or suspending the process), grep the files and then go back to my Vim session. This approximation has one main drawback: I usually don’t remember all the matches reported by grep.
Vim provides a mechanism for invoking grep from a Vim session. The command is:

:grep string files

This way, one can invoke his local grep command and the results will be integrated into the error list, the one we wrote about in compilation errors. This way, one can move through the matching list using both :cp and :cn
We can instruct Vim to use another grep program by setting the grepprg variable.

Just Normalize. Assume file.txt is a list of unicode words, then

cat file.txt | perl -e 'use Unicode::Normalize; my @w ;\
while (<>) {chomp; push @w, $_;} ; @w = sort {NFD($a) cmp NFD($b) } @w ;\
print(join("\n", @w))'

will output the sorted list (well, sorted according to the NFD normalization, which for Spanish is enough).

shar(1) is a FreeBSD base system utility for creating shell archives that is, a kind of self-extracting archive of a hierarchy of files and directories. The archive will recreate the file hierarchy specified at creation time. It is fast and the result is easy to handle as the shell archive is a text file (good to email a file hierarchy).

To create a shell archive:

$ shar `find my_directory` > my_hierarchy.shar

To recreate the hierarchy:

$ sh my_hierarchy.shar

That is, shar is a simpler version of ar and tar.

Enjoy!

Nowadays almost all the computers have a 64-bit CPU, but sometimes we are logged in on a remote server and do not know what kind of CPU it has and we need to know it to install a package or… out of mere curiosity.

In those cases we can run the following command:

$ grep --color lm /proc/cpuinfo
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts
acpi mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc up ida nonstop_tsc arat pni
ssse3 cx16 sse4_1 sse4_2 popcnt lahf_lm 

If the lm flag is present (i.e. if there is any output to the grep command), then the CPU is 64-bit. lm means long mode (64 bit extension).

I did not know that rsync had the resume capability till last week when I had to transfer almost 200GB between two servers with no good connection. I think some context is needed here: My company has two servers in two different cities where the backups are stored. There is a daily syncronization between the backup tree between the servers. That is, a cron task that calls a script that basically runs rsync.

Due to the bad connection, I have had to add the -P option to the rsync command so that the command run by the cron task is:

$ rsync -rPtz -e ssh /local_backup_path/ remote_host:/remote_backup_path/

The -e ssh tells rsync to use a ssh client instead of rsh. The -z option compresses the file. -t preserves time attributes and the -P option resumes incomplete file transfers.

If you run this command from the command line you can use the --progress option, that will show you a progress bar during transfer. Very useful with large files.

I hope this saves you some time ;)

mixer(8) is a FreeBSD base system utility for setting and displaying sound card mixer levels. It resembles the Linux’s command line utility alsamixer. Invoked with no parameters it shows the current values of the mixer devices:

$ mixer
Mixer vol      is currently set to  85:85
Mixer pcm      is currently set to  75:75
Mixer speaker  is currently set to  75:75
Mixer mic      is currently set to   0:0
Mixer mix      is currently set to   0:0
Mixer rec      is currently set to  75:75
Mixer igain    is currently set to  75:75
Mixer monitor  is currently set to  75:75
Recording source: mic

Setting specific values is easy enough:

$ mixer rec 80:80
Setting the mixer rec from 75:75 to 80:80.

Enjoy!

Sometimes, when I have to program a web service client I have to deal with unformatted XML files. For example, the next one:

<users><user><email>pfortuny@commandliners.com</email><passwd>a0f901492d89fe2ba88cc96bf9d
2475e</passwd></user><user><email>n0str0m0@commandliners.com</email><passwd>7e1b6dbfa824d
5d114e96981cededd00</passwd></user><user><email>rafacas@commandliners.com</email><passwd>
70c1db56f301c9e337b0099bd4174b28</passwd></user></users>

This is not a bad thing, because it is sent that way to save traffic, but I’d rather see it in a human readable format. So I use the xmllint command, that reformat and reindent the input.

$ xmllint --format test.xml
<?xml version="1.0"?>
<users>
  <user>
    <email>pfortuny@commandliners.com</email>
    <passwd>a0f901492d89fe2ba88cc96bf9d2475e</passwd>
  </user>
  <user>
    <email>n0str0m0@commandliners.com</email>
    <passwd>7e1b6dbfa824d5d114e96981cededd00</passwd>
  </user>
  <user>
    <email>rafacas@commandliners.com</email>
    <passwd>70c1db56f301c9e337b0099bd4174b28</passwd>
  </user>
</users> 

The indentation can be controlled by the environment variable XMLLINT_INDENT. The default value is two spaces.

pfortuny, n0str0m0, do not worry guys, those are not your passwords, are they? ;)

After creating an XML document from scratch I always check if it is well-formed. This means it must adhere to a number of rules, including the following:

1. Every start-tag must have a matching end-tag.
2. Elements may nest, but may not overlap.
3. There must be exactly one root element.
4. Attribute values must be quoted.
5. An element may not have two attributes with the same name.

This is not an exhaustive list and I do not mean to explain all the rules. There are many, many ways a document can be malformed. But if you need to determine if and XML document is well-formed there is a linux command for doing that: xmlwf

$xmlwf test.xml

If there is no output, the document is well-formed. If it is not, the output will show you where the problem is:

$ xmlwf test.xml
test.xml:4:38: mismatched tag

For more info man xmlwf