<?xml version="1.0" encoding="utf-8"?>
<feed version="0.3" xmlns="http://purl.org/atom/ns#">
<link rel="alternate" type="text/html" href="https://gamma.unpythonic.net/"/>

<title>Jeff Epler's blog</title>
<modified>2013-05-20T21:37:49Z</modified>
<tagline>Photos, electronics, cnc, and more</tagline>
<author><name>Jeff Epler</name><email>jepler@unpythonic.net</email></author>
<entry>
<title>tardiff: diff two (compressed) tar files without extracting</title>
<issued>2013-05-20T21:37:49Z</issued>
<modified>2013-05-20T21:37:49Z</modified>
<id>https://gamma.unpythonic.net/01369085869</id>
<link rel="alternate" type="text/html" href="https://gamma.unpythonic.net/01369085869"/>
<content type="text/html" mode="escaped">
Recently I was googling for a script to compare tar files, and found references
to a perl script (which I did not read) which reportedly did this by
expanding both tar files and then diffing the trees.  This would actually
have been fine for my case, but some people noted that their use case
involved tarfiles that were too big to extract comfortably.  I assume that
this is due to space considerations, but doubtless there are time
considerations too.</content>
</entry>
<entry>
<title>dusub: Subtract two 'du'-style listings</title>
<issued>2012-04-04T12:54:44Z</issued>
<modified>2012-04-04T12:54:44Z</modified>
<id>https://gamma.unpythonic.net/01333544084</id>
<link rel="alternate" type="text/html" href="https://gamma.unpythonic.net/01333544084"/>
<content type="text/html" mode="escaped">
Life is a constant war against the limited size of backup media.  Here
is my next weapon in the fight: dusub.  Save a &lt;tt&gt;du&lt;/tt&gt; listing
today, then find out tomorrow or next week what's been growing:
&lt;pre&gt;dusub olddu newdu&lt;/pre&gt;
or
&lt;pre&gt;du … | dusub olddu&lt;/pre&gt;
Positive numbers in the output represent an item that grew since olddu;
negative numbers represent a decrease in size since olddu.

&lt;p&gt;Version 2 knows about &amp;quot;du -h&amp;quot;-style listings.

&lt;p&gt;dusub is useful with &lt;a href=&quot;https://gamma.unpythonic.net/01329670473&quot;&gt;sorttop&lt;/a&gt;:
&lt;pre&gt;du … | dusub olddu | sorttop&lt;/pre&gt;
&lt;p&gt;&lt;b&gt;Files currently attached to this page:&lt;/b&gt;
&lt;table cellpadding=5 style=&quot;width:auto!important; clear:none!important&quot;&gt;&lt;col&gt;&lt;col style=&quot;text-align: right&quot;&gt;&lt;tr bgcolor=#eeeeee&gt;&lt;td&gt;&lt;a href=&quot;https://media.unpythonic.net/emergent-files/01333544084/dusub-v2.py&quot;&gt;dusub-v2.py&lt;/a&gt;&lt;/td&gt;&lt;td&gt;2.4kB&lt;/td&gt;&lt;/tr&gt;&lt;tr bgcolor=#dddddd&gt;&lt;td&gt;&lt;a href=&quot;https://media.unpythonic.net/emergent-files/01333544084/dusub.py&quot;&gt;dusub.py&lt;/a&gt;&lt;/td&gt;&lt;td&gt;1.4kB&lt;/td&gt;&lt;/tr&gt;&lt;/table&gt;&lt;p&gt;</content>
</entry>
<entry>
<title>Custom compose sequences in X</title>
<issued>2011-02-01T16:33:44Z</issued>
<modified>2011-02-01T16:33:44Z</modified>
<id>https://gamma.unpythonic.net/01296578024</id>
<link rel="alternate" type="text/html" href="https://gamma.unpythonic.net/01296578024"/>
<content type="text/html" mode="escaped">

In modern gnome-based Linux distributions, it's quite easy to enable
a compose key through the Keyboard Preferences window.  However, I
had trouble finding information on how to define custom compose sequences
like compose+&amp;quot;inf&amp;quot; for ∞.

&lt;p&gt;The answer is the ~/.XCompose file.  Start by copying the default compose
file (/usr/share/X11/locale/en_US.UTF-8/Compose for me) to ~/.XCompose, and
then edit it to add any additional sequences that are desired.  (You can
also remove any sequences you don't use, though it's not clear whether
there's any benefit to this.  For example, I removed all &amp;quot;dead key&amp;quot; sequences)

&lt;p&gt;Applications seem to read this file once at startup, so my testing generally
involves opening a new urxvt to verify the sequence works and inserts the
desired character.

&lt;p&gt;The Character Map applet is quite useful for finding the desired characters.

&lt;p&gt;Make sure your text editor is using the right character encoding (typically
UTF-8).

&lt;p&gt;Here are some of the sequences I've found it useful to define:
&lt;blockquote&gt;&lt;pre&gt;
&amp;lt;Multi_key&amp;gt; &amp;lt;i&amp;gt; &amp;lt;n&amp;gt; &amp;lt;f&amp;gt; : &quot;∞&quot;
&amp;lt;Multi_key&amp;gt; &amp;lt;p&amp;gt; &amp;lt;i&amp;gt;     : &quot;π&quot;
&amp;lt;Multi_key&amp;gt; &amp;lt;o&amp;gt; &amp;lt;h&amp;gt; &amp;lt;m&amp;gt; : &quot;Ω&quot;
&lt;/pre&gt;&lt;/blockquote&gt;

&lt;p&gt;It's also worth noting that you can define compose sequences that result in
entire strings:
&lt;blockquote&gt;&lt;pre&gt;
&amp;lt;Multi_key&amp;gt; &amp;lt;m&amp;gt; &amp;lt;e&amp;gt;     : &quot;Jeff Epler &amp;lt;jepler@unpythonic.net&amp;gt;&quot;
&lt;/pre&gt;&lt;/blockquote&gt;

&lt;p&gt;&lt;b&gt;Update,&lt;/b&gt; May 2011: By default in certain locales including the en_US
locale, gtk+ uses its own hardcoded list of compose sequences.  To get
~/.XCompose support in gtk+ applications, arrange to set GTK_IM_MODULE=xim in
the environment.  Related: &lt;a href=&quot;https://bugzilla.gnome.org/show_bug.cgi?id=96053&quot;&gt;gnome bug 96053&lt;/a&gt;, where I found the answer
for how to get gtk/gnome apps to behave.
</content>
</entry>
</feed>
