· #linux · #unix
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 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
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:
But I never put two & two together. Shame on me!
The second interesting thing was
ksh‘s strange handling of
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
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
And yes, I realize the title should actually be This Week I Learned :-)