I have looked at duplicate questions. Nothing has worked.
I use Gitbash, and when using Cygwin, I source the gitbash prompt (/Git/etc/bash.bashrc) to display the same prompt. In Gitbash, the prompt works. In cygwin, the output line wraps. For example:
[ "$python_version" ] && python_version='\[\033[95;38;5;227m\]🐍'"${python_version##* } "
This line causes a wrap (only in cygwin) when appended to PS1. The minttyrc and color settings are exactly the same. Removing the color, which I think is the problem, fixes the wrap. However, I believe everything is escaped correctly, and as it doesn't wrap in gitbash, I don't know what the problem is.
The color here seems to be the issue, as removing it fixes it. But why? What is so different about the terminals? I also wonder if it could be an issue with an early escape, but PyCharm's shellcheck says it's all fine.
Wrapping example:
Cygwin:
⬢14.7.0p/new 🐍3.8.3 (venv) ❯
GitBash (ideal output):
~/Desktop/new 🐍3.8.3 ⬢14.7.0 (venv) ❯
It only occurs within the prompt (PS1 variable, aka PROMPT_COMMAND); not when actually typing out commands in the terminal.
Answer: Cygwin is trash (excuse the exaggeration). It has so many utilities but many have encountered bugs like this, and it is really a shame. I uninstalled it, removed its variables from PATH, and with C:\Program Files\Git\bin added to such, I could now ssh in using ssh -t user#host bin "bash -l". This gave me a correct prompt, in ssh or not, with no wrapping; I was able to install other utilities, such as g++, using MinGW. I hope Cygwin gets things sorted out soon, as I debugged in every single way; changed no code, uninstalled it, and then had a successful output.
Related
I have a complicated prompt. Very. I use git-bash for windows.
SSH-ing in on gitbash sends me to the CMD prompt. I know to type ssh -t user#host "bash -l" to get a bash prompt. It works, however, I use a repository called gitstatus to speed up the parsing of the git commands, and sshing in using bash -l calls the PS1 set in /c/cygwin/etc/bash.bashrc (for Mintty), NOT ~/bash.bashrc (for GitBash). This initially seems fine, as I can just copy paste the code from the GitBash *.bashrc to cygwin's. However, the gitstatus repository only works on bash terminals, aka not Cygwin/Mintty, so the prompt when I ssh in appears quite slower in git repos (Mintty doesn't allow gitstatus to be sourced and speed up parsing, once again) than if I was not SSH-ed in and using the GitBash-sourced prompt.
Are there any work arounds for this? I have seen many simnilar questions here but none have provided me a solution.
If you're in my situation, just source the scripts (duh). If you can't execute foo in file x when it should do the same thing as bar in file y, just source bar from file x. It seems obvious but took me a moment.
ALSO: Make sure to run dos2unix.exe on admin command prompt to remove carriage returns every time you make a change.
Recently I installed Zshell instead of Bash. During this, then I saw that my $PATH was 7 miles long, - so I decided to try and clean it up a bit. When I uninstalled rvm (by running rvm implode followed by rm -rf ~/.rvm) then when I restarted my terminal, I now see an error:
If I just press ENTER, then the error remains. But if I do any other command, then it disappears (ls, echo, source ~/.zshrc - you name it).
If I reboot iTerm (or start a new tab), - then the error re-appears.
The error is not being showed, - so if I activate another theme, then I can't see if there is an error.
My gut feeling tells me, that it has something to do with my path, but I'm not sure. My path is waaay shorter than before RVM was installed.
If i rename my ~/.zshrc-file, then the Powerline9k-theme gets deactivated, so I can't see if the error actually still appears or not. But I have tried it... Then a theme-less zshell just start up.
Any idea how to fix it or how to debug it?
EDIT
I just realized that it could actually have been a left-over-error, from back when I was running bash, - so I added that tag as well.
If the visual blemish disappears as soon as you execute any command as you say so, just place an echo -n at the end of your .zshrc as a quick and easy fix, if you are not up to the task of debugging and potentially causing more problems on your machine.
The issue isn't worth your time ;)
Edit: Apparently the above didn't work. See comments.
If you are interested in debugging, a good starting point would be to place set -xe (print every line that is executing and abort on any line that exits nonzero) at the beginning (after the shebang line, or as flags in the shebang) of each configuration script that is executed when you start a new interactive shell.
Also consider set -xeuo pipefail to additionally catch and abort on usage of unset shell variables and commands that return nonzero inside pipes (e.g. set -e will not abort on false | true because the overall line exited with status 0, but -o pipefail will abort on such a line). It is worth noting that these flags are bash features, but since zsh is a feature superset of bash, they work in zsh too.
Have look at their documentation on github, relevant fragment is here.
Solution:
In your ~/.zshrc find variable called POWERLEVEL9K_LEFT_PROMPT_ELEMENTS and remove rbenv.
Explanation:
The default value of POWERLEVEL9K_LEFT_PROMPT_ELEMENTS is (context dir rbenv vcs), and it is likely that rbenv is the segment producing the error - after you uninstalled rvm that segment can't execute.
Uninstall all apps that use the path and reinstall. It's the only way. Instead of rm, you use should create an alias that has a trash can.
Both my office and home computers have Git Bash for Windows from the very same source (Git for Windows, that came with TortoiseGit), but Git Bash's prompt differs on both machines:
on office computer I have /c/path (branch) all green (this is, how I would like it to have),
on home computer I have only path (no branch) and all white.
Up until now I was told, that this is PS1 variable, kept in ~/.bashrc file. However, on both machines, this files is missing (executing notepad ~/.bashrc opens up empty Notepad).
I'm lost here. If ~/.bashrc doesn't exists, then from where Git Bash "knows", that it should display current branch, in a green prompt? And why the same doesn't happen on second machine?
EDIT: I also tried to compare c:\Program Files\Git\etc\ folder contents for both machines and contents of Git Bash.vbs file. There identical on both computers so I even more have no idea, how it can be, that Git Bash's prompt differs on both computers (and how to fix this).
Several answers (like this, this and this) has suggested me, that I should look for .bash_profile and .bash_prompt files. Unfortunately, these two also are missing on both my computers.
Exactly what file decides about that under Windows 7? Where else should I look for, and what PS1 variable's value should be, to have current branch shown in green prompt on both machines?
Git on Windows almost always uses a bash shell. So, it's not Git setting the prompt as much as Bash does.
There are two ways to set prompts in Bash. One is the PS1 command which is fairly flexible, but is limited to a particular set of escape character sequences. Unfortunately, Git information isn't one of those escape sequences (although I suspect it'll come someday). You can use the second way to set the prompt by setting the PROMPT_COMMAND environment variable. If this is set, the $PROMPT_COMMAND is executed and used as the prompt instead of the PS1 environment variable.
When you install the standard Git with BASH, you're Git prompt is defined under the /etc/profile file. By the way, etc is a directory under where you've installed Git which is usually under %PROGRAMFILES% unless you changed it when you installed Git.
Under the /etc/profile script in line #156 in my version, you see the PS1 command being set and using $(__git_ps1) in $PS1 as a means of executing an external command in the prompt. (A third way I didn't mention previously).
The __git_ps1 is a shell function. You'll also notice a bit above (line #154 in my version) that /etc/git-completion.bash is being sourced in as well as /etc/git-prompt.sh. It's /etc/git-prompt.sh that defines the __git_ps1 function (Line #273 in my version) is defined. You'll notice that the __git_ps1 function pulls in several other functions defined in /etc/git-prompt.sh.
So, in a very Rube Goldberg manner, the Git prompt is being defined in /etc/profile via defining $PS1 which pulls in /etc/git-prompt.sh which defines a __git_ps1 function that pulls in the __git_ps1_show_upstream function and the __git_ps1_colorize_gitstring function. Then, $PS1 uses the $(...) string as part of pulling in the __git_ps1 function into PS1.
You can define your own $HOME/.bash_profile to override the way the prompt is set to define your own prompt. And, when you do that, you can also use the __git_ps1 Bash function in your own prompt.
Or, you can simply decide not to touch anything, and just back away very slowly. After all, you may have actual work to do.
On my Windows 10, __git_ps1 is defined in :
C:/Program Files/Git/etc/profile.d/git-prompt.sh.
I faced similar issue and realized that accidently I had added ${HOME} variable under environment/system variables(This PC) in my windows 10 64 bit pointing to my unixhome path. Once I removed it, the issue got fixed. My Git Bash prompt is back to how it used to look.
I would make a comment if I would have enough reputation,
but my guess is that the bashrc is not in your homefolder: ~/ but in the all users or general user folder(I dont know how it is named exactly). Look under your users where all users are located and search for .bashrc.
Look here : C:\Users\All Users
or: C:\Users\Default User
I have made a few python scripts, but is there an easier way to run them? I am using cygwin.
python "C:\Users\Desk\Dropbox\scripts\wsort.py" > data11414_unsorted.txt < data11414_sorted.txt
I want something like this (not typing the path name or "python"):
wsort > data11414_unsorted.txt < data11414_sorted.txt
where wsort is a link to my real wsort.py
Add a
Shebang
to the script
#!/bin/python
then invoke like this
wsort.py > data11414_unsorted.txt < data11414_sorted.txt
First, your question has a Windows-style path (backslashes, beginning with C:) rather than a Cygwin path (/cygdrive/c/Users/Desk/Dropbox/scripts/wsort.py). That implies you're not actually using Cygwin, or if you are, you're ignoring a bunch of warnings.
The below assumes you're using Cygwin Bash (which should be what you get if you start Cygwin Terminal from the Start Menu) and Cygwin Python (which you've installed using Cygwin's setup.exe, not a Windows Python installer). If your not, you're making life more difficult for yourself than you need to.
That out the way, there's a bunch of steps you need to take:
First, make the script executable. Use the chmod command for that, from a Cygwin Bash shell:
chmod +x /cygdrive/c/Users/Desk/Dropbox/scripts/wsort.py
Second, tell the system how to execute it. Add the following line to the top of the script:
#!/bin/python
(That's a "shebang". Python sees it as a comment, so doesn't do anything with it, but Cygwin and other Linux-like systems will use that line to see which program to run the script with. In this case, Python.)
Third, make sure your line endings are correct. Cygwin expects Linux line endings and will fail without them. This may not be a problem, but there's no harm in doing this. Run the following command:
dos2unix /cygdrive/c/Users/Desk/Dropbox/scripts/wsort.py
At this point, you'll be able to call the script by specifying the full path to it in Cygwin. You can't yet run it without specifying where the script is explicitly.
The fourth step is making sure the script is "in your path", ie in one of the folders where Cygwin looks for scripts to run. There are lots of ways to do this, but the most sensible is probably to just add your scripts directory to your path. The following command will add your scripts directory to your path whenever you start a new Cygwin session:
echo 'PATH="/cygdrive/c/Users/Desk/Dropbox/scripts:$PATH"' >>~/.bashrc
You will need to restart your Cygwin terminal for that to take effect, however.
At that point, you'll be able to run the script in Cygwin just by typing wsort.py (and thus use it with redirections and so forth as in your question).
Finally, to be able to call it simply as wsort, there's a number of options. The obvious one is just renaming the file. More usefully (and without copying the file or doing anything liable to break with Dropbox syncing things), try creating an alias:
echo 'alias wsort=wsort.py' >>~/.bashrc
Again, you'll need to restart your Cygwin terminal for that to take effect.
Maybe use an alias ?
alias wsort = "Command_Used"
I'm using msysgit 1.7.7.1 on Windows. I get an error when using git diff. What is causing this? Is there no diff tool included in msysgit? What should I do?
WARNING: terminal is not fully functional
If you are having issues in cmd.exe, for instance, see the warning here:
Then simply set your environment variables and include TERM=msys. After that, each time you open a cmd.exe, your variable will be set correctly.
NOW YOU MUST RESTART YOUR SHELL (CMD.EXE). Just run a new one. And from there, you should have no more issues. Again:
For Git Bash, this can be fixed by adding the following line to ~/.bashrc:
export TERM=cygwin
-or-
export TERM=msys
The first seems to be the original by git for windows, the second a popular known form to "heal" as well.
The problem can be caused if some other program (like for example Strawberry Perl) sets the TERM system environment variables.
http://code.google.com/p/msysgit/issues/detail?id=184
Above answers was not fully worked for me, so I did:
Add
export TERM=msys
to "[githome]/etc/profile" at the top but it made changes only for git bash. Then I added
#set TERM=msys
to "[githome]/cmd/git.cmd" after #setlocal (I installed only git run from command line). May be this decision not truly good but it works for me and there are not any terminal warnings. (I use git version 1.7.10.msysgit.1).
The answer can be found here, in which the author of the solution claims that:
the environment variable TERM was set to dumb
that was instead of
TERM=cygwin
You can change that to
TERM=msys
to solve the problem at hand.
I work in powershell and I have the git executable directly in my path.
None of the suggested answers worked, but I found a solution that works for me.
I added a line in my powershell profile:
$env:TERM="msys"
Which fixed the problem for me.
A quick & dirty solution in my case turned out to be to use the --no-pager option.
By default, some git commands (like log) will use a pager like less if they expect the output to be long. Pagers require things like scrolling text up and down with the arrow keys, which sometimes doesn't work if the assumptions about what kind of terminal you're on are wrong (this is what the "not fully functional" means).
If you know ahead of time that your output will be short, or you just want it to dump output to the terminal and leave the scrolling up to your terminal program, you can override this and not use a pager at all, e.g.:
git --no-pager log
In case someone gets this launching bash from Git Extensions, check the setting for Path to linux tools.... Mine was set to C:\cygwin. Changing it to C:\Program Files (x86)\Git\bin\ fixed it for me. I didn't have to set the TERM variable to launch bash this way.