Bugs in new version

[n10v]

1. Prompt starts with new line
2. Colors don't display correct

Shell: fish 2.2.0

[michaeldfallen]

how unusual.. can you post your GIT_RADAR_FORMAT (since I'm guessing you've used that feature to customise the radar) and your fish equivalent of PROMPT or PS1 (I don't really know fish at all).

[n10v]

GIT_RADAR_FORMAT = " (%{remote: }%{branch}%{ :local})%{ :changes}"
PROMPT = git-radar --fish

[michaeldfallen]

Probably you have a colour code applied to the folder part, the ~/nehm which isn't being closed and so the colour is continuing until the next $reset_color or \x01\033[0m\x02. I'd try adding \x01\033[0m\x02in front of your call to git-radar, that might fix it.

[lucas-clemente]

I've got the same problem since the last update (from homebrew):

I didn't change anything. My PS1 is

%{
%}$(build_prompt)%{%}

I don't know why there's a newline there, but it apparrently doesn't matter.

[michaeldfallen]

@lucas-clemente what does your PROMPT look like? PS1 is used in Bash, not Zsh so I wouldn't expect it to work for you.

Also, what does that build_prompt function look like? Like the one in your dotfiles?

[lucas-clemente]

$PROMPT is the same as $PS1 (maybe oh-my-zsh does that?). I didn't update my dotfiles in a while, but pushed the current version using git-radar now.

Also, while I'm in a git folder, git-radar returns the following:

~/D/test git:(upstream ⚡ master)
 → /usr/local/bin/git-radar --zsh
 %{%}git:(%{%}upstream %{%}⚡%{%} %{%}master%{%}%{%})%{%}
~/D/test git:(upstream ⚡ master)
 →

Dunno if the newline should be there or not? Thanks for your help! 👍

[n10v]

Use 1.3.2 version and I like it
No problems with it

[pkernevez]

I've exactly the same problem with the last version on MacOSx ElCapitan + fish.
All is good with bash, but I've the additional carriage return.
I have the problem with all default values and also with
set -gx GIT_RADAR_FORMAT = " (%{remote: }%{branch}%{ :local})%{ :changes}"
set -gx PROMPT = git-radar --fish

[n10v]

@pkernevez I have the same configuration
Honestly, I love previous version of git-radar. It suits me.
So I made a lightweight fork of it and it works great for me
If you interested in it, you can check it here: https://github.com/bogem/git-radar

[michaeldfallen]

@pkernevez that's really weird. I'm sorry it's not working well in fish. I'll install fish on a VM and test it out tomorrow (it's 11pm in London right now) and see what I can find out.

Do you have any weird versions of printf or sed? I use them extensively for string manipulation and they can cause issues if not the standard.

Can you run printf '%q' "$(git-radar --bash)"and paste in the output here? It should show us what characters git-radar is outputting.

My output is (on master and clean, no commits or changes): \ $'\001'$'\033'\[1\;30m$'\002'git:\($'\001'$'\033'\[0m$'\002'$'\001'$'\033'\[0m$'\002'master$'\001'$'\033'\[0m$'\002'$'\001'$'\033'\[1\;30m$'\002'\)$'\001'$'\033'\[0m$'\002'

If they match mine then it's not an environment problem. We'll then have to look at configuration and see what is different between yours and mine.

If they don't then it is an environment problem and I'll need to handle another slightly different version of a tool like sed or printf.

[michaeldfallen]

@pkernevez another comment as that was getting long:

My current guess is still that there's something screwy happening with the nonprinting characters and colour codes. It's based on the first characters being green.

The other option is there's a rogue printf or echo adding a newline where on my environment it doesn't do that.

Fingers crossed we can sort this out for you, sorry it hasn't been a painless install.

[pkernevez]

Hi Michael,

Form a bash shell in a clean master folder:

git st
On branch master
nothing to commit, working directory clean

printf '%q' "$(git-radar --bash)"
$' \001\E[1;30m\002git:(\001\E[0m\002upstream \001\E[1;31m\002?\232?\001\E[0m\002 \001\E[0m\002master\001\E[0m\002\001\E[1;30m\002)\001\E[0m\002'

There is differences with your, but I can't interpret these ones.

With bash the output is the same with --fish:

printf '%q' "$(git-radar --fish)"
$' \001\E[1;30m\002git:(\001\E[0m\002upstream \001\E[1;31m\002?\232?\001\E[0m\002 \001\E[0m\002master\001\E[0m\002\001\E[1;30m\002)\001\E[0m\002'

[michaeldfallen]

ok, I've set up a Centos 7 VM with a clean fish and zsh install. Using the config laid out in the readme I get exactly what I would expect out. No extra new lines at the end.

@BoGeM @lucas-clemente @pkernevez can you post your configs here and I will try to replicate the issues in the vm. If I can't by your config replicate it then it has to be environment, either versions of echo, printf and sed not acting as expected.

My Centos VM uses only GNU coreutils 8.22 versions of echo, printf and GNU sed version 4.2.2.

[n10v]

I have default config

[pkernevez]

I have a default installation too, but on MacOSX, not on CentOS.

On Thu, Nov 5, 2015 at 2:47 PM, Michael Allen notifications@github.com
wrote:

ok, I've set up a Centos 7 VM with a clean fish and zsh install. Using the
config laid out in the readme I get exactly what I would expect out. No
extra new lines at the end.

@BoGeM https://github.com/bogem @lucas-clemente
https://github.com/lucas-clemente @pkernevez
https://github.com/pkernevez can you post your configs here and I will
try to replicate the issues in the vm. If I can't by your config replicate
it then it has to be environment, either versions of echo, printf and sed
not acting as expected.

My Centos VM uses only GNU coreutils 8.22 versions of echo, printf and
GNU sed version 4.2.2.

—
Reply to this email directly or view it on GitHub
#73 (comment)
.

Philippe Kernévez

Directeur technique (Suisse),
pkernevez@octo.com
+41 79 888 33 32

Retrouvez OCTO sur OCTO Talk : http://blog.octo.com
OCTO Technology http://www.octo.com