Replicating the error:
I am using iTerm2 on Macbook (OS X Yosemite)
I ssh into a remote instance and tried to run the clear command and this error is shown:
'xterm-new': unknown terminal type.
Not only for the clear command but the same error is displayed for several other commands and the command does not execute as expected.
The error occurs only when I use iTerm2 and not when I use the default Mac Terminal. So I am guessing this problem has something to do with iTerm2 and not the virtual machine.
How can I solve this problem with iTerm2?
As mikyra pointed out in the comments above, setting the environment variable TERM=xterm-256color solves the problem.
To summarize:
# Run the following commands on the local machine's bash prompt
echo "export TERM=xterm-256color" >> ~/.bashrc
source ~/.bashrc
ssh into remote machine and run the commands you like. The same xterm-new error should not occur now.
Related
I am trying to use the SSHOperator to SSH into a remote machine and run an external application through the command line. I have setup the SSH connection via the admin page.
This section of code is used to define the commands and the SSH connection to the external machine.
sshHook = SSHHook(ssh_conn_id='remote_comp')
command_1 ="""
cd /files/232-065/Rans
bash run.sh
"""
Where 'run.sh' runs the shell script:
#!/bin/sh
starccm+ -batch run_export.java Rans_Model.sim
Which simply runs the commercial software starccm+ with some options I have specified.
This section defines the task:
inlet_profile = SSHOperator(
task_id='inlet_profile',
ssh_hook=sshHook,
command=command_1
)
I have confirmed the SSH connection works by giving a simple 'ls' command and checking the output.
The error that I get is:
bash run.sh, error: run.sh: line 2: starccm+: command not found
The command in 'run.sh' works when I am logged into the machine (it does not require a GUI). This makes me think that there is a problem with the SSH session and it is not the same as the one that Apache Airflow logs into, but I am not sure how to solve this problem.
Does anyone have any experience with this?
There is no issue with SSH connection (at least from the error message). However, the issue is with starccm+ installation path.
Please check the installation path of starccm+ .
Check if the installation path is part of $PATH env variable
$ echo $PATH
If not, then install it in the standard locations like /bin or /usr/bin etc (provided they are included in $PATH variable), or export the installed director into PATH variable like this,
$ export PATH=$PATH:/<absolute_path>
It is not ideal but if you struggle with setting the path variable you can run starccm stating the full path like:
/directory/where/star/is/installed/starccm+ -batch run_export.java Rans_Model.sim
I am trying to rsync a local folder to a remote location. This a command that I have run successfully a week ago, but now if i run:
rsync -vrtzu\
--chown=user:webadm
--delete
--exclude-from=.rsyncignore
FOLDER/
USER#REMOTE:/DESTINATION
Then I get the following error message:
zsh:1: no matches found: --usermap=*:USER
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(235) [sender=3.1.3]
make: *** [makefile:39: push] Error 12
The command is run from a makefile, hence the last line.
I am using a regular WSL2 Ubuntu shell, not zsh.
I am able to ssh into the remote location with USER#REMOTE.
I have also checked that both locations have rsync installed (same version).
Finally, there is plenty of disk space available on the remote location.
Any pointers? What should I be checking to improve my diagnostic?
Thanks in advance!
This can happen when the remote shell messes with the command. Not sure exactly why and what it does but it modifies escaping so that the file path becomes invalid.
In your case the shell outputs --usermap=*:USER at log in.
The solution is to change the remote (zsh) shell to bash using the chsh command
I'm pretty sure this is an rsync bug:
zsh:1: no matches found: --usermap=*:USER
It only happens the remote machine's default shell is zsh.
It was fixed somewhere between rsync 3.2.3 (where it's broken) and 3.2.5 (where the bug is gone).
You can verify this by passing -vv to rsync. This prints as one of the first output lines which command invocation rsync is doing on the remote server via SSH.
On a broken version, it prints e.g.:
... ssh ... rsync --server -vvnlogDtpRe.LsfxCIvu "--usermap=*:user" "--groupmap=*:webadm"
On a fixed version, it prints e.g.:
... ssh ... rsync --server -vvnlogDtpRe.LsfxCIvu "--usermap=\*:user" "--groupmap=\*:webadm"
As you can see, they inserted a \ to fix the string being interpreted by zsh.
I have this error just trying to use WSL from cmder
wslbridge error: failed to start backend process
note: backend error output: -v: -c: line 0: unexpected EOF while looking for matchi ng `''
-v: -c: line 1: syntax error: unexpected end of file
ConEmuC: Root process was alive less than 10 sec, ExitCode=0.
Press Enter or Esc to close console...
does anyone how to solve it?
Create a new profile with the command wsl.exe.
Taken from https://github.com/Maximus5/ConEmu/issues/1930#issuecomment-512882561; it works for me.
For anybody having problems with this, I finally figured it out by setting a new task command of:
wsl.exe ~ -d Ubuntu-20.04
In my case, I had two versions of WSL installed and it wouldn't take the newer in Cmder for anything—it always loaded the ~ directory of my older install. You can use the file browser and go to directory \\wsl$ to see which version of WSL you are using.
I found this solution:
It is a ConEmu thing. The whole WSL part is for WSL version 1, I guess you are running WSL version 2?
You need a new version of cygwin1.dll
Grab one here: https://cygwin.com/snapshots/
Go to vendor\conemu-maximus5\ConEmu\wsl and replace the dll.
You need wslbridge 2:
Grab it here: https://github.com/Biswa96/wslbridge2/releases (the cygwin version)
Copy the content to the same directory: vendor\conemu-maximus5\ConEmu\wsl
Now edit your WSL bash task:
Replace the part "conemu-cyg-64.exe --wsl" with "conemu-cyg-64.exe %ConEmuBaseDirShort%\wsl\wslbridge2.exe"
It works now.
note: backend error output: -v: -c: line 0: unexpected EOF while looking for matching `''
-v: -c: line 1: syntax error: unexpected end of file
ConEmuC: Root process was alive less than 10 sec, ExitCode=0.
Press Enter or Esc to close console...
This is error i am getting.
Also i have set the fish shell as default shell in WSL.
For WSL1 on windows 10 build later than 1909 (yes wsl2 is available to me but for corporate reasons i cant use it)
Try setting your command to wsl.exe -new_console:d:C:\_stuff\code -cur_console:p5 and the task parameters to /dir "c:/_stuff/code" /icon "c:/_distros/ubuntu/ubuntu1804.exe"
You may need to change the file locations to make the command and parameters suitable for your setup. c:/_stuff/code is where i keep all my repositories and c:/_distros/ubuntu is where i have installed ubuntu.
I'm trying to run a command on a remote host via libssh2 as wrapped by the ssh2 Rust crate.
So I would like to run the command cargo build, but when I try to run it via libssh, I get the error:
cargo: command not found
However, when I ssh into the server manually from the command line everything works fine.
I have noticed that the $PATH is different when running ssh from the command line and libssh as well:
for instance when I echo $PATH
ssh gives me:
/home/<user>/.cargo/bin:/usr/share/swift/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bi
while libssh gives me:
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
So it looks like what's happening is that the modifications made to $PATH inside .bashrc and .profile are not making it in when running via libssh.
I also get the same behavior if I run /bin/bash -c "echo ${PATH}"
Why would this be the case, and is there any way to get the same behavior in both these cases?
Please take a look at that question.
TL;DR A login shell first reads /etc/profile and then ~/.bash_profile. A non-login shell reads from /etc/bash.bashrc and then ~/.bashrc.