This question already has an answer here:
Closed 10 years ago.
Possible Duplicate:
Why and where are \n newline characters getting introduced to c()?
I am running R (version 2.15.1) in a bash shell (version 4.2.36(1)) in the GNOME terminal (version 3.4.1.1). Sometimes I write my code in a text file and then paste it directly into the console (when running R). I didn't have any problems until the scripts I was pasting grew in length. Now, it appears that any code greater than 4206 characters (including \n) is rejected (i.e., the first 4206 characters are accepted and the remaining code is truncated; the truncation is accompanied by the terminal "bell" sound). This character limit is not specific to bash or GNOME terminal because I do not observe a character limit when pasting into e.g., vi. Therefore, I suspect that the character limit is imposed by R, but do not know how to change it, assuming it is a user-configurable parameter. Can the paste limit be changed and if so, what parameter governs it?
It looks like you're running into a known limitation of the console. As it says in Section 1.8 - R commands, case sensitivity, etc. of An Introduction to R:
Command lines entered at the console are limited[3] to about 4095 bytes (not characters).
[3] some of the consoles will not allow you to enter more, and amongst those which do some will silently discard the excess and some will use it as the start of the next line.
Either put the command in a file and source it, or break the code into multiple lines by inserting your own newlines at appropriate points (between commas).
The value is hard-coded in src/include/Defn.h : #define CONSOLE_BUFFER_SIZE 4096, so you would need to recompile R to change it.
Related
In 2001 German scene group Farbrausch released a demo called "fuenf" (in your face). pouet.net It contains a 5 Byte executable which could be rather considered a troll approach than a demo. If you run it your hear a weird sound and it could crash your computer. At least it produces a sound. Whatever.
The hexadecimal content is:
95cd 21eb fc
And the binary representation is:
10010101 11001101 00100001 11101011 11111100
Using xxd I also get the printable chars from the content, which are:
..!..
And that makes me a little confused. Looking up the values in the ASCII table (e.g. here), I get this as a result:
•Í!ëü
At least the exclamation mark is correct.
But how does 95cd21ebfc translate into ..!..?
Side note:
file -bi fuenf.com sais the encoding is not known:
charset=unknown-8bit
And iconv -f ISO-8859-1 -t UTF-8 fuenf.com returns
Í!ëü
Which leads to the assumption, that XXD simply cannot decode the content and therefore just uses default results, like the dot?
First of all, this is not a text file, so looking at it as one makes no sense. It's instructions.
Secondly, even if it could be interpreted as text, you would need to know the encoding. It's definitely not ASCII, because that only defines symbols in the range 0-127 (and the 3rd byte here is the only one in that range, which maps to '!'). The "extended ASCII" table you link to is only one of many possible code pages that give meaning to the value from 128-255, but there are many of those code pages. Calling it "extended ASCII" is misleading, because it suggests that ASCII created an updated standard for this, which they did not. For a while, computer vendors just did whatever they wanted with those additional characters, and some of them became quasi-standards by virtue of being included in DOS, Windows, etc. Or they got standardized by ISO (you tried iso-8859-1, which is one such standard).
I am using the R repl quite extensively to learn R.
The only problem is that if I type more than 80 characters, the R REPL beings to hide previously typed characters (in other words it will not show more than 80 characters... so always shows the last 80 characters)
it beings to show a "$" sign to indicate that it has gone past 80. see below
But I don't like this behavior and I want it to take the full length of the console whatever the windows/linux shell is set to.
can R shell behave like the normal shell where it rolls over to the new line if I type more than the configured width of the shell?
A similar question was asked a year ago, but the requirements were different (querent wanted R studio), and the solution package is not compatible with R 3.0.
I am using the R interpreter directly from the bash command line. I would like my scripts to output color text, ideally in a manner similar to how using a particular sequence of characters in C causes the color to be different.
More specifically, in C, we can output colors using printf as described in the answer to this question. I wonder if R 3.0.2 has a facility to do the same.
The ANSI sequences in the question you mentioned are processed by the terminal emulator so they will work fine in R:
cat("\033[32;1m OK \033[0m\n")
Note that \033 is (octal) code for escape symbol. It is one (non-printable) symbol which tells the terminal to start interpreting the control sequence. print when given \033 will output the four symbols \, 0, 3, 3 literally which, of course, tells the terminal nothing. See Wikipedia for the full list of ANSI escape sequences.
I connect to different types of computers every day. When I Telnet in, the first thing I do is run a command line script that is about 1150 characters long. I have no problem with Linux based systems, but if it is Unix based (ie IRIX), then my command is truncated at ~256 Chars.
The Final result of the Command will be a data dump (the results of the commands) to the Telnet window. This data will then be copied and pasted into a tool for analysis. Also the Command string that is being entered is a series of Commands (mostly egreps) separated by semi-colons, but when combined together it gets very long.
I need to be able to enter all 1150 Chars on the command line. The systems I access are not mine, So I need to be as Benign as possible when interacting with them.
Your Help is appreciated.
If its a parameter list thats making the command that long then xargs is your friend
I'm not sure if this is the answer you're looking for, but as you stated in your comment, all of the commands are less than 256 characters. So, you can break the commands up into 5-6 groups being sure to only separate at the semi-colon (not at pipes). Then execute each group in sequence. It's more work if your use to just copying and pasting, but not much if you already have the groups created in a text file.
I'm using the diff command to compare two text files. They need to be literally matched.
So I use the diff:
diff binary.out binary.expected
(By the way, those files are NOT binary files. They are text file. I call them binary because that's the name of the project)
and got
Binary files binary.out and binary.expected differ
When I use another diff tool, the smartest of all (AKA human), and there's really nothing different between the two files.
Does anyone happen to know what's going on here?
Thanks.
diff from diffutils says the following about text/binary:
diff determines whether a file is text or binary by checking the
first few bytes in the file; the exact number of bytes is system
dependent, but it is typically several thousand. If every byte in
that part of the file is non-null, diff considers the file to be
text; otherwise it considers the file to be binary.
hence GNU diff have a quite open definition of what is text, and the use of the --text option to force it to treat the file as text should seldom be needed.
Have you checked if binary.out or binary.expected contains null characters? What version is your diff program?
Make sure to ignore white space in the diff options.
It may also see Unicode characters and interpret that as binary. See if your diff tool has an option to force text mode.