When I log into the server, I can execute a user defined command, runfw from fish_user_key_bindings.fish file it runs fine. But when I try to execute
ssh user#myipaddress "cd ~/mydir; runfw"
It replies unknown command "runfw. Of course I can source the key bindings in command like this:
ssh user#myipaddress "cd ~/mydir; source ~/.config/fish/functions/fish_user_key_bindings.fish; runfw"
The runfw works, but other issues occur. So the question is, how can I remotely execute a command with fully loaded fish environment for the user?
When not running interactively, fish does not execute fish_user_key_bindings, which causes that file to not be sourced.
When you then try to run that function, it hasn't already been defined (by loading sourcing fish_user_key_bindings.fish), so fish tries sourcing "runfw.fish", which doesn't exist. So it can't find the function.
So either source fish_user_key_bindings manually, or put that function into its dedicated file called "runfw.fish".
Related
Everytime when I work with Perl (only through cmd) I put in C:\Perl520\Perl64\bin\perl.exe before my script Test.pl.
Now I want to run my script by only typing Test.pl. I have already looked through similiar questions like:
https://docs.sdl.com/791187/706364/sdl-contenta-5-7/associating--pl-files-with-strawberry-perl--windows-only-
How Do I Run a Perl Script from Cmd without typing "perl" in front of the script path?
I want to change this WITHOUT needing Admin Rights, as these are restricted on my computer.
I have even tried writing this in cmd:
assoc .pl=PerlScript
ftype PerlScript=C:\Perl520\Perl64\bin\perl.exe "%1" %*
Also here I keep getting the error message "Access is denied".
Is it possible to change the settings in another way?
EDIT: I managed to make it work through the first link. Yet I couldn't make it further after step 6 as once again I would need admin rights.
At least I am now able to run a script by just typing Test.pl.
But when using an input file :Test.pl C:\input.txt
I once again get an error message "Could not locate file!"
When writing it like this, it works as usual:
C:\Perl520\Perl64\bin\perl.exe Test.pl C:\input.txt
AFAIK, the file type association mechanism does require local admin rights. You can right-click on the script file and then pick perl.exe from the "Open With" menu, but that won't let you pass command line arguments to the string.
You might just want to run pl2bat on scripts you use often.
I would like to execute a bash command to activate a virtual environment with Octave using Linux. What I actually want to do is run DeepSpeech using Octave/Matlab.
The command I want to use is
source $HOME/tmp/deepspeech-venv/bin/activate
The line of code I tried on my own is system("source $HOME/tmp/deepspeech-venv/bin/activate")
And the output I'm getting is sh: 1: source: not found
I saw this answer on a post and tried this command setenv('PATH', ['/source $HOME/tmp/deepspeech-venv/bin/activate', pathsep, getenv('PATH')]) but with no help it returned the same error.
It's not completely clear from your question, but I'm assuming you're trying to do is run python commands within octave/matlab, and you'd like to use a python virtual environment for that.
Unfortunately, when you run a system command from within octave, what most likely happens is that this creates a subshell to execute your command, which is discarded once the command has finished.
You have several options to rectify this, but I think the easiest one would be to activate the python virtual environment first, and run your octave instance from within that environment. This then inherits all environmental variables as they existed when octave was run. You can confirm this by doing getenv( 'VIRTUAL_ENV' ).
If that's not an option, then you could make sure that all system commands intended to run python scripts, are prefixed with a call to the virtual environment first (e.g. something like system( 'source ./my/venv/activate; python3 ./myscript.py') ).
Alternatively, you can try to recreate the virtual environment from its exported variables manually, using the setenv command.
I'm trying to add a new ssh key. I've started the service using "ssh-agent -s", and I get this response:
SSH_AUTH_SOCK=/tmp/ssh-tUlzwbxYNLaZ/agent.9516; export SSH_AUTH_SOCK;
SSH_AGENT_PID=8992; export SSH_AGENT_PID;
echo Agent pid 8992;
But when I do "ssh-add ~/.ssh/id_rsa" I get the error "Could not open a connection to your authentication agent." Is the start command not working? I'm not sure what the output of the start command means.
The output that you show above needs to be evaluated. Very often this is done automatically by starting ssh-agent like eval `ssh-agent`. This causes
SSH_AUTH_SOCK=/tmp/ssh-tUlzwbxYNLaZ/agent.9516; export SSH_AUTH_SOCK;: the SSH_AUTH_SOCK environment variable to be set to the given value.
SSH_AGENT_PID=8992; export SSH_AGENT_PID;: the SSH_AGENT_PID environment variable to be set to the given value.
These two variables need to be set for ssh-add to be able to find the agent. If you want to evaluate them manually you can just copy those commands, paste them into your terminal or console, and hit Enter. Then try using ssh-add again.
The last line, echo Agent pid 8992;, simply prints out the ssh-agent process ID for your information.
These variables cannot be hard-coded because the socket and PID aren't predictable. Each time you start ssh-agent you need to use whatever values it prints out.
Note that these variables only get set for the current shell. So if you do it in a terminal window and then work in that window you should be fine, but if you close the window and open a new terminal it won't work anymore. Similarly if you are logged into a console, then log out and back in again.
Most modern desktop environments start ssh-agent and set the appropriate environment variables for you, so if you're using Gnome or KDE or Unity or something you shouldn't have to do this. If you are manually starting your environment or using something more bare-bones that doesn't handle this for you you should probably add eval `ssh-agent` to your X startup file, e.g. .xinitrc so that it runs before starting X.
The server perl script - with its required packages - works locally by the user "my_user".
But if I run the script remotely (ssh), I need to export PERL5LIB=/usr/local/share/perl/5.10.0/my_modules before calling the perl script to get it working.
Why this and how can I turn around this in order to avoid exporting PERLIB each time I need to call a remote perl script ?
WORKING :
ssh my_user#remote_server "export PERL5LIB=/usr/local/share/perl/5.10.0/my_modules; /cgi-bin/my_perl_script.pl --option1 foo --option2 '*';"
NOT WORKING :
ssh my_user#remote_server "/cgi-bin/my_perl_script.pl --option1 foo --option2 '*';"
returns :
Can't locate my_package1.pm in #INC
That might be rather an ssh question than a strict perl point : why the remote user running the perl script does not inherit from its ENV local datas.
Thx
As suggested by #mu_is_too_short (no friction is good as well), and linking to a more detailed explanation here, there are different types of shells : "the SSH command execution shell is a non-interactive shell, whereas your normal shell is either a login shell or an interactive shell".
So the solution is what I did on purpose (eg adding "export PERL5LIB" before running the script), or better, source the whole environement from the remote user to run the remote shell with the expected behavior.
Is it possible to have a Perl script run shell aliases? I am running into a situation where we've got a Perl module I don't have access to modify and one of the things it does is logs into multiple servers via SSH to run some commands remotely. Sadly some of the systems (which I also don't have access to modify) have a buggy SSH server that will disconnect as soon as my system tries to send an SSH public key. I have the SSH agent running because I need it to connect to some other servers.
My initial solution was to set up an alias to set ssh to ssh -o PubkeyAuthentication=no, but Perl runs the ssh binary it finds in the PATH instead of trying to use the alias.
It looks like the only solutions are disable the SSH agent while I am connecting to the problem servers or override the Perl module that does the actual connection.
Perhaps you could put a command called ssh in PATH ahead of the ssh which runs ssh as you want it to be run.
Alter the PATH before you run the perl script, or use this in your .ssh/config
Host *
PubkeyAuthentication no
Why don't you skip the alias and just create a shell script called ssh in a directory somewhere, then change the path to put that directory before the one containing the real ssh?
I had to do this recently with iostat because the new version output a different format that a third-party product couldn't handle (it scanned the output to generate a report).
I just created an iostat shell script which called the real iostat (with hardcoded path, but you could be more sophisticated), passing the output through an awk script to massage it into the original format. Then, I changed the path for the third-party program and it started working fine.
You could declare a function in .bashrc (or .profile or whatever) with that name. It could look like this (might break):
function ssh {
/usr/bin/ssh -o PubkeyAuthentication=no "$#"
}
But using a config file might be the best solution in your case.