It is possible to fool $ENV{SHELL} into thinking it's something other than the right answer. So I was going to mention using Proc::ProcessTable or something, combined with $$, to see what your parent process was, and check what that command was, etc., until you found a shell. But two things stop me from actually suggesting it. First, your program may be run from another program from another from the cron daemon, which is owned by init. So there may not be an obvious shell (it's there, but you may not be able to easily find it). Or your parent process may have died, and you got inherited by init.
So, I second the vote on $ENV{SHELL}. If some advanced user wants to fool you into thinking the shell is csh when it's really bash, well, they may actually know what they're doing. Let them. If it's not set, ask that it be set - or have a reasonable fallback, whatever that means to your program.
Although, I have to admit some curiosity - what are you doing that you care what the shell is? The only thing I can think of is that you're printing out a bunch of environment-setting commands, and you want to know whether to "setenv" or "export" them so that a parent shell could say exec `set_env.pl`.
