[R-SIG-Mac] R.app stange behavior?

Simon Urbanek simon.urbanek at r-project.org
Sat Dec 29 20:34:19 CET 2007

On Dec 29, 2007, at 2:04 PM, Philippe Grosjean wrote:

> Simon and Brian,
> Sorry, I forgot to tell about my system:
> > version
>               _
> platform       i386-apple-darwin8.10.1
> arch           i386
> os             darwin8.10.1
> system         i386, darwin8.10.1
> status
> major          2
> minor          6.1
> year           2007
> month          11
> day            26
> svn rev        43537
> language       R
> version.string R version 2.6.1 (2007-11-26)
> > sessionInfo()
> R version 2.6.1 (2007-11-26)
> i386-apple-darwin8.10.1
> locale:
> C
> attached base packages:
> [1] stats     graphics  grDevices utils     datasets  methods   base
> > Sys.getenv("R_GUI_APP_VERSION")
>           "1.22"
> > l10n_info()
> [1] FALSE
> $`UTF-8`
> [1] FALSE
> $`Latin-1`
> [1] FALSE
> I switch to French in the system preferences.

What is your format setting? It must be French too and I suspect that  
it's not. If it's not then you need to override the locale, because  
there is not such thing as french locale with non-french formats. See  
FAQ section 9, in that (rather unusual case) you need to use something  
defaults write org.R-project.R force.LANG fr_FR.UTF-8

> R is restarted after this. Menus are in French. To get messages in  
> French in the Console, I need to enter Sys.setenv(LANG = "fr")...

That is a really bad thing to do, because it uses the wrong locale  
that is not supported by the GUI. Again, the preferred way is to set  
the system preferences correctly.

> Even changing this variable in a terminal before starting R does  
> nothing better. I am a little bit lost...

For command-line R use the proper one:
and that work just fine for me (you can use non-UTF-8, but make sure  
you have the right terminal then).


> Simon Urbanek wrote:
>> Philippe,
>> On Dec 29, 2007, at 7:17 AM, Philippe Grosjean wrote:
>>> I have a couple of questions regarding the way R.app works:
>>> 1) R.app forces \n at the end of output:
>>>> cat("some text")
>>> some text
>>> While on any other R console I have tested (including R in a  
>>> terminal on a Mac), it is not the case:
>>>> cat("some text")
>>> some text>
>> Although your tests are right, your explanation is not. The GUI  
>> doesn't force \n in general, try:
>> > cat("foo"); cat("bar")
>> foobar
>> All it does is to make sure that a prompt is printed on a new line  
>> (to avoid prompt printed in the middle of some output). It does not  
>> affect output in functions, scripts etc. (hence I think the  
>> following is irrelevant).
>>> This is a problem for two reasons: (1) Mac users may forgot to add  
>>> \n when using cat() and it would produce weird results elsewhere,  
>>> and (2) it is sometimes useful to be able to write something  
>>> before the prompt, or to write text without \n (see progress() in  
>>> svMisc package, for an example of use)
>>> 2) R.app does not interpret \a and \b. \a should output a sound  
>>> ('bip') and is used in alarm() function that does not work in  
>>> R.app, and \b is backspace and is supposed to erase previous  
>>> character. Consequently:
>>>> cat("abc\bd\n")
>>> abcd
>>> which is wrong, or at least, different from the behavior on all  
>>> other R consoles I have used which gives:
>>>> cat("abc\bd\n")
>>> abd
>> The interpretation of all those codes is terminal-specific and for  
>> now the R.app chooses to not interpret them (however, they are  
>> preserved, try pasting the output in a terminal that interprets  
>> them).
>> As a side note, one specific issue is that of \r which seems to be  
>> handy at times to report progress (although not portably).  
>> Historically, Macs used \r to denote end of line in files and  
>> input, therefore we have to interpret it as what you would expect  
>> from \n for compatibility. With \r\n as the Windows end of line  
>> sequence being also treated as \n for compatibility this explains  
>> the current behavior in the GUI. ("\r", "\n", "\r\n" are  
>> equivalent, "\r\r" and "\n\r" ares equivalent to "\n\n").
>> We may change the behavior in the future as the compatibility may  
>> not be as important anymore. As of the other codes, I'm not quite  
>> sure it's worth the hassle, but it could be done.
>>> 3) Despite reading Mac-FAQ, I cannot figure out how to print French
>>> messages correctly. I got something like:
>>>> nonexistingvar
>>> Erreur : objet "nonexistingvar" non trouv'e
>>> This is the same on the terminal. Under Windows (RGui), I got:
>>>> nonexistingvar
>>> Erreur : objet "nonexistingvar" non trouvé
>>> How can I fix this? (I am the maintainer of R French translation,  
>>> and it uses 'charset=ISO-8859-1').
>> You'll have to tell us more about your settings - at least  
>> sessionInfo(), possibly Sys.getenv("R_GUI_APP_VERSION") and any  
>> other changes you made to your preferences manually. After  
>> selecting French language and French settings in the system  
>> preferences, I get correctly:
>> > nonexistingvar
>> Erreur : objet "nonexistingvar" non trouvé
>> locale:
>> fr_FR.UTF-8/fr_FR.UTF-8/fr_FR.UTF-8/C/fr_FR.UTF-8/fr_FR.UTF-8
>> Cheers,
>> Simon

More information about the R-SIG-Mac mailing list