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.
Related
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.
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
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've followed the directions in Installing MacPorts.
To install MacPorts using the pkg installer. The installation apparently goes fine. For example, it goes through the multi-step process eventually saying "Installation Successful" or something to this effect.
And now there's just the "little" problem that neither of these commands work:
man ports
which ports
I've checked in /usr/local, /bin, and /usr/bin, and I don't see where this has been installed to. Ideas?
They're in /opt/local/bin, so as to not overwrite stuff that came with Mac OS X or that you might have gotten from elsewhere. They won't be in your $PATH until you close that Terminal and open another (nothing can alter the environment of a running program except the program itself).
It's in /opt/local/bin. MacPorts updates .bash_profile to include this in the path, but obviously existing shells don't see the updated PATH variable...
It's probably because you're trying ports but the command is called port: See http://guide.macports.org/#using.port
I have opensuse 11.4 installed. Vim is version 7. Now I normally use it to browse the linux kernel source. So I generated the cscope database inside a directory within my home folder i.e. /home/aijazbaig1/cscope_DB/ and I got 3 files viz. cscope.out, cscope.po.out and cscope.in.out besides the cscope.files file which contains a list of all the relevant files which I want to search.
Additionally I have added the following to my .bashrc:
CSCOPE_DB=/home/aijazbaig1/cscope_DB/cscope.out
export CSCOPE_DB
But when I do a :cscope show from within vim it says there are no connections. Can anyone please let me know what is going wrong.
Keen to hear from you,
This is mentioned in the comments above, but I want to make sure it's preserved in an answer.
The issue that came up for me was that vim didn't know where to look for the cscope database. When I added
cs add $CSCOPE_DB
to my .vimrc. Everything came out fine.
I figure since I've made the visit, I would try responding.
I was getting this error when searching using ctrl-space s (or any search for that matter):
E567: no cscope connections
I finally found the full solution at http://cscope.sourceforge.net/cscope_vim_tutorial.html, Step 11.
The idea is that you create a list of source files to be included in the view of cscope, generate the cscope.out in the same location, and update the export path accordingly:
find /my/project/dir -name '*.c' -o -name '*.h' > /foo/cscope.files
cscope -R -b (this may take a while depending on the size of your source)
export CSCOPE_DB=/foo/cscope.out (put this in your .bashrc/.zshrc/other-starting-script if you don't want to repeat this every time you log into the terminal)
You need to add a "cscope connection", like this in vim:
:cscope add $PATH_TO_CSCOPE.out
See :help cs for more examples.
Here's how I explore linux kernel source using cscope:
I use vim as my editor.
While standing inside the kernel source root directory, run cscope in interactive mode while recursively going through subdirectories during search for source files:
cscope -R
When run for the first time, it will generate the database file with the name: cscope.out inside the current directory. Any subsequent runs will use the already generated database.
Search for anything or any file and open it.
Set cscope tags in vim to make the :tag and CTRL-] commands search through cscope first and then ctags' tags:
:set cscopetag
Set cscope database inside current VIM session:
:cs add cscope.out
Now you can use CTRL-] and CTRL-t as you would do in ctags to navigate around! :)
I have the same issue on my PC. For now, to solve the issue:
On terminal execute: which is cscope
Open .vimrc file to edit: set csprg=/usr/bin/cscope
I ran into a similar problem with no cscope connections on ubuntu 18.04, then I discovered my .vimrc file does not load the CSCOPE_DB variable. Looked a little around and found a solution.
You can just copy this directly in to your .vimrc file.
Part of the code loads your cscope file from your directory. The keybinds are just a nice bonus.
Hope this helps.