On 13-07-28 1:55 PM, Henrik Bengtsson wrote:
On Sun, Jul 28, 2013 at 10:22 AM, Henrik Bengtsson <h...@biostat.ucsf.edu>
wrote:
On Windows, the following crashes "R for Windows terminal front-end":
R -e ""
whereas
Rterm -e "" or R -e " " (a space in the expression) doesn't.
I observe this on:
- R Under development (unstable) (2013-07-26 r63419) [Platform:
x86_64-w64-mingw32/x64 (64-bit)]
- R version 3.0.1 Patched (2013-07-25 r63414) [Platform:
x86_64-w64-mingw32/x64 (64-bit)]
- R version 3.0.1 (2013-05-16) [Platform: x86_64-w64-mingw32/x64 (64-bit)]
- R version 2.15.3 Patched (2013-03-13 r62402) [Platform:
x86_64-w64-mingw32/x64 (64-bit)]
Can others reproduce this? If so, I'll submit a bug report. (On
Linux/OSX it does not crash/core dump.).
Following Duncan Murdoch's advice in a related message, I've filed bug
report PR#15406
[https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=15406].
These bugs are both fixed now in R-devel and R-patched.
A little bit more advice on the question of "should there be a bug
report or not":
- See the discussion in ?bug.report about "When is there a bug?"
Both of Henrik's reports were clearly bugs.
- Some things are so minor that using the bug reporting system wastes
time. My own rule is that if a NEWS entry is warranted, then it is
helpful to have more depth in the discussion in the bug list. (The HTML
version of the NEWS file has hyperlinks into the bug list.) So spelling
mistakes should be reported to R-devel, not to the bug system.
- If you report to R-devel, there's a non-zero chance that your report
will be missed. If you submit a bug report, it may not be acted on, but
it will not be so easily lost.
- If you're asking for an improvement or suggesting a change, you
should almost certainly start in R-devel, not in the bug list. People
might disagree about the value of your suggestion. If there's general
agreement, you can post it as a bug report with "Wishlist" in the
subject heading.
- If you do post something as a bug report, it may be helpful to
include a suggested patch. This should be against the R-devel source,
not against a displayed version of a function or a help page. Identify
the revision number as well. ("svn diff" on an R source checkout
produces a nice patch file, including revision number.) Don't fix more
than one thing in a single patch file. Do explain what your patch does.
- Don't expect all bug reports to get action. Sometimes they just
look like too much trouble to track down and will sit in the bug list
for a long time, sometimes whoever deals with it will disagree that the
change is desirable, and will mark it as WONTFIX.
Duncan Murdoch
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
