title: #! /usr/bin/env and process names: portability at a price?
body: <p>There are lots of <a href="https://stackoverflow.com/questions/2429511/why-do-people-write-usr-bin-env-python-on-the-first-line-of-a-python-script">good</a> <a href="https://stackoverflow.com/questions/1352922/why-is-usr-bin-env-python-supposedly-more-correct-than-just-usr-bin-pyth">reasons</a> to use #! /usr/bin/env. Bottom line: It makes your code more portable. Well, sorta. Check this out....</p>
  
  <hr>
  
  <p>I have two nearly identical scripts, <code>bintest.py</code></p>
  
  <pre><code>#! /usr/bin/python
  import time
  time.sleep(5*60)
  </code></pre>
  
  <p>and <code>envtest.py</code></p>
  
  <pre><code>#! /usr/bin/env python
  import time
  time.sleep(5*60)
  </code></pre>
  
  <p>Note that they are only different in their <a href="http://en.wikipedia.org/wiki/Shebang_%28Unix%29" rel="nofollow noreferrer">shebangs</a>.</p>
  
  <hr>
  
  <p><code>bintest.py</code> runs as expected</p>
  
  <pre>
  br@carina:~$ ./bintest.py & ps && killall bintest.py
  [1] 15061
    PID TTY          TIME CMD
  14625 pts/0    00:00:00 bash
  15061 pts/0    00:00:00 bintest.py
  15062 pts/0    00:00:00 ps
  br@carina:~$ 
  [1]+  Terminated              ./bintest.py
  </pre>
  
  <p>but <code>envtest.py</code> does something less-than-optimal</p>
  
  <pre>
  br@carina:~$ ./envtest.py & ps && killall envtest.py
  [1] 15066
    PID TTY          TIME CMD
  14625 pts/0    00:00:00 bash
  15066 pts/0    00:00:00 python
  15067 pts/0    00:00:00 ps
  envtest.py: no process found
  br@carina:~$ killall python
  br@carina:~$ 
  [1]+  Terminated              ./envtest.py
  </pre>
  
  <hr>
  
  <p>What we've seen is that using <code>#! /usr/bin/env</code> caused the process to receive the name "python" rather than "envtest.py", thus rendering our <code>killall</code> ineffective. On some level it seems like we've traded one kind of portability for another: we can now swap out python interpreters easily, but we've lost "kill-ability" on the command line. What's up with that? If there's a best-practice here for achieving both, what is it?</p>