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:>> 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]]
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> 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.[[alternative HTML version deleted]]
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. >>> >>> 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: >>>> 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 >>>>> 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 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 >>>> >>> >> >
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. [[alternative HTML version deleted]]
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]]