When I type something like:
poetry --version
I get in ConEmu:
Poetry version ←[36m1.1.4←[0m
This makes Python Poetry unusable as there are codes all over the place instead of text.
Even though I have enabled the settings Inject ConEmuHk and ANSI and xterm sequences in ConEmu settings.
I tried reinstalling both but nothing seems to fix this.
example of the isssue
I'm having the same issue. My workaround is to invocate poetry with:
poetry ... --no-ansi
This disables whatever coloring or whatever poetry is trying to do and failing on conemu.
Related
Since I have updated windows, my conemu terminal is giving me the following error each time a session is created:
wslbridge error: failed to start backend process
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...
Has anyone an idea to bring conemu to a wsl terminal? Thank you
A similar error is caused by upgrading WSL from v1 to v2.
If you read through the discussion on this github issue for ConEmu you'll find a variety of instructions that can be distilled into:
Change the command for the task {Bash::bash} to the following:
wsl.exe
A GitHub user posted this workaround which worked for me:
I've fixed the issue by doing this:
Download latest cygwin1-20200531.dll.xz from https://cygwin.com/snapshots/ and unpack the file as cygwin1.dll into ConEmu\wsl\ (replacing the original file there)
Download #Biswa96's wslbridge2 from https://github.com/Biswa96/wslbridge2/releases and unpack to the same directory
Replacing {WSL::bash} task's Command with:
set "PATH=%ConEmuBaseDirShort%\wsl;%PATH%" & %ConEmuBaseDirShort%\conemu-cyg-64.exe %ConEmuBaseDirShort%\wsl\wslbridge2.exe -cur_console:pm:/mnt -eConEmuBuild -eConEmuPID -eConEmuServerPID -l
I can now access my Ubuntu under W10 just like before the W10 upgrade. Backscroll and arrows in VIM work as expected.
The key part of step 3 is to replace conemu-cyg-64.exe --wsl with conemu-cyg-64.exe %ConEmuBaseDirShort%\wsl\wslbridge2.exe.
Longer term, it looks like the author of ConEmu is working on switching to the new Windows PTY API, which will eliminate the need for the wslbridge hack (and many others) entirely.
I had the same issue with last update windows
(Feature update to Windows 10, version 2004 - Successfully installed on 9/1/2020)
the error does not seem to be related to the version of WSL from 1 to 2:
$ wsl -l -v
NAME STATE VERSION
Ubuntu-20.04 Running 1
Nevertheless, this workaround worked for me as well, thank you so much!
Exactly this goes through upgrading WSL from v1 to v2.
You have to open cmder and in the startup command or Task enter {wsl.exe} and ready
cmder is working again.
Yes, the new command for WSL2 is much simpler, but just running wsl does not cause .profile to be read because launching this way does not request login shell, and it launches as root.
A better command is to specify the user id and to invoke the shell of your choice (bash is most common) with the appropriate option. For bash a login shell is desirable so .profile, .bashrc and .bash_aliases get sourced, if present. The -l (lower case L) does that:
wsl -U yourUserName bash -l
My company has a docker image which we use for app engine flex. I need to add a font, and there doesn't seem to be a simple apt package anywhere, so I need to add it manually, following steps like the ones listed here for command-line installation on Linux. Here's what I have so far:
FROM gcr.io/google_appengine/python
# ...
# Copy the font to the appropriate location.
# The font is in a ttf in the same directory as the Dockerfile.
RUN mkdir -p /usr/share/fonts/truetype/noto
COPY NotoColorEmoji.ttf /usr/share/fonts/truetype/noto
RUN chmod 644 /usr/share/fonts/truetype/noto/*
# Rebuild the font cache.
RUN fc-cache -fv
As you can see, the image is based on the GAE base python image. We're adding a few other things, as well, but this is the stuff relevant to the font.
The fc-cache output when building the image makes it clear that it is detecting one font in the noto directory:
/usr/share/fonts/truetype/noto: caching, new cache contents: 1 fonts, 0 dirs
And when I log in to a container, I see that the file was indeed copied. I can even run fc-cache again manually and see that same output. The new font, however, is never reflected in fc-list.
It's been frustrating to diagnose this because following similar steps seems to work perfectly on my own machine. It's almost as if fc-cache is behaving differently in the container.
Any ideas on what I might be missing?
Update:
I added a line to the docker file to explicitly set the correct permissions on the font file after copying it, but it made no difference. This was expected because these commands ultimately run as root, but still it seems like a better practice.
Interestingly, though, I tried this with a different font (NotoEmoji-Regular.ttf) and it did work. I'll be looking into what the difference between these two fonts might be that is causing this.
Very frustrating.
Another Update:
It seems the primary difference is likely the colors in the font, which is nonstandard in the TrueType format. As comments have pointed out, my system is using a newer version of fontconfig than the docker image, which likely accounts for the discrepancy.
I'd like to verify this, but it's digging a bit down a rabbit hole that my organization would rather me not spend too much more time on. If anybody is able to do so, however I'd be happy to give you the accepted answer. Otherwise I'm going to have to leave this be for a bit.
Try to add to dockerfile
# install fontconfig
RUN apt-get update; apt-get install -y fontconfig
# refresh system font cache
RUN fc-cache -f -v
it's the font file had issue, check the report in image
I used below commnad inside Docker file to install fonts and that worked for me.
RUN apt update && apt install fonts-indic -y \
&& fc-cache -f
or
RUN apk add font-noto-gujarati font-noto-kannada font-noto-avestan font-noto-osage font-noto-kayahli font-noto-oriya font-noto-telugu font-noto-tamil font-noto-bengali font-noto-malayalam font-noto-arabic font-noto-extra \
&& fc-cache -f
Note: u can add more fonts name based on your requirement.
I need to perform smoke-test of my AngularJS application on Unix, from terminal.
I tried accessing application from
links2
links
w3m
elinks
lynx
All above-mentioned browsers show empty screen. In most of them I am able to view source using \ (backslash), so I could do basic verification if application server works properly at least.
Is there any unix text browser with javascript support? I am not looking for complete support (so application would be usable).
It would be great to have ability just to view some elements of the page
Try to install libmozjs (on debian/ubuntu aptitude install libmozjs185-dev), then (don't forget to do a sudo ldconfig first) compile from the source elinks.
wget http://elinks.or.cz/download/elinks-current-0.13.tar.bz2
tar xjvf elinks-current-0.13.tar.bz2
cd elinks-0.13*
./configure
make -j8
sudo make install
Check after ./configure if ECMAScript is flagged SpiderMonkey document scripting.
p.s. Ubuntu 14.04 here.
I guess the best way to do it would be with a headless browser such as PhantomJS http://phantomjs.org/. It has a programmable interface, so you can run a simple JS script to open your webpage, and do a simple check.
Or, you can write a more complete test using Protractor https://github.com/angular/protractor. It will give you a nice API to write tests targeting Selenium Webdriver http://www.seleniumhq.org/projects/webdriver/, that can target many browsers, including PhantomJS.
If you do a lot of AngularJS development you should take a look a Protractor anyway.
I have: gstreamer-sdk, gstreamer-ffmpeg, gstreamer-plugins-good, bad, and ugly. I googled everywhere for this error and have found nothing relevant. I'm going a little nuts trying to figure out this error:
Error received from element decodebin20: Your GStreamer installation is missing a plug-in.
Debugging information: gstdecodebin2.c(3576): gst_decode_bin_expose (): /GstPlayBin2:playbin20/GstURIDecodeBin:uridecodebin0/GstDecodeBin2:decodebin20:
no suitable plugins found
It throws when I run my gstreamer program. Any ideas on why?
You may not be missing any plugins at all.
This error can be a result of just an unlinked pipeline.
Playbin2(decodebin2) got some changes that made it unable to automatically link up some pipelines that formally worked, for example transcoding a decoder to an encoder. In my case, explicitly adding the ffdec_h264 that it used to add automatically fixed it.
Relying on the Playbin2 can be very frustrating when it does not work. Using the setup below, you can create a .png diagram of the pipeline in various phases of construction. It's very helpful in finding why it isn't linking up.
export GST_DEBUG_DUMP_DOT_DIR=~/gstdump
for f in $GST_DEBUG_DUMP_DOT_DIR/*.dot ; do dot -T png $f >$f.png; done
This tool also lets you learn from it how to link up pipelines, and replace them with explicit ones that are easier to debug and less likely to break.
In Fedora, I resolved this issue removing gstreamer1-vaapi.x86_64:
sudo yum remove gstreamer1-vaapi.x86_64
uridecodebin is part of the "base" plugin set, so make sure you have gstreamer-plugins-base.
Another thing to look into is your LD_LIBRARY_PATH and GST_PLUGIN_PATH. If they point to a different GStreamer installation, it could cause problems like this. Also, if you didn't install GStreamer with a package manager, you may need to set your LD_LIBRARY_PATH to point to it (or better yet, install it with a package manager).
Pleas try to use gst-inspect command to find out if environment is correctly setup.
use gst-launch -v playbin2 uri = "your_uri_here" to find more information to trace this issue.
I recently upgraded my system to snow leopard and now my prompt doesn't work properly. I have this line in my .zshrc file:
PROMPT='%{$fg_no_bold[cyan]%}%n#%{$fg_no_bold[red]%}%m%{$fg_no_bold[green]%}$(git_branch)%{$reset_color%}: '
(where "git_branch" is a function that give me information about the current git branch I'm working on). The problem is that the colors and "git_branch" function aren't being evaluated, they are taken literally, so my prompt is:
%{$fg_no_bold[cyan]%}username#%{$fg_no_bold[red]%}machinename%{$fg_no_bold[green]%}$(git_branch)%{$reset_color%}:
The colors are nice, but the part I'd really like to get working is the git branch info. I've been googling, but haven't found anything yet. I'm a bit of a noob when it comes to zsh, so links to helpful resources would also be appreciated.
zsh --version
zsh 4.3.9 (i386-apple-darwin10.0)
After looking at a bunch of config files I discovered that adding these lines:
setopt prompt_subst
autoload colors
colors
caused my prompt to correctly interpret my color codes again.