<p dir="ltr">> > > AFAIK ssh does not allow to pass environment variables to remote hosts?<br>
> > So I guess<br>
> > > it is better to pass all arguments on the command line?<br>
> > Yes and no.  While ssh doesn't pass the local environment to the remote<br>
> > system, you can include the env var assignments as part of the ssh command<br>
> > line, just as you would when executing such a command locally.  Indeed,<br>
> > that's what this patch does.<br>
><br>
> Ah, OK. Thanks for explaining that.</p>
<p dir="ltr">Any time.</p>
<p dir="ltr">I do have a related concern, though.  We might run into a problem (using either the env-var approach *or* the args-only approach) with command line lengths under certain LUN drivers.  These limits vary from shell to shell, and aren't even guaranteed to be the same for a given shell on different host systems (Linux vs BSD vs Solaris vs Cygwin, etc).  If we do encounter such troubles, an alternate approach will be required.</p>

<p dir="ltr">All I can propose at the moment is the construction of a temporary wrapper script, which would set up the environment before calling the actual driver script/binary, and would be copied (via scp, sftp, rsync+ssh, or so) to the remote host, then executed via ssh.  This wrapper could then be deleted from the remote system, or perhaps preserved for later reuse as long as the various driver parameters remain the same (we already make use of hashes for determining these kinds of things elsewhere).</p>

<p dir="ltr">Of course, it's entirely possible (and even likely) that command line lengths will never become an issue, so my concern may be unwarranted.  But in case the concern is valid, I thought I'd propose a potential solution, if for no other reason than to find out if anyone else can think of something better.</p>