Well, Bill, at risk of embarrassing myself, in my case, I have gone this
sort of route out of plain wrong thinking. I took way too many years to
learn about R packages; it seemed that hurdle was too high (it wasn't
really) and so I followed the kinds of tricks that I needed to do in
other languages. Sourcing sets of scripts was one of those tricks.
Today, in most cases, I have found that when I travel this thinking
path, I need to re-think and set up a package to do the work.
That said, I have on occasion dropped projects that I couldn't figure
out a clean way to do within R. In those cases, it was simply easier to
do in Perl, Python or even csh. Still, because R is so powerful, I find
myself doing more and more of the basic parsing and processing within R
and this leads to models of processing more similar to that using in
those other languages. For example, making a "filter" (in the Unix
sense) out of R turns out to be challenging to write in a concise manner
('littler' solves this, but I have had some stability issues with it);
I've standardised my filters now based on a generic Makefile, generic
csh-script which is processed by sed, plus the actual R-code. It isn't
really pretty, but it is smooth now. It didn't fit the standard R model
of data and code in one directory, however, so it became a bit uglier.
The specific question below could be used to set up built in test
functions, in a manner similar to what is done in Python. That is
probably not the way to build in unit tests in R, but it is similar to
the way I did it for years in other languages. Another place that had
caused me trouble is when I have my data stored in one location (I work
at a company where the laboratory deposits large data sets in a
predefined set of locations and I don't have write access there) and my
analysis scripts are in another location which is part of a CVS source
tree. If someone else checks out my scripts from CVS, they need to run
properly on data in the fixed location, regardless of where they started
from, yet produce their results in script, not the data directory. We
can all think of ways to make that work, however, one possible approach
involves the script "knowing" where it is.
I'm not saying that any of this is "right", merely speculating on the
cause of people thinking about "source awareness" as I have gone that
route myself. And in some cases, as I said, it was wrong, and in other
cases, less well defined (as I can't think of the specifics now), it was
the only way I could find to make some code work (as I couldn't think of
a solution, that code doesn't exist); this was usually code that was to
be deployed for a user to run as a command line tool on a data set.
One particular use I would like for the path to the R script is for
"reproducible research". I currently log many aspects of any particular
processing run with "sessionInfo()" and other tools. However, the only
way I have to record the actual script name is via CVS and a string
within R, something like "$Id$" or "$RCSfile$". I usually end up
processing that thru a 'gsub' to strip out the '$' so that the log file,
which is stored in CVS as well doesn't get updated further. It is easy
to have multiple versions of a script for processing some data; knowing
the script name and directory path can help in logging what was done
with some data.
Regards,
Mark
William Dunlap wrote:
Over the years I've seen lots of requests concerning
how to conveniently call scripts from other scripts.
The S (R & S+) language is oriented towards functions,
not scripts (or macros), and many of the requests are
for things easy to do in functions (or packages of functions)
but not in scripts. Some would be easier if one used
a package of scripts (built with the usual R package
building tools).
I'd like to know from people who do this sort of thing
what pushes them toward using sets of scripts instead
of functions. I can think of several possible reasons
but would like to hear from people who actually do this
sort of thing. E.g., is the clarity and concreteness
of a script the important thing? Is it difficult to
make a package of functions? Is it that people are
used to another language where scripts or macros are
the preferred way to go? Or are other reasons?
Bill Dunlap
Spotfire, TIBCO Software
wdunlap tibco.com
-----Original Message-----
From: r-help-boun...@r-project.org
[mailto:r-help-boun...@r-project.org] On Behalf Of Ralf B
Sent: Wednesday, October 06, 2010 8:50 AM
To: r-help Mailing List
Subject: [R] Source awareness?
Here the general (perhaps silly question) first: Is it possible for a
script to find out if it was sourced by another script or run
directly?
Here a small example with two scripts:
# script A
print ("This is script A")
# script B
source("C:/scriptA.R")
print ("This is script B")
I would like to modify script A in a way so that it only outputs 'This
is script A' if it was called directly, but keeps quiet in the other
case.
In addition to that, is it possible to access the stack of script
calls from the environment?
Ralf
______________________________________________
R-help@r-project.org mailing list
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.
______________________________________________
R-help@r-project.org mailing list
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.
--
______________________________________________
R-help@r-project.org mailing list
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.
