Lobotomizing bash autocomplete

I hate the smart tab-completion functionality that comes with bash on Ubuntu (and others), and much prefer that just show me files & directories.

To disable it, just put this in your .bachrc:

complete -r

So you ditched your iPhone for an Android device ...

No, not me, I certainly haven't gotten rid of my iPhone.  Even if I didn't love the newish looks of iOS 7 (and I do love it), I'm much too lazy to learn a new UI without major payoff.

But my brother DID ditch his iPhone, and now sending him a text message is a pain, b/c my iPhone defaults to iMessage.  (There's even a lawsuit!)

I've found two threads discussing fixes for this; I haven't tried either, and haven't heard back from my brother, so I'm posting both in the hopes that one works.


(I) The easy method (from https://discussions.apple.com/thread/5079636?start=30&tstart=0)

Step 1

Go to supportprofile.apple.com/MySupportProfile.do.

Step 2

Log in with your Apple ID and password.

Step 3

Select the product you need to de-register (your iPhone, for example).

Step 4

Click ‘Unregister’.

Step 5

You’ll see the message ‘Are you sure you want to unregister and delete this product?’ – Click ‘Unregister’ again.

NOTE: if you’ve got any other iMessage-capable devices registered to the same Apple ID that you no longer have access to, unregister these now.

(II) The slightly harder method, from https://discussions.apple.com/thread/5157687

The long and short of my fix was 1) going to my iphone Settings under "Messages" and assuming iMessage is set to "on" scroll down to where it says "Send & Receive" and click on that. It showed my phone number along with other email and Apple related addresses. Deselect the phone number now associated with my Android device as well as any email messsages from which I didn't want to send/receive iMessages (in my case I still want to receive iMessages at email addresses associated with my iPad and MacBook). After doing those steps, close out of Settings.

 Then 2) go to the itunes/apple page and change your password at the following page: https://appleid.apple.com

When you change the password on your account it supposedly deauthorizes the phone number and other addresses just deselected addresses from iMessage.

Wednesday quickie: summing numbers in bash

care of stackoverflow, here's how you sum a bunch of numbers in Bash (or, well, awk):

   awk '{s+=$1} END {print s}'

Bash as occult text: starting a Unix daemon

So you've written your own Unix daemon, and now you need a start script to stick in /etc/init.d

As a socially responsible coder, you know your daemon needs to run under tightly policed user, like www or therebemonstershere.  So your init script will look something like this:

  su - therebemonstershere -c " { /usr/local/bin/mydaemon & } "

You'd also like to keep track of its pid, so you can kill your daemon later via /etc/init.d/mydaemon stop

  su - therebemonstershere -c " { /usr/local/bin/mydaemon & } ; echo \$! > /var/run/mydaemon.pid"

But this isn't enough: what about stdout and stderr?

  su - therebemonstershere -c " { /usr/local/bin/mydaemon > /var/log/mydaemon.log 2>&1 & } ; echo \$! > /var/run/mydaemon.pid"

Looking good!  But there's one more catch: when your terminal dies, your daemon will get a HUP signal and die too.   Probably in a week or so when you finally kill that xterm and forgot any of this happened.

  su - therebemonstershere -c " { nohup /usr/local/bin/mydaemon > /var/log/mydaemon.log 2>&1 & } ; echo \$! > /var/run/mydaemon.pid" 

Protip: disabling accidental text resizing in Firefox

Ubuntu, at least in its Pangolin incarnation, has this clever skeuomorphic touchpad behaviour: when you scroll with a glancing gesture, the scrolling continues for a bit after your fingers have left the touchpad, like flicking a playing card across a table.  It feels natural.

However, it often results in my Firefox fonts becoming randomly resized, as I frequently begin scrolling to the top of a page, then change my mind and highlight the URL bar via ctrl+L, and in that instant when the skeuomorphic scroll is happening and the ctrl key depressed, Firefox zooms.

The easy fix it to disable Firefox' ctrl+mousewheel zoom behaviour.

Using a web server for deferred computation

Bioinformatics lends itself to lengthy, offline computations on large datasets like Next-generation Sequencing runs, but I imagine any number of problems would follow the submit-form, check back in 10 minutes approach.

Often, web frameworks make this hard to do without resorting to secondary processes and message queues, because their response function doesn't close the socket until it returns.  (Eg, Django's views.py functions return Response objects).  Python's BaseHTTPServer / BaseHTTPRequestHandler combo turns out to make this easy:
 

import BaseHTTPServer
from SocketServer import ForkingMixIn
import socket

class Handler(BaseHTTPServer.BaseHTTPRequestHandler):

   def do_POST(self):
                path = self.path
                msg = ...
                self.send_response(200)
                self.send_header("Content-type", "text/html")
                self.end_headers()
                self.wfile.write(msg)
                self.wfile.close()
                self.connection.shutdown(socket.SHUT_RDWR)
                self.connection.close()

                long_computation() 


class ForkingHTTPServer(ForkingMixIn, BaseHTTPServer.HTTPServer):
  """
  Handle requests in a separate process.
  """
  pass

server = ForkingHTTPServer((host,port), handler_factory(override))

server.serve_forever()

The key is this bit:

   self.connection.shutdown(socket.SHUT_RDWR)
   self.connection.close()

Once you shutdown and close the socket, the HTTP client is released and you can run as lengthy a computation as you like.

Through the JVM looking-glass.

So you've got a binary file full of integers in bog-standard x86 format, just a straight list of unsigned short ints.  And you need to read them into a Java ArrayList.  Sounds simple enough.

Now, you're an experienced C programmer, so you know you'll have to deal with endianness: the JVM is big-endian, and x86 is little-endian.  Every time you find 0xff00 in your file, you need to flip those bytes around to read 0x00ff.  So you write a simple loop -- in pseudocode,

int accumulator = 0;
while( b = file.readByte() ) {
   accumulator = accumulator | b;
   accumulator = accumulator << 8;
}

And low and behold, 0xff00 becomes ... -1.

You might have guessed it already, but the problem is that Java doesn't support unsigned integers and that first byte, 0xff, is read as -1 per 2's complement.

Now, if you can visualize all that bit-shifting and or'ing, you might not see this as a problem -- the 0xff will just be OR'ed into your short, then shifted.  This is not what happens.

Instead, our byte b, which has been interpreted as -1, is silently coerced into a short -- 0xff becomes 0xffff, which is then OR'ed with 0x0000 to yield 0xffff, aka -1.  Our next byte, 0x00, is also coerced and OR'ed to no effect.

[Why anyone would want a signed byte is a whole 'nother question -- next time I want to store a value between -128 and 127, I guess I know what to use.]

The fix is to undo the 2's complement -- to turn -1 into 255, like so:

int accumulator = 0;
while( b = file.readByte() ) {
   short s = (short) b;
   if( s < 0 ) {
      s = s + 0x100;
   }
   accumulator = accumulator | s;
   accumulator = accumulator << 8;
}

That's how you read a single unsigned short in Java.  Just so intuitive, don't you think?  Compare with Python:

   s = struct.unpack("B", file.read(1))