TIL

20 Sep 2011 · #linux · #unix

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

env

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
FOO=bar
antrix@cellar:~$

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

antrix@cellar:~$ which env
/usr/bin/env
antrix@cellar:~$

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:

NAME
       env - run a program in a modified environment
SYNOPSIS
       env [OPTION]... [-] [NAME=VALUE]... [COMMAND [ARG]...]
<snip>
       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!

kill

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 :-)