Skip to content

Genuine relative paths with R

35 messages · Jeff Newmiller, Olivier GIVAUDAN, William Dunlap +4 more

Messages 1–25 of 35

Jeff Newmiller
#
On Sun, 7 Oct 2018, Olivier GIVAUDAN wrote:

            

      
      
      
    

        
The R interpreter does not make assumptions about where the code it is 
running came from. You might be running it by using the source() function, 
or by using the Rscript program, or by R CMD BATCH, or using eval() on 
code you pasted together in an R function, or as byte-compiled code loaded 
from an RData file. That is, there is not always a file in a particular 
directory even involved in the executing code.

You also keep referring to "this feature" being in many languages, though 
you seem to be mistaken about most of them... in fact, they, too, know NOT 
where the script is but where the current directory is ($PWD is the same 
as getwd()) or where the compilation occurred (__FILE__ in C relates to 
the source code directory that is usually not where the executable is 
located and may not even exist on the computer it is running on).

I have already pointed out that the solution is to let the OS set the 
current directory. If you want the user to have access to R independent of 
your code, the easiest way to leave them in Rgui after your code is done 
is to use save.image() to create a "myApp.RData" file which can be 
double-clicked [1]. The double-clicking action by default (as defined by 
the installation of R) causes the operating system to set the current 
directory to the one containing the file you double-clicked on and then 
executes the Rgui program.

If you don't want the user to interact with your session, you can use the 
Rscript executable (also mentioned briefly at the bottom of [1]). In both 
cases, the user has (unknowingly) set the current directory before running 
your code, and there is no need to encode where the script is or was 
inside the script.

You can also create a windows shortcut to invoke Rscript yourself by 
bootstrapping the RData file and invoking the 
R.utils::createWindowsShortcut() [2] function.

However, by far the best approach is to teach your users to fish... if you 
give them an RStudio project directory they can double-click on the .Rproj 
file to set the current directory and enter the world of R.

[1] https://www.r-bloggers.com/look-ma-no-typing-autorunning-code-on-r-startup/
[2] https://cran.r-project.org/web/packages/R.utils/R.utils.pdf

End comment.

            

      
      
      
    

        

      
      
    

        
---------------------------------------------------------------------------
Jeff Newmiller                        The     .....       .....  Go Live...
DCN:<jdnewmil at dcn.davis.ca.us>        Basics: ##.#.       ##.#.  Live Go...
                                       Live:   OO#.. Dead: OO#..  Playing
Research Engineer (Solar/Batteries            O.O#.       #.O#.  with
/Software/Embedded Controllers)               .OO#.       .OO#.  rocks...1k
---------------------------------------------------------------------------

  
  


  


    

    
2 days later

    

      
      

        


  

        

      Olivier GIVAUDAN
    

    

      
      #
    

  


  

      
