I am trying to open a terminal and run a script using matlab. The script will open an ssh connection. The matlab command is:
system(['lxterminal -e "bash ' scriptName '" &'],'-echo');
When I execute the matlab command the script runs but fails fails to validate SSL credentials.
The script is running ssh through the python paramiko package.
The error arises from the cli.py module.
The problem is solved if I run
system(['lxterminal -e "sudo bash ' scriptName '" &'],'-echo');
but then I have to enter the user password each time I execute the script.
If I open an lxterminal and run the same command:
bash scriptName
it works without the sudo.
I think it is related to some environmental variables / configuration which are not loaded in lxterminal before running the script, but cannot figure out it.
Using xterm instead of lxterminal has the same behavior.
Any ideas?
The fix, might be dirty, was to empty the LD_LIBRARY_PATH from the matlab environmental variables before calling the system command using the following command in the matlab script
setenv('LD_LIBRARY_PATH');
Probably the matlab LD_LIBRARY_PATH path is using obsolete libraries compared to the ones python needs.
A better approach might be to start removing one by one the paths until finding the one causing the problem.
Related
I've found a very strange issue, when in linux terminal I type "enable -n trap", it would disable the trap linux builtin command. But if I put it into a script like
#!/bin/bash
enable -n trap
and then run the script, there's no error but the command is also not disabled. Really appreciate if someone could share what is happening and how to run it in some file instead of directly in the terminal. Thank you!
The enable command only affects the current shell. When you run a script, that script is executed in a new process, so:
A new shell starts
The enable command runs and disables the trap command in that shell
The shell exits
If you want to affect the current shell, your only option is to source the script using the . (or source) command. If the script is named disable-trap.sh and is in your $PATH, you can run:
. disable-trap.sh
You can also provide a full path to the script:
. /path/to/disable-trap.sh
Sourcing a script like this is largely equivalent to typing the same commands in at the command line: it executes the instructions in the script in the current shell, rather than spawning a new process.
I am building project source code in a SUSE server.
The project build.sh called "lzma" command to compress kernel.
The project build.sh need "sudo" to get access to some system command.
But I has tried to execute "sudo ./build.sh", and the shell always report error: "lzma: command not found."
I could execute "lzma" in shell with my user account. It works fine.
I also write a test shell script named "test.sh" which calls "lzma" command.
I found that it fails with same error message if I excute "test.sh" with "sudo" .
But if I execute "test.sh" without "sudo", it works fine.
Why ?
"Command not found" within sudo is almost invariably the result of an environment variable such as PATH, LD_LIBRARY_PATH (if what's missing is not the executable but a shared library it requires) or the like being altered.
You can pass working values through your environment variables through explicitly:
sudo PATH="$PATH" ./test.sh
Sudo uses a different Path then your user account.
EDIT (see comments)
Try and execute:
type lzma
Say the output reads something like '/usr/bin/lzma', then just copy that output into your sudo command like (for example):
sudo /usr/bin/lzma
That should do the trick. You should also write the full path of lzma into your shell script if you are to run it as root.
EDIT 2:
Or, as Charles Duffy mentioned in his answer, you could leave all things as is and simply use PATH="$PATH" in your command if you are trying to execute your file as SUDO or as a different user.
Yesterday I ran into the git execute bit bash script quirk - the one that requires:
git update-index --add --chmod=+x scriptname.sh
and it seemed strange to me that it was even possible to get stuck in this situation. (Ie having created a script file that you don't have permission to run).
If I have created a shell script - surely I can run it under the permissions of the shell execute permissions. Why would it need it's own execute permission bit?
My question is: Why does a bash script require an execute bit if a windows batch script can just be executed?
To run a script you have two options in unix like systems. First Option is to use a direct interpreter call with the script as parameter.
# run a bash script
bash test.sh
# run a python scripts
python test.py
The second option is mark your file as executable, with the execute bit and after a call like this ...
# sample bash
./test.sh
# sample python
./test.py
... your system tries to find the right interpreter for you. For this the first line 'shebang' of the script is used.
Bash example:
#!/bin/bash
# points to the installed bash interpreter - bash example
Python example:
#!/usr/bin/python
# points to the installed python interpreter
To your question windows only use the file extension to detect a executable file.
Well, Linux is not Windows. Linux/Unix file systems support the executable bit to distinguish executable from pure data files, and to control exec permissions for user|group|others. You can still run the script if you prefix it with the name of the shell/binary you want to start it with, but if you want to do ./scriptname.sh or execute it from the path it needs to be flagged as executable for you as the onwer|a group member|some other user, and for scripts usually the shebang in the first line that defines the interpreter to start the script with: #!/bin/bash.
I am using anaconda python. So every time, in my mac terminal, I input the terminal command:
source /Users/mylaptop/anaconda/bin/activate /Users/mylaptop/anaconda
And then I activated the anaconda python environment. But I don't want to write this command line every time, so I tried a bash script like this:
#! /bin/bash
source /Users/mylaptop/anaconda/bin/activate /Users/mylaptop/anaconda
and I put this file in the directory /usr/local/bin. But unfortunately, I cannot log into anaconda environment in this way. There is no error message showed up in the terminal. So I do not know what is happening here.
Could anyone help me out?
The easiest fix is to just put /Users/mylaptop/anaconda in your PATH, by adding something like
export PATH="/Users/mylaptop/anaconda:$PATH"
to your bash profile (~/.profile).
You can't put the activate script in a script because it has to be "sourced" to work. source causes the script to be run in your current shell (as opposed to a subshell, which is how the bash script you wrote is run). This is necessary because it modifies your PATH environment variable, and environment variables from your current shell cannot be modified by subshells.
If I open a shell into a machine with: putty -load session_name and then execute a command to add a job to a Grid queue on a linux system (qsub -cwd -b hostname), everything works fine.
But if I add the command to a text file, and then do putty -load session_name -m file.txt, I get qsub: command not found
If I back out and simplify the text file to be only the command hostname and use the -m option, it also works fine.
If I use the Connection->SSH->Remote command, and do something similar as the -m command, I get the same results as from the command line.
I'm very much a novice at linux systems, and this seems like it should be a simple fix to tell something that 'qsub' exists somewhere. Either that or there are some restrictions on these remote access things...
Edit:
Ok, so the initial question was how to run it--and I figured that out (add an absolute path), but there are other environment variable issues as well. It appears that qsub requires the SGE_ROOT variable to be set, but that isn't set for the remote commands window either.
So, a better question is, how do I get the putty remote commands shell (using -m) to open with the same properties and setup as a manual command line shell?
qsub is on your path when you log in interactively, but in the non-interactive shell it is not. Give the full path in the script, or set PATH in the script, and you ought to fix your problem.
It seems you need to run your command in the context of an interactive session, but the sshd protocol doesn't directly do that. So try invoking the command indirectly through /bin/sh.
/bin/sh -i -c "qsub -cwd -b hostname"
The -i makes the shell initialize itself like an interactive one, so it will load all the environment variables in your .profile or .bashrc that are loaded in a real interactive shell. The -c provides a command to run within that interactive shell.
You shouldn't have to explicitly set any paths this way since it works in an interactive session.