<?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>2014-01-31T18:05:49Z</modified>
<tagline>Photos, electronics, cnc, and more</tagline>
<author><name>Jeff Epler</name><email>jepler@unpythonic.net</email></author>
<entry>
<title>Mosh automatic cleanup of dead sessions</title>
<issued>2014-01-31T18:05:49Z</issued>
<modified>2014-01-31T18:05:49Z</modified>
<id>https://gamma.unpythonic.net/01391191549</id>
<link rel="alternate" type="text/html" href="https://gamma.unpythonic.net/01391191549"/>
<content type="text/html" mode="escaped">

I love &lt;a href=&quot;http://mosh.mit.edu&quot;&gt;mosh&lt;/a&gt;, using it to connect to a
long-lived screen session from multiple computers (laptop, chromebook,
$DAY_JOB, and phone).

&lt;p&gt;One problem with it is that a &lt;tt &gt;mosh-server&lt;/tt&gt; process that has no living
client will linger for a very long time (forever?).  This can happen for
various reasons, such as letting a device's battery run down.

&lt;p&gt;With some brainstorming help from the participants from #mosh, I came up
with a way to automatically kill old mosh-server processes that probably
represented defunct clients without killing ones that may represent working
clients.

&lt;p&gt;For a long time, my basic setup has been to run a command equivalent to:
&lt;tt &gt;mosh myserver -- bin/cs&lt;/tt&gt; where cs is a script which sets some environment
variables and ends with &lt;tt &gt;exec screen&lt;/tt&gt;, so I already had an excellent
location to put cleanup code.

&lt;p&gt;I also felt that the cleanup rule I wanted was: kill all mosh-server processes
started from the same client.  $SSH_CLIENT was suggested for this, but it's not
useful since my portable devices naturally connect from different networks with
different IP addresses (that's the point of mosh after all!)  So I jumped
to the conclusion that I needed a unique identifier.  Why not involve a UUID?

&lt;p&gt;As soon as I realized I needed to pass the UUID on the commandline or
environment of &lt;tt &gt;cs&lt;/tt&gt;, I realized that meant it would show up in the &lt;tt &gt;
mosh-server&lt;/tt&gt; commandline.  So that led to the following snippet: ($i is already
identified as being the UUID= argument):
&lt;pre &gt;
    ps h --sort start_time -o pid,command -C mosh-server |
        grep &amp;quot;$i&amp;quot; |
        head --lines=-1 |
        awk '{print $1}' |
        xargs --no-run-if-empty -n 1 --verbose kill
&lt;/pre&gt;

&lt;p&gt;That seems to work!  One final wrinkle, though: In mosh irssi connectbot,
there's no way to specify the mosh commandline directly.  Hoever, there is
&amp;quot;Requested mosh server&amp;quot;.  I created a wrapper script reading:
&lt;pre &gt;
#!/bin/sh
exec mosh-server &amp;quot;$@&amp;quot; -- bin/cs UUID=...
&lt;/pre&gt;
and used that script (with full path, in my case) as the configuration
value.

&lt;p&gt;Now I shouldn't have to worry about mosh-server processes piling up
on my main linux box anymore.
</content>
</entry>
<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>Screen-scrape ting device usage</title>
<issued>2013-01-04T20:37:39Z</issued>
<modified>2013-01-04T20:37:39Z</modified>
<id>https://gamma.unpythonic.net/01357331859</id>
<link rel="alternate" type="text/html" href="https://gamma.unpythonic.net/01357331859"/>
<content type="text/html" mode="escaped">
&lt;a href=&quot;https://ting.com&quot;&gt;Ting&lt;/a&gt; offers great inexpensive cellphone service,
so when Ingrid's organization needed to provide a cellphone for an employee, I
naturally suggested she use them.  However, Ting doesn't presently have an API
to check usage.  So I put together a Python program that can screen-scrape this
information.</content>
</entry>
<entry>
<title>Half-maximize script for Linux</title>
<issued>2012-02-29T15:42:38Z</issued>
<modified>2012-02-29T15:42:38Z</modified>
<id>https://gamma.unpythonic.net/01330530158</id>
<link rel="alternate" type="text/html" href="https://gamma.unpythonic.net/01330530158"/>
<content type="text/html" mode="escaped">
A number of times, I've said that I like the Windows 7 feature that allows
a window to easily be half-maximized.  I got tired of waiting for it to be
added to my favorite window manager, so I wrote a script that uses
the program &lt;tt&gt;wmctrl&lt;/tt&gt; to half-maximize windows, then bound it
to key presses in my window manager.  Now, with a press of ctrl+alt+[QWER],
I can half-maximize a window into 4 locations on my dual-monitor setup.</content>
</entry>
</feed>
