On 11/3/21 1:37 AM, Henrik Bengtsson wrote:
Oh, I see, I misunderstood.  Thanks for clarifying.

One more thing, to mix-and-match environment variables and strings
with escaped characters, while mimicking how POSIX shells does it, by
using strings with double and single quotes. For example, with:

$ cat .Renviron
APPDATA='C:\Users\foobar\AppData\Roaming'
R_LIBS_USER="${APPDATA}"'\R-library'

we get:

$ Rscript --no-init-file --quiet -e 'cat(sprintf("R_LIBS_USER=[%s]\n",
Sys.getenv("R_LIBS_USER")))'
R_LIBS_USER=[C:\Users\foobar\AppData\Roaming\R-library]

and

$ source .Renviron
$ echo "R_LIBS_USER=[${R_LIBS_USER}]"
R_LIBS_USER=[C:\Users\foobar\AppData\Roaming\R-library]
Yes, that could be mentioned explicitly as well.

Tomas



/Henrik

On Sun, Oct 31, 2021 at 2:59 AM Tomas Kalibera <tomas.kalib...@gmail.com> wrote:

On 10/31/21 2:55 AM, Henrik Bengtsson wrote:
... If one still needed backslashes,
they could then be entered in single quotes, e.g. VAR='c:\users'.
I don't think it matters whether you use single or double quotes -
both will work.  Here's a proof of concept on Linux with R 4.1.1:

$ cat ./.Renviron
A=C:\users
B='C:\users'
C="C:\users"

$ Rscript -e "Sys.getenv(c('A', 'B', 'C'))"
            A           B           C
    "C:users" "C:\\users" "C:\\users"
Yes, but as I wrote "I think the Renviron files should be written in a
way so that they would work the same in a POSIX shell". This is why
single quotes. With double quotes, backslashes are interpreted
differently from a POSIX shell.

Tomas


/Henrik

On Wed, Oct 27, 2021 at 11:45 AM Tomas Kalibera
<tomas.kalib...@gmail.com> wrote:
On 10/21/21 5:18 PM, Martin Maechler wrote:
Michał Bojanowski
       on Wed, 20 Oct 2021 16:31:08 +0200 writes:
       > Hello Tomas,
       > Yes, that's accurate although rather terse, which is perhaps the
       > reason why I did not realize it applies to my case.

       > How about adding something in the direction of:

       > 1. Continuing the cited paragraph with:
       > In particular, on Windows it may be necessary to quote references to
       > existing environment variables, especially those containing file paths
       > (which include backslashes). For example: `"${WINVAR}"`.

       > 2. Add an example (not run):

       > # On Windows do quote references to variables containing paths, e.g.:
       > # If APPDATA=C:\Users\foobar\AppData\Roaming
       > # to point to a library tree inside APPDATA in .Renviron use
       > R_LIBS_USER="${APPDATA}"/R-library

       > Incidentally the last example is on backslashes too.


       > What do you think?

I agree that adding an example really helps a lot in such cases,
in my experience, notably if it's precise enough to be used +/- directly.
Yes, I agree as well. I think the Renviron files should be written in a
way so that they would work the same in a POSIX shell, so e.g.
VAR="${VAR0}" or VAR="${VAR0}/subdir" are the recommended ways to
preserve backslashes in VAR0. It is better to use forward slashes in
string literals, e.g. VAR="c:/users". If one still needed backslashes,
they could then be entered in single quotes, e.g. VAR='c:\users'.

The currently implemented parsing of Renviron files differs in a number
of details from POSIX shells, some are documented and some are not.
Relying only on the documented behavior that is the same as in POSIX
shells is the best choice for future compatibility.

Tomas

       > On Mon, Oct 18, 2021 at 5:02 PM Tomas Kalibera 
<tomas.kalib...@gmail.com> wrote:
       >>
       >>
       >> On 10/15/21 6:44 PM, Michał Bojanowski wrote:
       >> > Perhaps a small update to ?.Renviron would be in order to mention 
that...
       >>
       >> Would you have a more specific suggestion how to update the
       >> documentation? Please note that it already says
       >>
       >> "‘value’ is then processed in a similar way to a Unix shell: in
       >> particular the outermost level of (single or double) quotes is 
stripped,
       >> and backslashes are removed except inside quotes."
       >>
       >> Thanks,
       >> Tomas
       >>
       >> > On Fri, Oct 15, 2021 at 6:43 PM Michał Bojanowski 
<michal2...@gmail.com> wrote:
       >> >> Indeed quoting works! Kevin suggested the same, but he didnt reply 
to the list.
       >> >> Thank you all!
       >> >> Michal
       >> >>
       >> >> On Fri, Oct 15, 2021 at 6:40 PM Ivan Krylov 
<krylov.r...@gmail.com> wrote:
       >> >>> Sorry for the noise! I wasn't supposed to send my previous 
message.
       >> >>>
       >> >>> On Fri, 15 Oct 2021 16:44:28 +0200
       >> >>> Michał Bojanowski <michal2...@gmail.com> wrote:
       >> >>>
       >> >>>> AVAR=${APPDATA}/foo/bar
       >> >>>>
       >> >>>> Which is a documented way of referring to existing environment
       >> >>>> variables. Now, with that in R I'm getting:
       >> >>>>
       >> >>>> Sys.getenv("APPDATA")    # That works OK
       >> >>>> [1] "C:\\Users\\mbojanowski\\AppData\\Roaming"
       >> >>>>
       >> >>>> so OK, but:
       >> >>>>
       >> >>>> Sys.getenv("AVAR")
       >> >>>> [1] "C:UsersmbojanowskiAppDataRoaming/foo/bar"
       >> >>> Hmm, a function called by readRenviron does seem to remove 
backslashes,
       >> >>> but not if they are encountered inside quotes:
       >> >>>
       >> >>> 
https://github.com/r-devel/r-svn/blob/3f8b75857fb1397f9f3ceab6c75554e1a5386adc/src/main/Renviron.c#L149
       >> >>>
       >> >>> Would AVAR="${APPDATA}"/foo/bar work?
       >> >>>
       >> >>> --
       >> >>> Best regards,
       >> >>> Ivan
       >> > ______________________________________________
       >> > R-devel@r-project.org mailing list
       >> > https://stat.ethz.ch/mailman/listinfo/r-devel

       > ______________________________________________
       > R-devel@r-project.org mailing list
       > https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Reply via email to