system runs your commands using /bin/sh. If /bin/sh is a link to a Bourne shell (it's likely), the error you're seeing will occur. setenv is not a valid Bourne shell command.

You can alter the environment of your Perl script with the %ENV hash:

## untested
{
    local %ENV;
    $ENV{'GENESIS_DIR'}  = '/genesis/customers/ckt-imgs';
    $ENV{'GENESIS_EDIR'} = '/genesis/e90';
    system '/genesis/e90/get/get';
}
[download]

It's worth pointing out that setting environment variables in a Perl script, however, will not change your shell's environment variables.  That's because you are running Perl in a subprocess, which has its own environment variable list; as soon as the Perl script exits, you're back with the environment variables that the parent had originally.

To test this is as easy as running the following script:

#!/usr/bin/perl -w

use strict;
use warnings;

$ENV{'abc'} = 'def';
system('echo $abc');
[download]

% echo $abc
abc: Undefined variable.
[download]

  [Parent process] ======> [Perl subprocess] ====> [Sub process shell]
    Env list #1,             Env list #2              Env list #3
   "abc" NOT defined        copied from the          copied from the
                            Parent process,         Perl subprocesses,
                           define "abc" here       "abc" still defined
[download]

Moral of the story is:  there is no way that you can ever set an environment variable in a subprocess and have it "persist" to the parent process.

Update:  And the same thing is true, of course, for the process' notion of current directory.

The shell executed in system is not csh. Most probably bash. You can directly manipulate %ENV, though: see perldoc perlvar. Also beware of

perldoc -q environment
[download]

(maybe you knew, maybe you didn't, in doubt better to point this out.)

Technically, it's more likely that it's /bin/sh - whatever that is. Check perl -MConfig -le 'print $Config{sh}'. On Linux, this is usually bash, but as I recall, bash does some things slightly differently when invoked as sh than as bash, largely for backwards compatability with the Bourne Shell upon which it was based.

Making /bin/sh a link to csh seems just whacked though. Most of your system won't work properly if you try it.

<rant>That's it! As popeye says "I've hads all I can take I can't takes it no more." I'm starting a campaign to downvote everytime this question comes up *plus* every reply. I'm all for helping beginners but come on ... how many times has this question been asked? I completely understand how process concepts trip novices but the question displays a complete lack of initiative -- it's been asked and answered an inordinate amount of times. </rant>

And please ... somebody downvote my reply ..

In that case maybe the documentation is at fault? (no, I didn't vote you down)