When I run this, it will say something "Can't exec ... No such file or directory...". That is because of the presence of "$1" in the bash script.

No. The first argument of (a multi-argument call to) system is the name of a command to execute. You're passing the entire script as the name of the command. You could run sh and pass the script to sh via the -c argument.

#!/usr/bin/perl

use strict;
use warnings;

my $sh_script = do { local $/; <DATA> };

my @args = ( 'option1' );

system(sh => (-c => $sh_script, '--', @args) ) == 0
    or die "$?/$!\n";

__DATA__
#!/bin/sh

echo "hello"
echo $1
echo "hi"
[download]

Another option is to send the script to sh's stdin:

...

open(my $sh_fh, '|-', sh => ('-s', '--', @args) )
    or die "$?/$!\n";
print $sh_fh $sh_script;
close($sh_fh);

...
[download]

The -- denotes the end of arguments destined for sh and the start arguments destined for the script.

Update: Added alternate method.

As for what you've posted, if you put the content of your __DATA__ block into an disk file, e.g. call it "foo.sh", then do system( "foo.sh" ) or maybe system( "/bin/sh", "foo.sh" ) then the subshell run by the system call would read the shell script from that file, and run it.

If the idea is to use perl to change some string in the shell script and then run it, then the trick I used in shloop might help you: open up a pipeline file handle that runs a shell, and then print shell commands to it:

open( SH, "|-", "/bin/sh" ) or die "can't launch a shell: $!\n";

my $param = "whatever";
print SH "echo hello\n";
print SH "echo $param\n";
print SH "echo hi\n";
close SH;
[download]

That design requires advance knowledge of the script (to change $1 to the parameter). I don't know if that's a problem.

The implementation fails if $param contains two spaces in a row, a quote, etc due to improper encoding of strings. Fix:

sub to_sh_lit {
   my ($s) = @_;
   die if !utf8::downgrade($s, 1);  # Expecting bytes.
   die if $s =~ /\x00/;             # NUL can't be passed.
   $s =~ s/('+)/'"$1"'/g;
   return "'$s'";
}

my $lit_param = to_sh_lit($param);
print SH "echo $lit_param\n";
[download]

Update: Added code.

That design requires advance knowledge of the script (to change $1 to the parameter).

Well, there's no telling from the OP (as originally seen) how much is known in advance. Whatever the requirements are for the task, this approach could be adapted to use the available knowledge as needed, and work as well as other approaches.

The implementation fails if $param contains two spaces in a row, a quote, etc.

Sure. When printing commands to a shell process, there are lots of ways to go wrong and fail (and/or cause all sorts of mayhem and damage, depending on what sorts of mistakes are made and how various permissions play out when the perl script executes). This approach demands respect and caution; anyone who isn't sure whether they might get it wrong probably shouldn't use it.

A very valid point indeed! ;)
Respectfully, Brother Hippsta

open SH, '|/bin/sh --some-switch-sh-understands--important' or die $!;
print SH <DATA>;
close SH;
[download]

That doesn't address passing an argument to the script.

You're correct , the 2nd part doesn't, but first part does :)

perliff