I'm seeing a very strange issue with R (v 3.3.2, running on the command line of a CentOS 7 linux box). If I execute a command that goes over one line in the terminal, the output appears at the beginning of the second line of the command. This didn't happen with previous versions of R, though it does happen with later versions I've installed. I am using Putty as the terminal, but it also happens if I use xterm.
To describe it better, it looks like this:
> tmpvaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaal=1 [before hitting enter]
> tmpvaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
> aaaaaaaaaaaaaaaal=1 [after enter, typing overwrites the a's now]
If the multiline command outputs something, that output occurs on the second line and overwrites the a's. If there is an error, then the error message terminates properly and the next prompt follows the error message. So does anyone have any ideas? Thanks in advance!
Update: After some more experimenting, I've found another odd behavior. If I use CTRL-R to search for a previous multiline command, and then execute it, the output or subsequent prompt appears at the same location in the command as where the cursor was. Here's another example:
(reverse-i-search)`1':tmpvaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaal=1[cursor on one before hitting enter]
[hit enter and then:]
>tmpvaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaal=1
aaaaaaaaal=>
Pretty strange. Hard to describe so its hard to find any evidence of other problems like this on stack-exchange or elsewhere. My feeling is it has to do with the readline library but it is strange because this doesn't happen in the shell command line, only in R as far as I can tell.
Update 2: I've found a potentially more revealing way to replicate this issue. If you manually add a bunch of newlines (by jamming CTRL-V CTRL-J repeatedly), then hit enter, the next prompt jumps right back up to underneath the last one. This is not what happens in the underlying shell (bash for me), or in previous versions of R that I can check.
Just to have the answer out there in case anyone else has this issue, the problem was that my system was using an old version of the readline library, 6.2, and the issue disappeared when updating it to the current version, 7.0. So it would seem that even though later versions of R will install with the outdated readline, they don't exactly work correctly.
Related
I have just switched from windows 7 to windows 10 on my pc.
When I was still using windows 7, using the combination CTRL+R or CTRL+ENTER would run the line of code that I was in. Moreover, if the code continued on one or more lines below or started above my current line, it would run the entire section without me having to select it.
After switching to windows 10, the same combinations will only run the line of code that I am currently in, or the piece of code that is selected by me. To give an example:
#Tryout
for(i in 1:3){
print(i)
}
This code would normally run at once without having to select it, even when I would start in the first line (#Tryout). Now, if I don't select, I will need to use CTRL+R or CTRL+ENTER three times to go through this code and I have to start in the correct line. Starting in the line #Tryout will not run any part of the code but will only result in the line #Tryout being shown in the console.
I'm not good with computers (in your answers please pretend to be adressing a five-year-old) so I had one of my colleagues look at it who's our expert on R. Here are the findings:
The problem occurs in both RStudio as the standalone version of R.
I'm using R version 3.3.2, the same as before the windows update. Switching to version 3.5 didn't solve the problem.
I have other colleagues also using R 3.3 in combination with windows 10 for whom this problem does not occur.
Going to Tools-Global Options-Code and checking the box of 'Focus console after executing from source' doesn't help
When we went to 'Modify Keyboard Shortcuts', the name attached to the shortcut (CTRL+R or CTRL+ENTER) was the same as it was for other colleagues for which the function does run all lines in a command: 'Run Current Line or Selection'
The problem is not preventing me from using R, but it is tedious and I hope someone can help me to solve it.
Thanks so much for reading!
Click on header Tools, then Global Options..., then Code, then Ctrl + Enter Executes and choose Multi-line R statement
#M Waz & #Just Burfi: I know I can select the code and then run it, that works fine. But I don't want to have to manually select the code all the time.
#Clemsang: your answer puzzled me for a moment because I didn't have the CTRL + Enter Executes that you were referring to. I went back to my colleague who had the bright idea to check the version of RStudio that I was using.
As it turns out, I was using an old version (0.99.903). Now that I've installed a newer version (1.1.463), running the code works as before! I also have the CTRL + Enter Executes now.
I'm doing some very basic commands in RStudio (in Windows 10), and suddenly/randomly the command prompt ">" disappeared. This is not the first time this has happened for me. Pressing escape, enter, or anything else doesn't get me back the >. Moreover, when I try to close RStudio, it just stays on "quitting r session" and never closes. I tried to embed a screen shot of the console I'm seeing, but I'm not sure if it worked. If anyone can help me with this issue (being able to get back the > and execute commands again) or direct me to another post where this was addressed, I would really appreciate it (otherwise I have to restart my whole system every time to fix it).
The problem is that when I run the code, there's no return in the console; I mean it does run the code, but does not return any output.
For example, if I write
v <- c(1, 2, 3, 4, 5)
v
I would expect in return
[1] 1 2 3 4 5
But it's not working.
I have version RStudio Version 0.98.1079 and R Version 3.1.1
Possibility 1 (until the + sign was mentioned): I was wondering if you had been doing a tutorial where they were demonstrating the sink function and you hadn't gotten to the point where it was reversed.
> sink('out.txt') # diverts all output to a disk file
> v <- c(1,2)
> v # output went to file
> sink() # sets the output back to the console
> v
[1] 1 2
Another way would be to call closeAllConnections:
> sink('out.txt')
> v
> v
> closeAllConnections()
> v
[1] 1 2
Possibility 2: To address the lack of response with a "+" showing at the Rstudio console ... that is a sign that the R parser "thinks" the entered text has not completed a full R command. It may indicate that you haven't typed a closing bracket or parenthesis. If typing one or two of those is unsuccessful and you keep getting mor +'s then you may be successful with typing the [esc]-key. If it is showing up immediately after a restart then you should check your code for correctness and make sure that the .Rdata file is deleted from your working directory. If you don't know what that means then you may need to search for the methods appropriate to your operating system. You could also have an error in the code of one of your .rprofile files.
In any case these two possibilities have nothing to do with Rstudio per se and everything to to with the typical behavior of an R console session in pretty much any IDE.
Do the lines still start with a "+"? It is also possible you forgot to close the brackets of a function. Try "}".
I had the same issue and none of the tips mentioned here were working.
Session > Restart R did the trick for me, possibly suggesting that I had a similar problem as andrewH but was not patient enough to wait for R to behave again.
This is a very old question, but I just had the same problem with a different cause, so I thought I would describe it here case it should be useful to someone else. I was getting the regular command prompt, with nothing more, no matter what I typed at the command line. I tried multiple returns, escape, sink, traceback, closeAllConnections (which did give me a response, "error: unexpected ) in (), but then went back to the command prompt and ignored a second traceback).
Anyway after half an hour or so of pulling my hair out, up pops "View(Mid2)". Mid2 is a tibble with 8.5 million observations of 88 numeric variables. I must have tapped it in the environment pane accidentally. I suppose it just took that long for the viewer to render it. I assume that all the other things I did hit at once, because RStudio crashed immediately thereafter.
The interesting thing about this particular version of the problem is what didn't happen. The red stop sign in the upper right of the console window, that lights when R is busy, didn't light. That is unfortunate -- but understandable, if the RStudio viewer is a different process. But also, when my computer is working hard on a really big computation or IO task, the fan usually starts, but it didn't. Don't know why. . I took its absence, incorrectly, to mean no such computation was underway.
If the lines in console are starting with "+".
Save your work and close the 'RStudio' or other tool which you are using and Start it again, it worked for me.
If you are using R Studio Cloud, refresh or re-opening won't work.
Only clue from the above posts or answers is your console will always start with '+'
In my case I tried all possibilities of closing braces.
And ")" worked for me when I typed that into the console and press enter.
sink() function did nothing in R Studio Cloud
A simple mistake might have also caused this problem:
A rather lengthy command left abandoned in the console is blocking the appearance of the result line.
Thus, the console only shows that line, but the result from any code run from the source, will not appear.
To solve this, just switch to the console, remove any remaining command and try again.
Experiencing something like that explained here as an unresponsive console to the R-Code running was just devastating for me when I experienced it. But luckly although I tried every trick explained in this page, it did not work for me. At last I clicked on the "To console" option available just below the Environment, History, Connections, Tutorial Tab on the R Studio. It solved the puzzle for me just now.
The best solution I've found is closeAllConnections and/or sink which almost always work
But as a stop gap measure, View()'ing always works. It's sort of a pain but whatever you wanted to print out, surround by View and you can see it
I am using R 2.15.2 on windows XP.
I was used to use Rgui.exe but it was lacking the UNIX standards I like to use like CTRL+R <=>backward research and CTRL+U <=>erase line ...
If I missed something please tell me !
Then I tried Rterm.exe (which looks identical to R.exe to me) which has all those nice features. I found how to tune it right clicking on the top of the window to set height-width (it is like tuning the window you get from cmd.exe).
The problem is that now I cannot see on the window more than 75 characters, with a $ at the end: like this:
R) ppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppp$
Not sure if it is a R option of a windows one, but if I set options("width"=180) I can see data.frame on the full width of the window...
Not sure what is happening, can I modify this?
We still do not know the answer to that one, so I guess 50 pts goes to Oscar de León... good for him to bad for me...
Sadly, it appears to be built in.
There used to be a problem with R when trying to print long strings. Apparently it was fixed first in Rterm and other versions of R before being fixed in Rgui.
When Rgui was fixed, possibly it was by a different means, since this issue can be fixed in Rgui but not other windows versions of R. You can change the width of the console for output both in Rgui and (later) Rterm.
The prompt is another story. It is actually not the same as the output space, and thus is controlled with a different option; but, this only works for Rgui. To do it, set pgcolumns=180 in the Rconsole file under [R HOME]\etc\. This modifies the width of the internal pager of the Rgui console, and effectively enables you to type up to 180 characters per input prompt.
Possibly there is a way to integrate that behavior into Rterm, and maybe Duncan Murdoch can point you in the correct direction (or prove me completely wrong).
I'm not really sure what is being requested. If what is needed in RTerm.exe is to display the end of a long line (and position the cursor there), then use CTRL-E. You can go back to the beginning of a line with CTRL-A. One can go back and forth repeatedly as needed until the line is use ENTER.
The control character of readline seem to be active, for instance CTRL-P scrolls back one command and CTRL-N brings up the "next" command from history if you hit CTRL-P too many times. (These are the same behavior as the up/down arrow keys.) See link for other expected readline behaviors.
On my machine alt-f and alt-b (which should have been meta-f and meta-b) did not natively move forward or backward by words, but ESC-b and ESC-f did so on a line that exceeded the console width and had the $'s marking either the right or left extents as having further material to look consider.
If you want to wrap display lines, then you need to consider alternatives or additions to readline: link, but that is an untested suggestion and merely the results of a search for: "readline wrap display".
The command should be options(width = 180) (without the quotes around width), but when you run Rterm in the Windows shell, it doesn't respect changes to this value; it just prints output as wide as the console.
The best way of working with R is (almost always) to use an IDE. Try emacs + ESS or one of the many vim plugins (R.vim, vim-R, VIM:r-plugin) if you want something UNIXy.
I'm using R on OS X 10.6 and I prefer the unix console to the R.app for my work. If I issue a help command eg ?print the help content opens through a pager (i tried most and less), which however then hides out the content if I exit it bringing me back to the R input line.
What I really want is that the pager output stays on the screen even after I exit it back to R (hitting q).
I get this desired behaviour on other Readline-based Cli like psql for example, but not on R. Any hints on how this gets configured would be greatly appreciated.
The console pager that R uses can be set with the options function. With less, the -X option suppresses the terminal clearing at exit. So, if the less binary is located in "/bin" (not sure where it's located in OS X), this should work:
> options(pager="/bin/less -X")
If you want this to be the default behavior every time you start R, you can place the above command in your ~/.Rprofile file, which is run automatically at startup.
Alternatively, you can set a export LESS=-XF in ~/.bashrc and this will have an effect across all programs that use less as a pager. The F option would further exit straight away if the content is less than a page, which I find quite useful.