levlaz

Posts tagged: gnu

The Best Autotools tutorial from the Ajunta docs

2017-05-11 19:15:02 ][ Tags: hacking gnu autotools

Autotools is probably the most overwhelming piece of software that I have encountered. Just when I think that I get how it works, something goes wrong and I spend hours digging through man pages and info docs trying to figure out what is going on.

I wish I had found the Anjuta docs that describe how the "magic" behind their project wizards actually work earlier. Like most IDE's Anjuta takes care of doing a lot of heavy lifting in the background. Unlike most IDE's they have excellent documentation (in addition to the source code of course) on how everything actually works. This is extremely valuable and I am grateful to the folks from the Anjuta project who took the time to describe how all of this works from doing everything as a single line gcc command all the way to clicking buttons via the new project wizard.

If you are new to autotools like me, check out this doc. If you dont care about auto tools but want to see what excellent documentation looks like, check out this doc as well.

Anjuta "You must have libtool installed"

2017-05-09 18:35:00 ][ Tags: debian gnu

Anjuta is an excellent IDE specifically when it comes to writing applications for GNOME. On Debian stable, there seems to be a bug having to do with a missing dependency. When you create a project for the first time using the new project wizard and then try to execute it; Anjuta will complain that you must have libtool installed. I already have libtool installed, but it is looking specifically for some tools found in the libtool-bin package. Installing this package resolves the issue.

sudo apt-get install libtool-bin

Reading gz files with zcat

2017-05-04 23:15:44 ][ Tags: hacking gnu terminal

The Debian Policy Manual dictates that all packages should come with documentation. In order to save space in the debian archive these documents need to be compressed with gzip. There are a ton of these files floating around in the /usr/share/doc directory. Recently I wanted to read some of the documentation. If you try to open the file with cat it spits out binary gibberish. You can of course unzip the file as you normally would and open it up that way, but it turns out there is an easier way. Using zcat you can read the contents of compressed files just like you would with cat.

zcat is identical to gunzip -c. (On some systems, zcat may be installed as gzcat to preserve the original link to compress.) zcat uncompresses either a list of files on the command line or its standard input and writes the uncompressed data on standard output. zcat will uncompress files that have the correct magic number whether they have a .gz suffix or not. GZIP(1) man page.

By default, this will put all of the output into your terminal window, which is fine for most files. The other place where this can come in handy is when you are trying to look through compressed log files. In this case, having to scroll around the terminal may not be a great option. You can pipe the output of zcat into other programs such as less in order to be able to page through long files. For example, if I wanted to read the first 10 lines of a compressed log file, I could do so with the following command:

levlaz@debvm:/var/log$ sudo zcat syslog.2.gz | head -n 10

The output of this command would look like this:

May  2 22:27:43 debvm rsyslogd: [origin software="rsyslogd" swVersion="8.4.2" x-pid="585" x-info="http://www.rsyslog.com"] start
May  2 22:27:43 debvm kernel: [    0.000000] ACPI: LAPIC_NMI (acpi_id[0x1a] high edge lint[0x1])
May  2 22:27:43 debvm kernel: [    0.000000] ACPI: LAPIC_NMI (acpi_id[0x1b] high edge lint[0x1])
May  2 22:27:43 debvm kernel: [    0.000000] ACPI: LAPIC_NMI (acpi_id[0x1c] high edge lint[0x1])
May  2 22:27:43 debvm kernel: [    0.000000] ACPI: LAPIC_NMI (acpi_id[0x1d] high edge lint[0x1])
May  2 22:27:43 debvm kernel: [    0.000000] ACPI: LAPIC_NMI (acpi_id[0x1e] high edge lint[0x1])
May  2 22:27:43 debvm kernel: [    0.000000] ACPI: LAPIC_NMI (acpi_id[0x1f] high edge lint[0x1])
May  2 22:27:43 debvm kernel: [    0.000000] ACPI: LAPIC_NMI (acpi_id[0x20] high edge lint[0x1])
May  2 22:27:43 debvm kernel: [    0.000000] ACPI: LAPIC_NMI (acpi_id[0x21] high edge lint[0x1])
May  2 22:27:43 debvm kernel: [    0.000000] ACPI: LAPIC_NMI (acpi_id[0x22] high edge lint[0x1])

Don't forget the -i

2017-04-19 12:00:46 ][ Tags: gnu

I spent way too much time troubleshooting an issue I was having with sed today. This is a common theme sometimes where I spend upwards of an hour debugging something that is ridiculously obvious.

I was trying to replace a string in a file. This is super simple to do with sed.

sed 's/string/replacement_string/` $file_name

The problem is that this command just spits out the result. If you want to actually save your change you must use the -i flag.

sed -i '/s/string/replacement_string/` $file_name

For more information on how to not suck at Linux like Lev please refer to man $command ;)

Whatever hacky script you are writing already exists in GNU Core Utilities

2016-11-16 23:52:10 ][ Tags: hacking gnu bash

When I think of bash, I think of writing hacky scripts that do random things utilizing "bash commands". It turns out that the parts of bash that "do stuff" such as echo, cut, cat are part of a larger program called GNU Core Utilities.

The GNU Core Utilities are the basic file, shell and text manipulation utilities of the GNU operating system.These are the core utilities which are expected to exist on every operating system.

Source: Coreutils - GNU core utilities I am working on a general purpose backup utility and this evening I was moments away from writing something like this: perl -e (print split("/\//", "/foo/bar/baz.tar.gz") My goal was to try to extract the base file name from a given directory (I recognize that that code does not actually do that). Then I realized that this was pure madness and there had to be a better way. This is when I discovered the handy basename program. It simply does the needful. GNU Core Utilities is full of all sorts of gems such as this one. My main takeaway from this is to read the entire GNU Core Utilities manual so I can stop writing horrible things.