Hi Jeff,
?

            

      
      
      
    

        
?
True. I'm only asking in the case where some R code is run from an R file. This function 'MyOwnPath()' (say) should only work (i.e. return a useful result) in this case.?
?

            

      
      
      
    

        
?
That's precisely the reproach I have in case the code comes from a file.?
?

            

      
      
      
    

        
?
'Most of them' is largely exaggerated (plus I corrected myself): I only mixed between the 'cd' variable / command in Windows and Linux shells (you would certainly agree it's a bit vicious).?
?

            

      
      
      
    

        
?
Wrong. As I already said, if I create an R script located somewhere on my computer with the only line 'getwd()' and run this script, I won't get the directory of this R script, contrary to a shell file with the only line '$PWD'.?
?

            

      
      
      
    

        
?
Yes, and? What is the issue here? So '__FILE__' does the job. Invoking '__FILE__' in a .C file (I never said in its related executable) will return the absolute path of this C source file.?
'__DIR__' in PHP also does the job. No to forget the good old VBA (Excel in this case) 'ActiveWorkbook.Path'.?

Thank you for the 2 references you provided.
However it seems that some manual settings are still required to be able to use Rscript.
But I like the solution of the .RData file: I simply created an empty .RData file at the root of my project and by double-clicking on this file (as you said), the R GUI opens and 'getwd()' returns the path of this .RData file. It seems to be a good alternative to .Rproj file to be opened with RStudio.
?

            

      
      
      
    

        
?
Yes, using an .Rproj file to be opened with RStudio also seems to me to be a reasonable solution (the one I chose until now), although it is still a workaround and requires RStudio.?
Actually in this case, the package 'here'? I previously mentioned is useless to get the current working directory of the project as 'When a project is opened within RStudio the following actions are taken: [...] The current working directory is set to the project directory.', as stated on this page: https://support.rstudio.com/hc/en-us/articles/200526207-Using-Projects.
So 'getwd()' returns exactly the same as 'here()' does.

Best regards,?
?
Olivier

________________________________
De : Jeff Newmiller <jdnewmil at dcn.davis.ca.us>
Envoy? : dimanche 7 octobre 2018 20:48
? : Olivier GIVAUDAN
Cc : D?nes T?th; r-help at r-project.org
Objet : RE: [R] Genuine relative paths with R

        
On Sun, 7 Oct 2018, Olivier GIVAUDAN wrote:

        

            

      
      
      
    

        
The R interpreter does not make assumptions about where the code it is
running came from. You might be running it by using the source() function,
or by using the Rscript program, or by R CMD BATCH, or using eval() on
code you pasted together in an R function, or as byte-compiled code loaded
from an RData file. That is, there is not always a file in a particular
directory even involved in the executing code.

You also keep referring to "this feature" being in many languages, though
you seem to be mistaken about most of them... in fact, they, too, know NOT
where the script is but where the current directory is ($PWD is the same
as getwd()) or where the compilation occurred (__FILE__ in C relates to
the source code directory that is usually not where the executable is
located and may not even exist on the computer it is running on).

I have already pointed out that the solution is to let the OS set the
current directory. If you want the user to have access to R independent of
your code, the easiest way to leave them in Rgui after your code is done
is to use save.image() to create a "myApp.RData" file which can be
double-clicked [1]. The double-clicking action by default (as defined by
the installation of R) causes the operating system to set the current
directory to the one containing the file you double-clicked on and then
executes the Rgui program.

If you don't want the user to interact with your session, you can use the
Rscript executable (also mentioned briefly at the bottom of [1]). In both
cases, the user has (unknowingly) set the current directory before running
your code, and there is no need to encode where the script is or was
inside the script.

You can also create a windows shortcut to invoke Rscript yourself by
bootstrapping the RData file and invoking the
R.utils::createWindowsShortcut() [2] function.

However, by far the best approach is to teach your users to fish... if you
give them an RStudio project directory they can double-click on the .Rproj
file to set the current directory and enter the world of R.

[1] https://www.r-bloggers.com/look-ma-no-typing-autorunning-code-on-r-startup/
[2] https://cran.r-project.org/web/packages/R.utils/R.utils.pdf

End comment.

            

      
      
      
    

        

      
      
    

        
---------------------------------------------------------------------------
Jeff Newmiller                        The     .....       .....  Go Live...
DCN:<jdnewmil at dcn.davis.ca.us>        Basics: ##.#.       ##.#.  Live Go...
                                       Live:   OO#.. Dead: OO#..  Playing
Research Engineer (Solar/Batteries            O.O#.       #.O#.  with
/Software/Embedded Controllers)               .OO#.       .OO#.  rocks...1k
---------------------------------------------------------------------------

  
  


  


      

    

    

      
      

        


  

        

      Duncan Murdoch
    

    

      
      #
    

  


  

      
On 10/10/2018 10:37 AM, Olivier GIVAUDAN wrote:

            

      
      
      
    

        
What system are you talking about?  On Unix-alikes, you'd need an "echo" 
ahead of that, and it would print the user's working directory, not the 
working directory of the script.

Duncan Murdoch

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Olivier GIVAUDAN
    

    

      
      #
    

  


  

      
Hi Duncan,

Yes, if you need to display the content of $PWD you obviously need to type 'echo' before this variable.

It prints the user's working directory if run from a terminal but if run from a bash file it prints the working directory of the script.
At least for me (I am running on the last version of Ubuntu)...

Best regards,

Olivier
________________________________
De : Duncan Murdoch <murdoch.duncan at gmail.com>
Envoy? : mercredi 10 octobre 2018 14:51
? : Olivier GIVAUDAN; Jeff Newmiller
Cc : r-help at r-project.org
Objet : Re: [R] Genuine relative paths with R

        
On 10/10/2018 10:37 AM, Olivier GIVAUDAN wrote:

            

      
      
      
    

        
What system are you talking about?  On Unix-alikes, you'd need an "echo"
ahead of that, and it would print the user's working directory, not the
working directory of the script.

Duncan Murdoch

            

      
      
      
    

        

      
      
    

        

  
  


  


      

    

    

      
      

        


  

        

      Duncan Murdoch
    

    

      
      #
    

  


  

      
On 10/10/2018 11:18 AM, Olivier GIVAUDAN wrote:

            

      
      
      
    

        
Not for me.  Always prints the user's working directory.

Duncan Murdoch

            

      
      
      
    

        

      
      
    

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Duncan Murdoch
    

    

      
      #
    

  


  

      
On 10/10/2018 11:20 AM, Duncan Murdoch wrote:

            

      
      
      
    

        
... unless some earlier lines in the script changed it, of course.

Duncan Murdoch

            

      
      
      
    

        

      
      
    

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      William Dunlap
    

    

      
      #
    

  


  

      
I am curious about why it is desirable for a script to know where in the
file system it is.  Is it because you have a set of scripts invoking each
other?  If so, the best route it to convert the scripts into functions and
put them into a package.  Functions do know which package they live in and
they "prefer" to call other functions in their own package (or other
packages which they have declared).

Or is there some other reason?


Bill Dunlap
TIBCO Software
wdunlap tibco.com

On Wed, Oct 10, 2018 at 8:18 AM, Olivier GIVAUDAN <

        
olivier_givaudan at hotmail.com> wrote:

        

            

      
      
      
    

        

      
      
    

        

  
  


  


      

    

    

      
      

        


  

        

      Olivier GIVAUDAN
    

    

      
      #
    

  


  

      
Well, no idea...

I just created a file 'TestPWD', made it executable, inserted in it these lines and moved the file in various places:

#!/bin/bash

echo $PWD
read -p ""
________________________________
De : Duncan Murdoch <murdoch.duncan at gmail.com>
Envoy? : mercredi 10 octobre 2018 15:20
? : Olivier GIVAUDAN; Jeff Newmiller
Cc : r-help at r-project.org
Objet : Re: [R] Genuine relative paths with R

        
On 10/10/2018 11:18 AM, Olivier GIVAUDAN wrote:

            

      
      
      
    

        
Not for me.  Always prints the user's working directory.

Duncan Murdoch

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

  
  


  


      

    

    

      
      

        


  

        

      Olivier GIVAUDAN
    

    

      
      #
    

  


  

      
To be able to change easily, cleanly and automatically the working directory and thus to work with relative paths in the close neighbourhood of your R files.
________________________________
De : William Dunlap <wdunlap at tibco.com>
Envoy? : mercredi 10 octobre 2018 15:25
? : Olivier GIVAUDAN
Cc : Duncan Murdoch; Jeff Newmiller; r-help at r-project.org
Objet : Re: [R] Genuine relative paths with R

I am curious about why it is desirable for a script to know where in the file system it is.  Is it because you have a set of scripts invoking each other?  If so, the best route it to convert the scripts into functions and put them into a package.  Functions do know which package they live in and they "prefer" to call other functions in their own package (or other packages which they have declared).

Or is there some other reason?


Bill Dunlap
TIBCO Software
wdunlap tibco.com<http://tibco.com>

        
On Wed, Oct 10, 2018 at 8:18 AM, Olivier GIVAUDAN <olivier_givaudan at hotmail.com<mailto:olivier_givaudan at hotmail.com>> wrote:

        
Hi Duncan,

Yes, if you need to display the content of $PWD you obviously need to type 'echo' before this variable.

It prints the user's working directory if run from a terminal but if run from a bash file it prints the working directory of the script.
At least for me (I am running on the last version of Ubuntu)...

Best regards,

Olivier
________________________________
De : Duncan Murdoch <murdoch.duncan at gmail.com<mailto:murdoch.duncan at gmail.com>>
Envoy? : mercredi 10 octobre 2018 14:51
? : Olivier GIVAUDAN; Jeff Newmiller
Cc : r-help at r-project.org<mailto:r-help at r-project.org>
Objet : Re: [R] Genuine relative paths with R

        
On 10/10/2018 10:37 AM, Olivier GIVAUDAN wrote:

            

      
      
      
    

        
What system are you talking about?  On Unix-alikes, you'd need an "echo"
ahead of that, and it would print the user's working directory, not the
working directory of the script.

Duncan Murdoch

            

      
      
      
    

        

      
      
    

        
______________________________________________
R-help at r-project.org<mailto:R-help at r-project.org> mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

  
  


  


      

    

    

      
      

        


  

        

      Duncan Murdoch
    

    

      
      #
    

  


  

      
On 10/10/2018 3:51 PM, Olivier GIVAUDAN wrote:

            

      
      
      
    

        
When I execute that, it prints my working directory.  Doesn't matter 
where the TestPWD file is.  If I put it in directory "foo", and change 
to foo's parent, then

   foo/TestPWD

prints the name of the parent directory, not the foo directory.  If I 
then add foo to the PATH, and run

   TestPWD

I get the same thing.  I find it unbelievable that you are seeing 
anything different from that on a Unix-alike.

Duncan Muroch

            

      
      
      
    

        

      
      
    

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Olivier GIVAUDAN
    

    

      
      #
    

  


  

      
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?
________________________________
De : Duncan Murdoch <murdoch.duncan at gmail.com>
Envoy? : mercredi 10 octobre 2018 20:17
? : Olivier GIVAUDAN; Jeff Newmiller
Cc : r-help at r-project.org
Objet : Re: [R] Genuine relative paths with R

        
On 10/10/2018 3:51 PM, Olivier GIVAUDAN wrote:

            

      
      
      
    

        
When I execute that, it prints my working directory.  Doesn't matter
where the TestPWD file is.  If I put it in directory "foo", and change
to foo's parent, then

   foo/TestPWD

prints the name of the parent directory, not the foo directory.  If I
then add foo to the PATH, and run

   TestPWD

I get the same thing.  I find it unbelievable that you are seeing
anything different from that on a Unix-alike.

Duncan Muroch

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

  
  


  


      

    

    

      
      

        


  

        

      Duncan Murdoch
    

    

      
      #
    

  


  

      
On 10/10/2018 4:42 PM, Olivier GIVAUDAN wrote:

            

      
      
      
    

        
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

  
  


  


      

    

    

      
      

        


  

        

      Olivier GIVAUDAN
    

    

      
      #
    

  


  

      
Actually there is a difference between:

  1.  Directly executing the file by the user by double clicking on the "physical" file (you can only do that from the directory where the file is located), without going through any terminal, and
  2.  Executing this file "remotely" by calling it through a terminal for instance.

________________________________
De : R-help <r-help-bounces at r-project.org> de la part de Olivier GIVAUDAN <olivier_givaudan at hotmail.com>
Envoy? : mercredi 10 octobre 2018 20:42
? : Duncan Murdoch; Jeff Newmiller
Cc : r-help at r-project.org
Objet : Re: [R] Genuine relative paths with R

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?
________________________________
De : Duncan Murdoch <murdoch.duncan at gmail.com>
Envoy? : mercredi 10 octobre 2018 20:17
? : Olivier GIVAUDAN; Jeff Newmiller
Cc : r-help at r-project.org
Objet : Re: [R] Genuine relative paths with R

        
On 10/10/2018 3:51 PM, Olivier GIVAUDAN wrote:

            

      
      
      
    

        
When I execute that, it prints my working directory.  Doesn't matter
where the TestPWD file is.  If I put it in directory "foo", and change
to foo's parent, then

   foo/TestPWD

prints the name of the parent directory, not the foo directory.  If I
then add foo to the PATH, and run

   TestPWD

I get the same thing.  I find it unbelievable that you are seeing
anything different from that on a Unix-alike.

Duncan Muroch

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        
______________________________________________
R-help at r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

  
  


  


      

    

    

      
      

        


  

        

      Olivier GIVAUDAN
    

    

      
      #
    

  


  

      
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...
________________________________
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:

            

      
      
      
    

        
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

  
  


  


      

    

    

      
      

        


  

        

      Duncan Murdoch
    

    

      
      #
    

  


  

      
On 10/10/2018 5:31 PM, Olivier GIVAUDAN wrote:

            

      
      
      
    

        
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

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Olivier GIVAUDAN
    

    

      
      #
    

  


  

      
I'm not sure I'm "inventing my own way" of distributing R code... And I distribute it to a very limited audience.
Anyway, why not "inventing a new way" if it's more efficient than the standard one (I'm talking now in theory)?
________________________________
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:

            

      
      
      
    

        
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

            

      
      
      
    

        

  
  


  


      

    

    

      
      

        


  

        

      Duncan Murdoch
    

    

      
      #
    

  


  

      
