If I trigger pry or byebug, eventually while using the live-debug mode the cursor will disappear, and input will become slow/laggy. Ultimately I have to Ctrl-C and kill the unicorn/puma process. After I've quit the process the terminal works, but the cursor is sometimes still missing/invisible. Then I have to close the terminal and open another. I've tried two different servers (puma/unicorn) and two different debugging tools (pry and byebug).
Hard to say if this is related to the debug tool, the rails server or my Terminal. I'm using Terminal.app with Solarized theme.
When the cursor disappears you can enter the command stty echo and hit enter. That should bring the cursor back.
Related
When I run \dt (and other commands of psql like \l) this thing appears. What is this? Is this an editor?
Most importantly, when I click Ctrl+Z, I get thrown out of psql completely. How do I exit it without exiting psql?
I am totally new to Ubuntu, so sorry if its a dumb question. Thanks for your time on advance!
You seem to come from Windows.
The pager that gets invoked whenever a query result does not fit on your screen is something similar to Windows' more, so you exit it by typing q.
If you don't want a pager at all, set the environment variable PAGER to an empty string:
PAGER='' psql
Typing Ctrl+Z will not send an End-of-file on Linux, it will suspend the current foreground process, which continues to lurk in the background. You can rescue it from there with the command fg.
In Rails console I entered an Active Record query, and it took up more than the whole screen, so it was scrolling. I forgot to hit q to get out of it and instead hit Ctrl-C. I got some errors, then I got some of the Rails console output, then I hit ^C again, then my prompt came up...
But I can't type anything. Well, actually I can type, but I can't see anything.
If I type exit it will exit the Rails console and get me back to my prompt, and then if I type rails c I'll get back to my console. Except none of the things I just mentioned typing appear on the screen when I type them.
And once I'm back inside the console I still can't see what I'm typing. I have to open a new terminal.
I've had this happen in a number of different scenarios, probably all where my reflexes exited a process the wrong way (like with ^C instead of q), and this is just the first one where I could pin it down.
Does anyone know how to fix this without having to scrap my work and open a new terminal?
Something you've typed, or something output from your query in console, has disabled or redirected the "echo" setting in your shell - so, you're still able to type commands, but you just can't see them. If the Active Record query returned binary data, it's quite likely that some bytes of the binary data happened to be an escape code that changed your echo setting. It's also important to realize that if your echo setting changed, it's quite possible that other settings have changed as well.
If you're at your shell prompt, you would just type the unix command reset to restore normal settings. However, if you're still in your Rails console, you'll need to type:
system 'reset'
to run that command from Ruby.
Type reset and press enter, it should be fixed.
I am using a BBB with the Debian distro. I access Cloud9 (192.168.7.2:3000) via Chrome on my Windows 7 machine. I am able to access existing demo js programs and have written a test program (myblink.js). The editor and overall system works fine.
But when I try to run the program, nothing happens for a few seconds, then eventually, it appears to stop on the first line (which becomes highlighted yellow). When this happens, the debugger panel pops out and the bottom window shows that the "debugger listening on port 15454" and I have the option to stop the program. At this point I can step through the program, well, at least to the point where there is some asynchronous events handling required.
However, if I run "node myblink.js" app from the bash tab in Cloud9 or from a shell (via putty) it works perfectly fine.
Do I have to set anything up to enable debugging? Or is it too much to expect from the debugger and a BBB system?
I am an absolute beginner with Ruby on Rails and I seem to have a problem with the way I should be doing things.
If I use "rails server" in order to be able to test my application, I can't do anything else in the command line.
Is there another way of doing scaffolding, other than command line? If not, how to I get two "Command prompts with Ruby" at the same time?
When you search for it from your metro screen, right click on it and then click on Open in a new window.
Open a new terminal tab before you start your Rails server, and then you can just leave it running in the background. However, do make sure you go back to that tab and specifically shut the server down before closing terminal as it doesn't always automatically shut down when terminal is closed and then you may have problems when reopening later.
I'm on mac osx using zsh. If I start a rails server with "rails s" I can put it in the background by hitting "ctrl-z" in my terminal (zsh).
If I open up a different terminal window then I don't see the rails server if I do "jobs". However, I can see it when I do "ps".
Is there a way I can somehow "unpause" the rails server in this new terminal window?
You can not easily move a process to a new tty. The easiest solution would be to start it in a screen session, detach screen and then resume in the new terminal.
The job is "stopped" by sending it a SIGSTOP.Your C-z doesn't send the job into the background. It "stops" it. You can then move it into the background using the bg shell builtin. However, if you send this process a SIGCONT (kill -CONT <pid>), it should bring the process back to the foreground. This can be done from a different shell.
You will not see it if you type jobs because it is a job controlled by a different shell (the other terminal window and not the one where you typed jobs). Processes however are "global" and can be seen from anywhere using the ps command (as you rightly pointed out).
Update: Looks like I spoke too soon. Apparently, the signal alone isn't enough to bring it back to the foreground. Probably something to do with the shell.