I was working on bash to install a node module (which was my first command since opening it today). Didn't install quite right so since I knew that was my first command I went about looping back to that command and instead I noticed that it didn't stop going beyond that. Went as far back as November/December commands and stopped there. Is this a bug, a known bug, or something wrong with my installation?
Git version: 2.21.0.windows.1
Not a bug. That's bash saving history of sessions when you write exit. The amount of history you want to save when this happens can be set with the variable HISTSIZE.
Related
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.
I encountered some bizarre Bash behavior today, and maybe it's a bug that's since been fixed, but I'm going to ask about it anyway.
I have an x64 Cygwin install on my work computer with Bash 4.3.46 in it. By accident today, instead of typing !533 to run an old command in my history, I typed ~533. That should have just displayed nothing, since I had an empty directory stack.
But instead, ~n seems to freeze Bash, for any number n. Open a brand-new MinTTY with Bash in it, type ~1 and hit Enter, and Bash just disappears into la-la land. Ctrl+C, Ctrl+J, Ctrl+Z, Ctrl+anything can't get you back to a prompt. Characters you type are echoed to the console, which is mildly interesting, since something must still be echoing them. But you can't recover the shell, and you can't even close MinTTY normally — you have to force-kill the Bash process ID.
It's worth noting that dirs +1, which is supposed to be the equivalent of ~1 (per the Bash manual), works just fine.
I can reliably reproduce this on my work computer. Interestingly, Cygwin Bash 4.4.12 on my home computer works right, so this may be a bug in the 4.3.x versions that they fixed in 4.4.x. If it is a bug, I'll definitely upgrade.
So is this broken tilde behavior a bug? A misconfiguration? Has anyone encountered this behavior before?
Often when I (re)activate the mingw-64 git bash window and start typing a shell command, the first character that I type is not captured. This results in an incorrect command, which I have to fix before I can execute it. Since I use the git bash a lot, this buggy behaviour really slows me down and frustrates me.
I cannot consistently reproduce the issue, it just occurs at random, after I haven't used the git bash for a short while. When I paste a command into the git bash window, the same may happen: i.e. the first character in the pasted command is omitted.
I'm using git version 2.6.2.windows.1 together with the mingw-64 git bash that comes with it.
I can't imagine I'm the only one with this problem. Has anyone found a solution to this?
I am using a bash script to run a number of application (some repeatedly) on a Windows machine through cygwin. The script contains commands to launch those applications, line by line. Most of these applications run for many minutes and many times I have observed that the i+1 th application is not being started even after i th application is completed. In such cases, if I press enter in the cygwin console on which the bash script is running, the next application starts running. Is it because of any issue with bash on cygwin? Or is it an issue with the Windows OS itself? Have any of you observed such an issue with bash + cygwin + Windows?
Thanks.
I think I have seen this before.
Instead of
somecommand
try
somecommand </dev/null
If that doesn't work, try
cmd /c somecommand
Or experiment with other redirections, e.g.
somecommand >/dev/null
Sounds like you may have a problem with your shell script encoding; DOS (and Windows) uses CR+LF line endings, whereas Linux uses LF endings. Try saving the file as LF.
What might also be going on:
When I was running Cygwin on a school laptop, I encountered a dramatic slowing of shell scripts vs. when they were running in a native Linux environment. This was especially apparent when running a configure script from GNU Autotools.
Check your path for slow drives. (From the Cygwin FAQ):
Why is Cygwin suddenly so slow?
If suddenly every command takes a very long time, then something is probably attempting to access a network share. You may have the obsolete //c notation in your PATH or startup files. Using //c means to contact the network server c, which will slow things down tremendously if it does not exist.
You might also want to check whether you have an antivirus program running. Antivirus programs tend to scan every single executable file as it is executed; this can cause problems for even simple shell scripts that run hundreds or even thousands of individual programs before they run their course.
This mailing list post outlines what is needed to pseudo-mount the main /usr/bin directory as cygexec. I'm not sure what that does, but I found it helped.
If you're running a configure script, try the -C option.
Hope this helps!
Occasionally, I'll get this behaviour because I have accidentally deleted the 'she-bang' at the top of the script, that is, deleted the #!/bin/bash on the first line of the script.
It's even more likely for this to happen when a parent shell script calls a child script that has the she-bang missing!
Hope this helps.
A bit of a long shot, but I have seen some similar behaviour previously.
In Windows 2000, if any program running in a command prompt window had some of it's text highlighted by the cursor, it would pause the command running, and you had to press enter or clear the highlighting to get the command prompt to continue executing.
As I said, bit of a long shot, but accidental mouse clicks could be your issue...
Install cygwin with unix style line breaks and forget weird problems like that.
Try saving your script as "the-properly-line-broken-style" for your cygwin. That is, use the style you specified under installation.
Here is some relevant information:
https://stackoverflow.com/a/7048200/657703
I have just installed darcs 2.1.2.2. When I type darcs help, sth less-like shows up. When I dismiss it with q it goes away but I don't get prompt and can't execute any commands. C-c doesn't work either. I am using bash on gentoo.
I have no idea what darcs is, but when bash fails to return to the prompt that some command as part of a pipeline is still running. For instance if you ran:
cmd | less
And exited less, but cmd did not die from a broken pipe, then cmd would continue to run and bash would continue to wait until it exited. It also might not respond to signals and keypresses if it didn't have access to the tty.
You will need a second terminal to check and see if any processes are hanging around after trying to dismiss darcs. Sometimes Ctrl-Z or Ctrl-\ will work where Ctrl-C doesn't. There is probably no fix other than to look at darcs and figure out why it is not dimissing like it should. If it is really launching less, then maybe typing ">" before "q" will make it exit properly.
In this situation (terminal messed up, can't see what you're typing) the "reset" command will often fix things.
I would try again with a newer darcs, eg version 2.3 released today. If the problem still happens, you can probably change this behaviour - see the darcs manual. Otherwise, folks on the #darcs irc channel will be able to help.