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.
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
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 get unison working after upgrading to Mac OS X Catalina. Unfortunately, macports installs a more recent version of ocaml (4.08.1), which means that the unison 2.51.2 release won't compile.
Well, that's no problem, I just update to git master on unison, and recompile. Unfortunately, this fails at sync time because the version of ocaml used to compile on the mac (4.08.1) is different from the one used to compile on the other machine (4.07.1). Sigh. Okay, use opam magic to install 4.07.1 on my machine. Everything should be fine, right? No!
Here's the error:
Connected [//zzzmyhost//home/clements/unison-home -> //zzzmyotherhost//Users/clements/clements]
Looking for changes
Uncaught exception Failure("input_value: ill-formed message")
Raised at file "/private/tmp/unison/src/lwt/lwt.ml", line 126, characters 16-23
Called from file "/private/tmp/unison/src/lwt/generic/lwt_unix_impl.ml", line 102, characters 8-23
Called from file "/private/tmp/unison/src/update.ml" (inlined), line 2105, characters 2-69
Called from file "/private/tmp/unison/src/uitext.ml", line 978, characters 16-56
Called from file "/private/tmp/unison/src/uitext.ml", line 1066, characters 6-90
Called from file "/private/tmp/unison/src/uitext.ml", line 1088, characters 19-66
Called from file "/private/tmp/unison/src/uitext.ml", line 1144, characters 21-43
What's going on?
Sigh... the problem here (very non-obvious) is actually with a corrupted/wrong-format syncronization file, created when doing the failed sync in the earlier test.
The solution is just to go into ~/Library/Application Support/Unison (on a UNIX machine this path would presumably live in ~/.unison and delete the archive file that's causing the problem (probably the most recent one). In a pinch, just delete all of the archive files and start over.
I've got the same problem between Windows and Ubuntu 20.04 after upgrading from Ubuntu 18.04. I tried the binary from Ubuntu 18.04 in 20.04, which still fails, so the incompatibility is likely inside one of the dependencies.
As a workaround I created a Docker image based on Ubuntu 18.04:
FROM ubuntu:18.04
RUN apt-get update && apt-get dist-upgrade -y
RUN apt-get install unison -y
RUN useradd martin --home /home/martin
WORKDIR /home/martin
USER martin
Building it with docker build -t unison:18.04 .
And then I added a wrapper to ~/bin/unison-2.48.4-docker:
#!/bin/bash
docker run --rm -i \
-v /home/martin/dirtosync:/home/martin/dirtosync \
-v /home/martin/.unison:/home/martin/.unison \
--hostname $(hostname) \
unison:18.04 unison "$#"
Setting the --hostname is important, since the hostname is part of the archive file.
Inside the profile on my Windows machine I configured:
servercmd = ~/bin/unison-2.48.4-docker
In my setup with two windows clients and one Ubuntu 18.04 server, connected by ssh, the problem startet with a second server running on Ubuntu 20.04. Neither the old server nor the windows clients could sync with the new machine.
My solution: Copying the binary from Ubuntu 18.04 to a new directory in the Ubuntu 20.04 machine. This new file is referenced in the "authorized_keys" file of ssh on the new machine.
So far, everything works great with unison 2.48.4.
I am very new to vxworks and make files.
I have a batch file to run this below command
%GNUFILTER% C:\WindRiver\wrenv.exe -p vxworks-6.3 make --no-print-directory BUILD_SPEC=PENTIUMgnu comp=kernel DEBUG_MODE=0 -f vsbuild.make %*
Can anyone explain me this command please?
This giving me an error message
sh.exe stopped working" abnormal program termination
C:\Users\XXXXX\AppData\Local\Temp\make12099.sh: fork failed: no child processes [1]
Once I had a such error when I copied the workbench files into my computer instead of installing workbench. Reinstalling properly by installshield solved the problem.
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.