There are two workarounds for what you are trying to do, but neither work the way you are trying. The only way* for a program to affect its calling shell is by help from the calling shell.

You can make a make your program emit the prompt string, and then export the value in your shell. Or you can make your program emit the complete export command and then use eval in the shell.

1) emit the prompt string

in .profile or .bashrc, or manually at a prompt:

export PS1=$( make_a_red_prompt.pl )
[download]

make_a_red_prompt.pl

#!/usr/bin/perl
use strict; use warnings;
my $cmd = q( \e[0;31m[\u@\h \W]$ \e[m );
print $cmd , "\n";
[download]

2: return the full shell command and use eval.

manually at a prompt, or within a dotfile:

eval $( export_a_red_prompt.pl )
[download]

#!/usr/bin/perl
use strict; use warnings;
my $cmd = q( export PS1="\e[0;31m[\u@\h \W]$ \e[m " );
print $cmd , "\n";
[download]

Here I'm using $( command ) in the shell to return the STDOUT of a command into the current prompt. Equivalent to using backticks: `command`.

Why use a perl subprocess to essentially just echo a string? The advantage would come in from using something like Term::ANSIColor

#!/usr/bin/perl
use warnings; use strict;
use Term::ANSIColor;
my $prompt = colored ("Prompt", 'bold red on_white');
print "export PS1=$prompt\n";
[download]

*ok, technically, yes it is possible for a subprocess to affect the caller. But since it involves finding the parent process and directly inserting into its memory space, I really don't think you want to do that.

It does make for a fun answer to that interview question, though.

ps. zsh.org is awesome.