On 10/10/2018 5:45 PM, Olivier GIVAUDAN wrote:

            

      
      
      
    

        
Nothing says a package has to go on CRAN.  You can distribute them 
privately to a small audience.

            

      
      
      
    

        
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

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Olivier GIVAUDAN
    

    

      
      #
    

  


  

          

      
      
      
    

        
Yes, I agree in theory. But this solution still violates my own proportionality principle.

            

      
      
      
    

        
I didn't claim that (that's was a quite general / theoretical statement, not necessarily and only applicable to R).

            

      
      
      
    

        
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 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:

            

      
      
      
    

        
Nothing says a package has to go on CRAN.  You can distribute them
privately to a small audience.

            

      
      
      
    

        
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

            

      
      
      
    

        

  
  


  


      

    

    

      
      

        


  

        

      Duncan Murdoch
    

    

      
      #
    

  


  

      
On 10/10/2018 6:17 PM, Olivier GIVAUDAN wrote:

            

      
      
      
    

        
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).

            

      
      
      
    

        
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

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Olivier GIVAUDAN
    

    

      
      #
    

  


  

          

      
      
      
    

        
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.

            

      
      
      
    

        
Which false claims?
________________________________
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:

            

      
      
      
    

        
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).

            

      
      
      
    

        
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

            

      
      
      
    

        

  
  


  


      

    

    

      
      

        


  

        

      Duncan Murdoch
    

    

      
      #
    

  


  

      
