[R] Genuine relative paths with R

[Duncan Murdoch]

On 10/10/2018 8:08 PM, Olivier GIVAUDAN wrote:
> I think Gabor (at least) already suggested this solution. But the 
> problem is: how do you source this file containing this 'foo' function 
> without writing its absolute path?

You only need its relative path to source it.

Duncan Murdoch
> 
> It's a kind of initialisation issue.
> 
>  > a function returning the path of the R file where this same function 
> was invoked.
>  >> I didn't realize that's what you were asking for. This has nothing 
> to do with your subject line.
> 
> It's just a trick to work with relative paths without having to write 
> any hardcoded (by definition) absolute path beforehand.
> ------------------------------------------------------------------------
> *De :* Duncan Murdoch <murdoch.duncan using gmail.com>
> *Envoyé :* mercredi 10 octobre 2018 23:51
> *À :* Olivier GIVAUDAN; Jeff Newmiller
> *Cc :* r-help using r-project.org
> *Objet :* Re: [R] Genuine relative paths with R
> On 10/10/2018 7:11 PM, Olivier GIVAUDAN wrote:
>> It is not wrong to claim that R currently doesn't have a function 
>> returning the path of the R file where this same function was invoked.
> 
> But it does.  I didn't realize that's what you were asking for.  This
> has nothing to do with your subject line.
> 
> If you source a file from somewhere, then each of the functions it
> creates is marked with its source location.  So you can put this in a file:
> 
> foo <- function () 1
> 
> filename <- normalizePath(getSrcFilename(foo, full.names=TRUE))
> 
> (You need the normalizePath() call because all that will be saved is the
> path that was used.  If it was a relative path, that's what you get
> before you normalize it.  You don't really need the foo function; you
> could put an anonymous function into the getSrcFilename call.  It's just
> usually easier to include a function that already exists.)
> 
> When you source() that file, filename will get the name of the file it
> came from.
> 
> This is a lot like __FILE__ in C.  One difference is that it is usually
> turned off when the function is being loaded into a package, but you can
> optionally turn it on.
> 
> You can also find out what line foo starts on, using
> 
> fooline <- getSrcLocation(foo)
> 
> This is a lot like __LINE__ in C.
> 
> Duncan Murdoch
> 
> 
>> 
>> 'getwd()' is indeed not equivalent to VBA 
>> 'Application.ThisWorkbook.Path' or C macro '__FILE__' or SAS 
>> %sysget(SAS_EXECFILENAME), etc.
>> ------------------------------------------------------------------------
>> *De :* Duncan Murdoch <murdoch.duncan using gmail.com>
>> *Envoyé :* mercredi 10 octobre 2018 22:59
>> *À :* Olivier GIVAUDAN; Jeff Newmiller
>> *Cc :* r-help using r-project.org
>> *Objet :* Re: [R] Genuine relative paths with R
>> On 10/10/2018 6:52 PM, Olivier GIVAUDAN wrote:
>>>>  Again, you seem to think making a package is a big deal.
>>> 
>>> Perhaps not a big deal (I believe you, I didn't write an R package yet), 
>>> but not as straightforward as having a function within an R file 
>>> returning its own path.
>>> 
>>>> But you're free to decide not to do it:  just please don't repeat 
>>> falseclaims about R (like the ones about paths that started this long 
>>> thread).
>>> 
>>> Which false claims?
>> 
>> "But I am really wondering why R doesn't have (please tell me if I'm
>> wrong) this basic feature as many other languages have it (batch, shell,
>> C, LaTeX, SAS with macro-variables, etc.)?"
>> 
>> Duncan Murdoch
>> 
>>> ------------------------------------------------------------------------
>>> *De :* Duncan Murdoch <murdoch.duncan using gmail.com>
>>> *Envoyé :* mercredi 10 octobre 2018 22:31
>>> *À :* Olivier GIVAUDAN; Jeff Newmiller
>>> *Cc :* r-help using r-project.org
>>> *Objet :* Re: [R] Genuine relative paths with R
>>> On 10/10/2018 6:17 PM, Olivier GIVAUDAN wrote:
>>>>> Nothing says a package has to go on CRAN.  You can distribute 
>>>> themprivately to a small audience.
>>>> 
>>>> Yes, I agree in theory. But this solution still violates my own 
>>>> proportionality principle.
>>> 
>>> Again, you seem to think making a package is a big deal.  Maybe that was
>>> true 10 years ago (though I wrote and tested a package in a 45 minute
>>> presentation at UseR 2008), but now it's very easy.
>>> 
>>> But you're free to decide not to do it:  just please don't repeat false
>>> claims about R (like the ones about paths that started this long thread).
>>> 
>>>> 
>>>>> If you know as much about R as the people who wrote it
>>>> 
>>>> I didn't claim that (that's was a quite general / theoretical statement, 
>>>> not necessarily and only applicable to R).
>>> 
>>> I didn't say you made that claim.  I was answering your question about
>>> why inventing your own way is not a good idea.  It might be a good idea,
>>> if you know the system very, very well.  Otherwise, it's probably better
>>> to work the standard way.
>>> 
>>> Duncan Murdoch
>>> 
>>>> 
>>>>> For example, you might thinkthat all front ends set the working 
>>>> directory to the directory of theprogram they are running, because the 
>>>> ones you've tried do it that way. But they don't.
>>>> 
>>>> It runs that way at least on Windows with RStudio and R GUI and I know 
>>>> the recipients of my R code work on Windows with at least one of these 2 
>>>> GUIs. So the workaround I finally found satisfies my current needs
>>>> ------------------------------------------------------------------------
>>>> *De :* Duncan Murdoch <murdoch.duncan using gmail.com>
>>>> *Envoyé :* mercredi 10 octobre 2018 22:07
>>>> *À :* Olivier GIVAUDAN; Jeff Newmiller
>>>> *Cc :* r-help using r-project.org
>>>> *Objet :* Re: [R] Genuine relative paths with R
>>>> On 10/10/2018 5:45 PM, Olivier GIVAUDAN wrote:
>>>>> I'm not sure I'm "inventing my own way" of distributing R code... And I 
>>>>> distribute it to a very limited audience.
>>>> 
>>>> Nothing says a package has to go on CRAN.  You can distribute them
>>>> privately to a small audience.
>>>> 
>>>>> Anyway, why not "inventing a new way" if it's more efficient than the 
>>>>> standard one (I'm talking now in theory)?
>>>> 
>>>> If you know as much about R as the people who wrote it, then you can
>>>> almost certainly invent better ways to do many of the things it does.  R
>>>> Core was constrained by trying to maintain back compatibility, and that
>>>> means some of their solutions aren't perfect.
>>>> 
>>>> But if you don't know it that well, chances are you'll make mistakes
>>>> when you invent your own way of doing it.  For example, you might think
>>>> that all front ends set the working directory to the directory of the
>>>> program they are running, because the ones you've tried do it that way.
>>>> But they don't.
>>>> 
>>>> Duncan Murdoch
>>>> 
>>>>> ------------------------------------------------------------------------
>>>>> *De :* Duncan Murdoch <murdoch.duncan using gmail.com>
>>>>> *Envoyé :* mercredi 10 octobre 2018 21:39
>>>>> *À :* Olivier GIVAUDAN; Jeff Newmiller
>>>>> *Cc :* r-help using r-project.org
>>>>> *Objet :* Re: [R] Genuine relative paths with R
>>>>> On 10/10/2018 5:31 PM, Olivier GIVAUDAN wrote:
>>>>>> I do not want to use the terminal, just double clicks (i.e. the 
>>>>>> simplest, automatic, non-manual way, without having to write a line / 
>>>>>> command).
>>>>>> Therefore everything should happen outside any terminal. The user won't 
>>>>>> use a terminal.
>>>>>> 
>>>>>> I don't have a Mac and I'm not familiar with this OS, sorry.
>>>>>> But I'm really surprised the click method gives different results than 
>>>>>> on Linux and Windows.
>>>>>> I know the click method worked both on Linux (Ubuntu latest version) and 
>>>>>> Windows (10).
>>>>>> 
>>>>>> Yes, I executed my file from a terminal and got obviously the same 
>>>>>> result as you (that's reassuring).
>>>>>> 
>>>>>> Come on guys, creating a package... It's like using a hammer to kill a 
>>>>>> fly...
>>>>> 
>>>>> It's a simple operation to create a package in RStudio.  Not quite a
>>>>> single click, but just a few.
>>>>> 
>>>>> In plain R, it's just a little more work using package.skeleton().
>>>>> 
>>>>> Really, if you are distributing R code, you should do it in the standard
>>>>> way, not invent your own.
>>>>> 
>>>>> Duncan Murdoch
>>>>> 
>>>>>> ------------------------------------------------------------------------
>>>>>> *De :* Duncan Murdoch <murdoch.duncan using gmail.com>
>>>>>> *Envoyé :* mercredi 10 octobre 2018 20:54
>>>>>> *À :* Olivier GIVAUDAN; Jeff Newmiller
>>>>>> *Cc :* r-help using r-project.org
>>>>>> *Objet :* Re: [R] Genuine relative paths with R
>>>>>> On 10/10/2018 4:42 PM, Olivier GIVAUDAN wrote:
>>>>>>> Why are you not simply double-clicking on 'TestPWD' and choosing to 
>>>>>>> execute the file (don't add anything)?
>>>>>>> Are you executing the file from a terminal?
>>>>>> 
>>>>>> Yes, I was executing the file from my terminal.  Otherwise I really have
>>>>>> no idea what the "current directory" is in the Finder.   (I'm on a Mac.
>>>>>> I just tried the click method; it printed my home directory, not the
>>>>>> directory of the script.)
>>>>>> 
>>>>>> I don't know the name of your visual front end, but you are displaying
>>>>>> the working directory that it sets when you click on TestPWD.  That will
>>>>>> be different from the working directory that your user sees in the Terminal.
>>>>>> 
>>>>>> You can see what I saw if you run TestPWD from the Terminal.  It will
>>>>>> print the current working directory, not the one where TestPWD happens
>>>>>> to live.
>>>>>> 
>>>>>> If you want to do the same sort of thing in R, you could set up a script
>>>>>> that calls R, and execute that in the way you executed TestPWD.  But in
>>>>>> another message you said you aren't allowed to do that, so I think your
>>>>>> best solution is the one offered by Bill Dunlap:  organize your files as
>>>>>> an R package.  If you name your package "Olivier", then you can find all
>>>>>> the files in it under the directory returned by
>>>>>> 
>>>>>>     system.file(".", package = "Olivier")
>>>>>> 
>>>>>> The package system is designed for R code, but you can put arbitrary
>>>>>> files into a package:  just store them under the "inst" directory in
>>>>>> your source.  When the package is installed, those files will be moved
>>>>>> up one level, i.e.
>>>>>> 
>>>>>> Olivier/inst/foo
>>>>>> 
>>>>>> will become
>>>>>> 
>>>>>>     system.file("foo", package = "Olivier")
>>>>>> 
>>>>>> Duncan Murdoch
>>>>> 
>>>> 
>>> 
>> 
>