Right on the point, Ivan, that was the issue. The output from l10n_info()
was:
$MBCS
[1] FALSE
$`UTF-8`
[1] FALSE
$`Latin-1`
[1] FALSE
$codeset
[1] "US-ASCII"
(and the locale was just "C")
I simply needed to write something like:
export LC_ALL='en_US.UTF-8'
before starting the child
On Fri, 30 Jun 2023 11:33:34 +0300
Adrian Dușa wrote:
> In a very simple test, I tried creating a text file from the Electron
> app embedded R:
> sink("test.txt")
> cat("\u00e7")
> sink()
>
> which resulted in:
>
>
>
> I don't quite understand how this works, my best guess is it matters
>
Hello Iris,
Thanks for your answer. The thing is not that I want to obtain ,
but that it gets produced regardless.
In the meantime, I have assessed the real culprit is somehow (perhaps)
related to the locale or encoding of the terminal process that I use to run
R, in that particular MacOS
Hiya!
You can do this by specifying sub="c99" instead of "Unicode":
```R
x <- "fa\xE7ile"
xx <- iconv(x, "latin1", "UTF-8")
iconv(xx, "UTF-8", "ASCII", "c99")
```
produces:
```
> x <- "fa\xE7ile"
> xx <- iconv(x, "latin1", "UTF-8")
> iconv(xx, "UTF-8", "ASCII", "c99")
[1] "fa\\u00e7ile"
>
```
Dear list,
Building on the example from ?iconv:
x <- "fa\xE7ile"
xx <- iconv(x, "latin1", "UTF-8") # "façile"
and:
iconv(xx, "UTF-8", "ASCII", "Unicode")
# "faile"
This is the type of result I sometimes get from an R script that I cannot
reproduce here, because it depends on a terminal process
5 matches
Mail list logo
