1

I have a .bat file on my Windows machine. This .bat file uses plink.exe to connect to an Ubuntu machine and execute an .sh script. However, I get different behaviors on the script depending on how Plink is used:

  1. log onto Ubuntu directly (in person) -- script succeeds

  2. ssh via Bitvise client -- script succeeds

  3. ssh via Plink (by calling plink.exe) and calling script from interactive shell (it's a Ubuntu shell within windows cmd.exe) -- script succeeds

  4. ssh via .bat which then calls Plink -- script fails

The script fails w/ message:

error while loading shared libraries: libCint.so: cannot open shared object file: No such file or directory

Other posts seem to refer to installation/permission issues of libCint.so but I know this is not the case since the script works correctly in other instances as shown above.

Below is the plink.exe line from my .bat file:

plink.exe !plink_ssh_details! myscript

The above script fails when called this way via .bat file; again, note that it succeeds when called directly from the Ubuntu or when I -ssh directly into the Ubuntu via cmd.exe (using plink.exe) or Bitvise client. Any help would be appreciated.

Martin Prikryl
  • 188,800
  • 56
  • 490
  • 992
Joe Pak
  • 153
  • 2
  • 9

2 Answers2

1

In the other cases, you are using interactive sessions.

While the Plink uses non-interactive session by default, when you specify a command on its command-line.

Your script probably relies on some environment variables (like PATH) being set specifically.

It's quite probable that the variables are set only for interactive sessions. Probably because they are modified in a startup script that is executed (sourced) for the the interactive sessions only.

Solutions are:


Some more obscure SSH servers can also behave differently when "exec" channel is used to execute the command. See Executing command on Plink command line fails with "not found".

Martin Prikryl
  • 188,800
  • 56
  • 490
  • 992
0

I had to hack a solution to work around this problem. Adding a "-i" option at the header of the bash script I was invoking from my .bat file did the trick:

#!/bin/bash -i

Note some warn of unwanted side effects (no mention of specifics tho...) when using this option. But calling this now interactive script from a remote ssh session (e.g. when using plink.exe from a Windows .bat file and passing inline commands to the Unix box) solves any issues regarding file/directory visibility & permission issues.

Note to plink users: if you're calling a script on Unix via plink and noticing that the script doesn't behave as expected...adding the "-i" may help debug/solve your problem. Again, note that some have claimed unwanted side-effects of this hack of which they/I'm unaware.

Joe Pak
  • 153
  • 2
  • 9
  • The side effects are mentioned in the link in my question (but only some are mentioned, a range of possible problems is unlimited). And it's even obvious that "interactive" session (-i) should not be used to automate tasks. – Martin Prikryl Jul 12 '16 at 05:28
  • Martin -- not sure which link you're referring to. I haven't seen any side effects to date. Could you clarify the link containing side effects of including -i in .sh script headers? – Joe Pak Jul 12 '16 at 17:26
  • There's only one link in my answer. And it describes two out of many possible side effects (ANSI sequences in the output and a command prompt in the output). – Martin Prikryl Jul 12 '16 at 17:37