Genuine relative paths with R
Olivier: Readers of R-Help generally are patient and try to be helpful. Numerous solutions to your initial query were proposed, but for some reason you either reject them or take the discussion down some different rabbit hole of claims about R vs. other software environments, to which kind people reply and you then rebut. ENOUGH ALREADY. This thread has been going on for nearly a week. Choose something that works for you, have a cup of tea, go for a run, get a life. Please do not bother to reply. -Michael
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? 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 at gmail.com>
Envoy? : mercredi 10 octobre 2018 23:51
? : Olivier GIVAUDAN; Jeff Newmiller
Cc : r-help at 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 at gmail.com>
*Envoy? :* mercredi 10 octobre 2018 22:59
*? :* Olivier GIVAUDAN; Jeff Newmiller
*Cc :* r-help at 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 at gmail.com>
*Envoy? :* mercredi 10 octobre 2018 22:31
*? :* Olivier GIVAUDAN; Jeff Newmiller
*Cc :* r-help at 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.
GUIs. So the workaround I finally found satisfies my current needs
------------------------------------------------------------------------
*De :* Duncan Murdoch <murdoch.duncan at gmail.com>
*Envoy? :* mercredi 10 octobre 2018 22:07
*? :* Olivier GIVAUDAN; Jeff Newmiller
*Cc :* r-help at 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 at gmail.com>
*Envoy? :* mercredi 10 octobre 2018 21:39
*? :* Olivier GIVAUDAN; Jeff Newmiller
*Cc :* r-help at 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
I know the click method worked both on Linux (Ubuntu latest version) and
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 at gmail.com>
*Envoy? :* mercredi 10 octobre 2018 20:54
*? :* Olivier GIVAUDAN; Jeff Newmiller
*Cc :* r-help at 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
[[alternative HTML version deleted]]