SSH heredoc to run Perl script on another server can't find right paths

Question

I have a Perl program on server_B which uses Perl DBI and 5.010 and runs fine from the server_B terminal. I run it from a shell script which first prepares some arguments and then passes them to the Perl program, all works fine.

I need to run a shell script on server_A that will execute that script on server_B. This is because the Perl program creates several files that I want to SFTP back over to server_A. This is the script I'm running on server_A:

ssh server_B <<- EOF
    perl/update.sh
EOF

There is some strange behavior which I'm trying to understand:

• The script (update.sh) on server_B runs mysql, which is not installed on server_A (which is why I have to do this whole thing.) If I try to run it on server_B as-is, I can call mysql just like that. But when I run the above script (on server_A) to ssh into server_B and run that script, it doesn't recognize mysql unless I change the file (on server_B) to call the full path /opt/mysql/client/bin/mysql (even though that file is already on server_B with mysql installed) Does this mean server_B is picking up on the PATH variable from server_A instead of using my PATH variable from server_B? Is it trying to run my programs from server_A on the files on server_B? How and why??

• If I make the change above it executes the script, but when it hits Perl it says

  Perl v5.10.0- required - this is only v5.8.8
  

  Again, 5.10 works fine on server_B but the version of Perl on server_A is 5.8.8.

• So I got rid of use 5.010; because it actually wasn't necessary, but then I have a similar problem with my modules (DBI and DBD::mysql). I get:

  Can't locate DBI.pm in @INC (@INC contains.. [my Perl PATH from server_A])
  at perlfile.pl line 4
  

I was expecting the ssh heredoc call to update.sh (from server_A) to run exactly as update.sh does if I call it on server_B, but instead it seems like it's trying to use my programs from server_A on server_B, which I find weird. Can anyone help me understand why it's happening? I feel like I'm misunderstanding something fundamental about how ssh works.

server_A is AIX with ksh

server_B is AIX with bash

Edit - since some of you voted to the effect that I haven't done my research, here's what else I've tried. I didn't mention because I don't understand them fully, these are just guesses based on other SO posts & hunches. It'd be disingenuous if I gave the impression I knew what I was talking about.

If this is a duplicate, which question should I be looking at? If this is a "just read the manual situation", which one? What should I look for?

• Read man ssh looking for clues related to environment variables, didn't find anything I understood
• Tried running with -t
• Tried running with -t -t
• Did log in remotely with ssh and manually running it - this DOES work
• Sourced my .bash_profile in the update script
• Tried to re-assign PATH as the remote server's PATH when ssh
• Tried using a different delimiter for the heredoc
• Tried < instead of <<
• Tried without the "-"

Edit 2 with Saigo's help below I determined that when in interactive ssh, if I echo $PATH I do get the target server's $PATH, but in a shell script I don't. That led me to this:

https://serverfault.com/questions/643333/different-bash-path-variables-when-using-ssh-script-vs-interactive-ssh

where I found out that scripted ssh doesn't call .bashrc, but interactive ssh does. So it looks like I was on the right track trying to source .bash_profile inside the scripted SSH heredoc, just need .bashrc not .bash_profile - however I don't have a .bashrc on the target server. I do have .profile but when I source that, I get an error stating it's for interactive bash sessions only. So now I'm just trying to find whatever file would contain my $PATH variable because it's apparently not .bashrc as there isn't one in there.

Edit 3 - tried hard-coding the PATH variable into a file and sourcing that and even then when I echo $PATH I get the origin server's PATH variable. It is reading the file in correctly, I also assigned another test variable and echoed that as part of the script. I tried sourcing /etc/profile and no luck.

Answer 1

I found a solution that works perfectly. I wasn't able to get it to work with ~/.bashrc, ~/.bash_profile, or ~/.ssh/rc but still not sure why it's not picking up my environment variables even with sourcing these.

Since it works when I manually ssh in and then run the commands one-by-one, I used these arguments to run ssh in a forced interactive login.

ssh server_B bash --login -i "~/perl/update.sh"

See these for more:

https://superuser.com/questions/564926/profile-is-not-loaded-when-using-ssh-ubuntu

https://unix.stackexchange.com/questions/46143/why-bash-unable-to-find-command-even-if-path-is-specified-properly

Hope this is useful for someone in the future. Thank you for your assistance Saigo.