On 10/10/2018 6:52 PM, Olivier GIVAUDAN wrote:

            

      
      
      
    

        
"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

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Olivier GIVAUDAN
    

    

      
      #
    

  


  

      
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.

'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:

            

      
      
      
    

        
"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

            

      
      
      
    

        

  
  


  


      

    

    

      
      

        


  

        

      Peter Claussen
    

    

      
      #
    

  


  

      
If I?m following all this correctly, it seems your criticism is that R doesn?t provide a run-time function that is equivalent to a compile-time macro. You do realize that __FILE__ is not part of the C programming language - it?s a predefined variable recognized by the cpp - the C preprocessor program. Similarly, SAS_EXECFILENAME is a predefined variable that can be recognized by the SAS macro processor, but has no meaning in the SAS language itself.

So, to go back to your original post:

            

      
      
      
    

        
This is what a macro processor does. Are you asking for a macro language in R?

Cheers

            

      
      
      
    

        

  
  


  


      

    

    

      
      

        


  

        

      Duncan Murdoch
    

    

      
      #
    

  


  

      
On 10/10/2018 7:11 PM, Olivier GIVAUDAN wrote:

            

      
      
      
    

        
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

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Olivier GIVAUDAN
    

    

      
      #
    

  


  

      
Yes, I am aware that both '__FILE__' and 'SAS_EXECFILENAME' are macro variables. I don't know how the VBA 'Application.ThisWorkbook.Path' VBA or PHP '__DIR__' (or '__FILE__') work.

