Displaying 20 results from an estimated 4000 matches similar to: "Guidelines when to use LF vs CRLF ("\n" vs. "\r\n") on Windows for new lines (line endings)?"
2020 Jul 25
0
Guidelines when to use LF vs CRLF ("\n" vs. "\r\n") on Windows for new lines (line endings)?
On 25/07/2020 4:48 p.m., nospam at altfeld-im.de wrote:
> Dear R developers,
>
> I am developing an R package which returns strings with new line codes.
> I am not sure if I should use "\r\n" or "\n" in my returned strings on Windows platforms.
>
> What is the recommended best practice for package developers (and code in base R) for coding new lines in
2013 May 21
3
should dovecot store maildir files with CRLF or LF?
Hi.
I've made a strange observation.
When having Dovecot (at least) with maildir and moving (via IMAP) mail
received by some client (Evolution 3.4) into it the following happens:
Regardless of whether the mail was originally(!) set with CRLF or LF
(i.e. when I use netcat to submit the plain SMTP to the relaying MTA).
When the client (Evolution) had received the mail via POP3 before moving
2003 Oct 30
0
[PATCH] contrib/cygwin/ssh-host-config: Fix a CRLF/LF issue
Hi,
could somebody apply the below patch to contrib/cygwin/ssh-host-config?
The patch solves a problem with the way, the Windows pendant of the
/etc/services file is used.
This file has (obviously) CRLF line endings. The ssh-host-config file
tries to accomodate that when adding the ssh service entries but I never
reviewed this functionality in the light of some major changes in the
Cygwin DLL.
2016 Feb 24
2
iconv to UTF-16 encoding produces error due to embedded nulls (write.table with fileEncoding param)
On 23/02/2016 7:06 AM, Mikko Korpela wrote:
> On 23.02.2016 11:37, Martin Maechler wrote:
>>>>>>> nospam at altfeld-im de <nospam at altfeld-im.de>
>>>>>>> on Mon, 22 Feb 2016 18:45:59 +0100 writes:
>>
>> > Dear R developers
>> > I think I have found a bug that can be reproduced with two lines of code
2016 Feb 24
2
iconv to UTF-16 encoding produces error due to embedded nulls (write.table with fileEncoding param)
On 24/02/2016 9:55 AM, Mikko Korpela wrote:
> On 24.02.2016 15:47, Duncan Murdoch wrote:
>> On 23/02/2016 7:06 AM, Mikko Korpela wrote:
>>> On 23.02.2016 11:37, Martin Maechler wrote:
>>>>>>>>> nospam at altfeld-im de <nospam at altfeld-im.de>
>>>>>>>>> on Mon, 22 Feb 2016 18:45:59 +0100 writes:
>>>>
2005 Apr 27
0
RE: CRLF << -- >> LF
No, I don't. But I do know that Samba provides transparent file access -- it
has no idea what data is in the files it offers to the clients. It could be
a database, a JPEG, a text document, or an executable program. What you
suggest would be an extremely bad idea. You need better clients -- it is
the clients that interpret the contents of the file. Samba is just another
file access method.
2016 Feb 23
4
iconv to UTF-16 encoding produces error due to embedded nulls (write.table with fileEncoding param)
>>>>> nospam at altfeld-im de <nospam at altfeld-im.de>
>>>>> on Mon, 22 Feb 2016 18:45:59 +0100 writes:
> Dear R developers
> I think I have found a bug that can be reproduced with two lines of code
> and I am very thankful to get your first assessment or feed-back on my
> report.
> If this is the wrong mailing list or I
2000 Jan 07
3
CRLF/LF Conversion
Hi everybody!
I hope that you are not already "pissed off" of all the crlf/lf conversion
discussion between dos and unix ;-)
Concerning that topic I have a question / suggestion:
This is what we have:
We are using a Win NT 4.0 Server with Win95 clients. Additionally we have a
Sun (Solaris 2.5) running in the same network. To access the Sun in character
mode we use a terminal
2020 Jan 16
0
[PATCH 1/2] Win::Hivex::Regedit: Accept CRLF line endings
---
perl/lib/Win/Hivex/Regedit.pm | 1 +
1 file changed, 1 insertion(+)
diff --git a/perl/lib/Win/Hivex/Regedit.pm b/perl/lib/Win/Hivex/Regedit.pm
index 34426f1..2b17036 100644
--- a/perl/lib/Win/Hivex/Regedit.pm
+++ b/perl/lib/Win/Hivex/Regedit.pm
@@ -144,6 +144,7 @@ sub reg_import
# this is fairly common in pasted regedit files.
$lineno++;
chomp;
+ s/\r$//;
2016 Feb 25
2
iconv to UTF-16 encoding produces error due to embedded nulls (write.table with fileEncoding param)
On 23.02.2016 14:06, Mikko Korpela wrote:
> On 23.02.2016 11:37, Martin Maechler wrote:
>>>>>>> nospam at altfeld-im de <nospam at altfeld-im.de>
>>>>>>> on Mon, 22 Feb 2016 18:45:59 +0100 writes:
>>
>> > Dear R developers
>> > I think I have found a bug that can be reproduced with two lines of code
>>
2018 Feb 17
1
writeLines argument useBytes = TRUE still making conversions
Of course, right after writing this e-mail I tested on my Windows
machine and did not see what I expected:
> charToRaw(before)
[1] c3 a9
> charToRaw(after)
[1] e9
so obviously I'm misunderstanding something as well.
Best,
Kevin
On Sat, Feb 17, 2018 at 2:19 PM, Kevin Ushey <kevinushey at gmail.com> wrote:
> From my understanding, translation is implied in this line of ?file
2016 Feb 23
1
iconv to UTF-16 encoding produces error due to embedded nulls (write.table with fileEncoding param)
Excellent analysis, thank you both for the quick reply!
Is there anything I can do to get the bug fixed in the next version of R
(e. g. filing a bug report at https://bugs.r-project.org/bugzilla3/)?
On Tue, 2016-02-23 at 14:06 +0200, Mikko Korpela wrote:
> On 23.02.2016 11:37, Martin Maechler wrote:
> >>>>>> nospam at altfeld-im de <nospam at altfeld-im.de>
>
2016 Feb 16
2
iconv to UTF-16 encoding produces error due to embedded nulls (write.table with fileEncoding param)
If I execute the code from the "?write.table" examples section
x <- data.frame(a = I("a \" quote"), b = pi)
# (ommited code)
write.csv(x, file = "foo.csv", fileEncoding = "UTF-16LE")
the resulting CSV file has a size of 6 bytes which is too short
(truncated):
""",3
The problem seems to be the iconv function:
2018 Feb 15
2
writeLines argument useBytes = TRUE still making conversions
On Thu, Feb 15, 2018 at 11:19 AM, Kevin Ushey <kevinushey at gmail.com> wrote:
> I suspect your UTF-8 string is being stripped of its encoding before
> write, and so assumed to be in the system native encoding, and then
> re-encoded as UTF-8 when written to the file. You can see something
> similar with:
>
> > tmp <- '?'
> > tmp <- iconv(tmp,
2018 Feb 15
2
writeLines argument useBytes = TRUE still making conversions
I think this behavior is inconsistent with the documentation:
tmp <- '?'
tmp <- iconv(tmp, to = 'UTF-8')
print(Encoding(tmp))
print(charToRaw(tmp))
tmpfilepath <- tempfile()
writeLines(tmp, con = file(tmpfilepath, encoding = 'UTF-8'), useBytes = TRUE)
[1] "UTF-8"
[1] c3 a9
Raw text as hex: c3 83 c2 a9
If I switch to useBytes = FALSE, then
2010 Sep 13
4
Problem with WARNING...headers with CRLF line endings
Dear all,
When running R CMD check on Windows XP to test my package I get the
following warning message:
"* checking line endings in C/C++/Fortran sources/headers ... WARNING
Found the following sources/headers with CR or CRLF line endings:
src/xpsDict.h"
The problem is that this file is created by the compiler AUTOMATICALLY
during the compilation process, and since the file is
2018 Feb 17
0
writeLines argument useBytes = TRUE still making conversions
>From my understanding, translation is implied in this line of ?file (from the
Encoding section):
The encoding of the input/output stream of a connection can be specified
by name in the same way as it would be given to iconv: see that help page
for how to find out what encoding names are recognized on your platform.
Additionally, "" and "native.enc" both
2016 Feb 29
1
iconv to UTF-16 encoding produces error due to embedded nulls (write.table with fileEncoding param)
I have just committed your first patch (the strlen() replacement) to
R-devel, and will soon put it in R-patched as well. I wont have time to
look at this again before the 3.2.4 release, so your file.show() patch
isn't going to make it unless someone else gets to it.
There's still a faint chance that I'll do more in R-devel before 3.3.0,
but I think it's best if there were bug
2018 Feb 15
0
writeLines argument useBytes = TRUE still making conversions
I suspect your UTF-8 string is being stripped of its encoding before
write, and so assumed to be in the system native encoding, and then
re-encoded as UTF-8 when written to the file. You can see something
similar with:
> tmp <- '?'
> tmp <- iconv(tmp, to = 'UTF-8')
> Encoding(tmp) <- "unknown"
> charToRaw(iconv(tmp, to =
2014 Oct 19
1
Writing UTF8 on Windows
Recent functionality in jsonlite allows for streaming json to a user
supplied connection object, such as a file, pipe or socket. RFC7159
prescribes json must be encoded as unicode; ISO-8859 (including
latin1) is invalid. Hence I would like R to write strings as utf8,
irrespective of the type of connection, platform or locale.
Implementing this turns out to be unsurprisingly difficult on windows.