Terrific, and I appreciate your thoughts and encouragement.
So, getting back on-list, I propose a backward-incompatible change, with
or without --verbose, that the --args be included in the 'av' array, and
passed to R, only if there are user arguments to follow it. The condition
for a first argument, at the time --args is currently included, is
(i0+1) < argc
Scott's fix, already in the devel version, solves my original complaint and
should continue to do so, as long as av[ac] continues to be the terminating
NULL. That is, av[ac-1] is the last argument in the R command.
On Sep 20, 2014, at 4:39 PM, Martin Maechler <maech...@stat.math.ethz.ch> wrote:
>
> On Fri, Sep 19, 2014 at 5:26 PM, Harris A. Jaffee <h...@jhu.edu> wrote:
> I must have searched the archives badly!
>
> I did not suggest that, exactly. My hack was a little more complicated,
> trying to honor what seemed to be the general intent of the code. So, I
> only conditionally echo the argument at i=ac-1 (see attached).
>
> Thank you, I understand but think it's unnecessarily complicated.
> Rather I think that the following issue should ideally be handled:
>
> There is also a more basic issue to decide, whether the "--args" should be
> sent to
> R when nothing follows it, but that debate should occur on-list, if at all.
>
> and if that is fixed (not sending '--args' if at the end), the simple fix
> for verbose printing will be enough.
>
> Yes, please go back on saying this on R-devel ... You did take it offline
> (and some say that it is not allowed to put something private suddenly back
> online, so I did not ... but do not care if you do it here).
>
>
> Martin
>
>
>
>
> On Sep 19, 2014, at 9:14 AM, Scott Kostyshak <skost...@princeton.edu> wrote:
>
> > On Fri, Sep 19, 2014 at 8:12 AM, Martin Maechler
>
> > <maech...@stat.math.ethz.ch> wrote:
> >>>>>>> Harris A Jaffee <h...@jhu.edu>
> >>>>>>> on Thu, 18 Sep 2014 19:32:29 +0200 writes:
> >>
> >> (using HTML, please don't )
> >>
> >>> The loop that echoes the arguments almost always stops too soon. It
> >>> apparently does that to avoid
> >>> echoing the "--args" (that had been inserted) when there are no user
> >>> arguments. However, when there
> >>> are user arguments, the next element of the 'av' array is the last
> >>> argument and usually not "--args",
> >>> although it can be.
> >>> ?Rscript is a little sketchy:
> >>> `--verbose' gives details of what `Rscript' is doing. Also passed
> >>> on to R.
> >>> What is passed to R is correct, but the diagnostic is not:
> >>> $ Rscript --verbose /dev/null 1 2
> >>> running
> >>> '/path_to_R --slave --no-restore --file=/dev/null --args 1'
> >>> Fixed (only tested on Mac):
> >>> $ Rscript --verbose /dev/null 1 2
> >>> running
> >>> '/Library/Frameworks/R.framework/Versions/3.1/Resources/bin/R --slave
> >>> --no-restore --file=/dev/null --args 1 2'
> >>
> >> You are right about the problem, also reproducible on Linux.
> >> You mention a 'fix'.
> >> It looks to me that is just
> >>
> >> - for(i = 1; i < ac-1; i++) fprintf(stderr, " %s", av[i]);
> >> + for(i = 1; i < ac; i++) fprintf(stderr, " %s", av[i]);
> >>
> >> in unix/Rscript.c, right ?
> >
> > Yes, I suggested the same patch here:
> > http://r.789695.n4.nabble.com/patch-Rscript-off-by-one-error-in-output-td4693780.html
> >
> > Scott
> >
> >> BTW: If one use -e 'commandArgs()' instead of /dev/null one
> >> sees that Rscript's "lying" about the last argument is not
> >> helpful anyway :
> >>
> >> Rscript --verbose -e 'commandArgs()'
> >>
> >> running
> >> '/usr/local64.sfs/app/R/R-3.1.1-inst/bin/R --slave --no-restore -e
> >> commandArgs()'
> >>
> >> [1] "/usr/local64.sfs/app/R/R-3.1.1-inst/bin/exec/R"
> >> [2] "--slave"
> >> [3] "--no-restore"
> >> [4] "-e"
> >> [5] "commandArgs()"
> >> [6] "--args"
> >>
> >> because the '--args' appears anyway and indeed *is* passed to 'R'...
> >>
> >> A better fix would rather suppress that; but I will commit the
> >> above change.
> >
> >
> > --
> > Scott Kostyshak
> > Economics PhD Candidate
> > Princeton University
> >
> > ______________________________________________
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