And yes, indeed, until now I didn't even realise that this simple find-and-replace solution of "mine" is actually the basic job of a preprocessor when it expands macro variables, thank you!

A macro language in R, yes, I think it would be useful, at least for this function. If nothing simpler is available, of course...
________________________________
De : Peter Claussen <dakotajudo at mac.com>
Envoy? : mercredi 10 octobre 2018 23:29
? : Olivier GIVAUDAN
Cc : Duncan Murdoch; Jeff Newmiller; r-help at r-project.org
Objet : Re: [R] Genuine relative paths with R

If I?m following all this correctly, it seems your criticism is that R doesn?t provide a run-time function that is equivalent to a compile-time macro. You do realize that __FILE__ is not part of the C programming language - it?s a predefined variable recognized by the cpp - the C preprocessor program. Similarly, SAS_EXECFILENAME is a predefined variable that can be recognized by the SAS macro processor, but has no meaning in the SAS language itself.

So, to go back to your original post:
1.  Either create a variable "ScriptPath" in the first lines of each of my R scripts and run a batch (or shell, etc.) to replace every single occurrence of "ScriptPath <-" by "ScriptPath <- [Absolute path of the R script]" in all the R scripts located in the folder (and possibly subfolders) of the batch file.

This is what a macro processor does. Are you asking for a macro language in R?

Cheers

        
On Oct 10, 2018, at 6:11 PM, Olivier GIVAUDAN <olivier_givaudan at hotmail.com<mailto:olivier_givaudan at hotmail.com>> 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.

'getwd()' is indeed not equivalent to VBA 'Application.ThisWorkbook.Path' or C macro '__FILE__' or SAS %sysget(SAS_EXECFILENAME), etc.