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.
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
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
libtool installed. I already have libtool installed, but it is
looking specifically for some tools found in the
Installing this package resolves the issue.
sudo apt-get install libtool-bin
2017-05-04 23:15:44 ][ Tags: hacking gnu terminal
The Debian Policy
that all packages should come with documentation. In order to save space
in the debian archive these documents need to be compressed with
There are a ton of these files floating around in the
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
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])
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
sed -i '/s/string/replacement_string/` $file_name
information on how to not suck at Linux like Lev please refer to
man $command ;)
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
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