I came across a couple of interesting things at work this week.


I’ve always used env to find out what environment variables are set in a shell. Either run it and read the output or pipe it to grep to check if a particular variable is set or not.

This week, I found out something strange:

antrix@cellar:~$ FOO=bar
antrix@cellar:~$ env | grep FOO
antrix@cellar:~$ export FOO=bar
antrix@cellar:~$ env | grep FOO

I don’t know about you but I was very surprised by this behaviour! How could this be?

antrix@cellar:~$ which env

Never in my years of using env had I suspected that it wasn’t a shell built-in! So let’s see what the man page for env says:

       env - run a program in a modified environment
       env [OPTION]... [-] [NAME=VALUE]... [COMMAND [ARG]...]
       If no COMMAND, print the resulting environment.

So essentially, all these years, I was using env without really using it fully!

Let me correct that. I did use it quite a bit as the first line of my python scripts:

#!/usr/bin/env python

But I never put two & two together. Shame on me!


The second interesting thing was ksh‘s strange handling of kill. In bash, you can specify any of the normal signals that kill should send to a process using the -s flag. The argument value to that flag can be either the signal number or the name. So both of the following will work:

antrix@cellar:~$ kill -s 15 pid
antrix@cellar:~$ kill -s TERM pid

But in ksh, if you use the -s flag, the value must be a signal name, not a number! Worse, it won’t even warn you with an error!

Just another in the long list of ksh idiosyncrasies!

And yes, I realize the title should actually be This Week I Learned :-)