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.
Related
I try to be brave and switch from vi to emacs.
Now, I set up Emacs 26 on macOS via homebrew and start Emacs as daemon in the background.
I can use files using emacsclient -t. However, whenever I bring the Terminal into the background emacsclient exits within a few seconds.
See example Video here: https://cloud.familie-ganter.de/s/QwbK8cFBHnPjQ4d
I did a plain install. My init file does not contain anything except what you see in the video. The funny thing is whenever I start emacs directly in the Terminal, nothing at all happens when bringing it to the background.
What seems to be the problem?
I am lost …
I expect it to be something dumb and simple -- so please be nice, this is my first stackoverflow post.
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.
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?
I am trying to use Sublime Text + GoSublime to do Golang development.
I am working with a webserver in Go (ListenAndServe("8000", &handler)).
The problem I have is that when I run the Go process (while another one is running), the second process doesn't work (since the port is already in use).
What I want to happen is that when I go run web.go, if one was already running, shut that down before running this one.
Sublime Text 3's build system doesn't seem to keep track of the previous execution - so I don't know the best way to terminate. When I run CTRL+B it doesn't block, it executes the build system in another thread - meaning that I can't CTRL+C before executing the next. So what I'm having to do is terminate via the command line the existing process before starting the next one.
So I'm looking for either a solution with Sublime Text's build system configuration, or perhaps even having the Go process itself check to see if one is running and killing the process.
Ideas? It's sort of annoying to swap back and forth from terminal.
Not sure if I understand the question right.
But in sublime text build console, there is tskill command which can kill active tasks initiated from the console. So you can type Ctrl+B to invoke out console and type tskill to kill the running web.go task. There are also other alias tskill <task ID>, task replay or task go. Reference is here. After that you can run other commands including go run.
What's more there is a replay command. "It is like run but attempts to cancel any active executions before running". I feel it looks like what you want.
Further, Gosublime command shell has sh command mode. It's much flexible for example type sh killall web;go run web.go or run a shell script to run that.
Hopefully it helps.
I used the command tar -x file.tar.gz and, for one reason or anything it failed. Then I get stuck being able to type anything in, but not being able to run any more commands. Pressing enter just gives me a new line. I don't know how to break out of it either (escape etc doesn't work). The only way I can get back working is to close putty and reconnect.
Is there a way to get it back to normal so I can keep going because it's irritating closing it all the time.
Try hitting CTRL+C :) This will cancel/kill/stop the running command!
But the best way to untar is to use -v to verbose the output :
tar -zxvf yourfile.tar.gz
With that, you'll perhaps see that your file just take more time than you thought unarchiving ;)
Ctrl-C can be used to send a break to the executable that's hanging, but it's up to the application to handle it. Ctrl-Z will break you out of the running executable, but you'll need to then manually kill the process.
What you're doing wrong is you're not gunzipping the archive.
Try this
tar -zxf file.tar.gz
If you want to quit it, press CTRL+c.
If you want to keep it but being able to write more commands while it's working, press CTRL+z and bg.
Then it will work in the background.
Your command failed because it is trying to read stdin. This is because you never told it the name of the tar file with an "f" option.
A good Idea would be to use GNU screen. That way, when a command hangs, you can open another screen and take a look at the system (e.g. top to see if tar is still working) or you could kill the process by pressing (strg+a) + k to hard-kill the running process within the screen-session.
Screen also has the nice feature that your processes keep running even though your SSH-connection died. It's a lifesaver!
Your tar invocation is waiting for input on the command line as the others pointed out. You may also use Ctrl-D to indicate EOF to the tar process.