[R] Can't there be a cd command?

Duncan Murdoch murdoch at stats.uwo.ca
Wed May 10 17:26:55 CEST 2006


On 5/10/2006 11:10 AM, Gabor Grothendieck wrote:
> On 5/10/06, Duncan Murdoch <murdoch at stats.uwo.ca> wrote:
>> On 5/10/2006 10:45 AM, Gabor Grothendieck wrote:
>> > On 5/10/06, Duncan Murdoch <murdoch at stats.uwo.ca> wrote:
>> >> On 5/10/2006 9:29 AM, Paul Johnson wrote:
>> >> > It is a FAQ in our Linux lab.  People start emacs and fire up R via
>> >> > ess, and then they have no idea 'where they are".  For computer
>> >> > experts, it is not a problem, but for people who don't know much about
>> >> > computers, it is a pretty big problem.  They have data in some
>> >> > subdirectory, but almost invariably they don't get emacs & R started
>> >> > from that same place.
>> >> >
>> >> > Unfortunately, for our users, it does not help to simply re-label
>> >> > setwd as cd.  Both commands imply a deeper understanding of the OS
>> >> > than they have.  Also, unfortunately, these are the same people who
>> >> > don't understand that FAQs exist and should be consulted. These people
>> >> > are so new/timid that asking in r-help would be the last thing to
>> >> > cross their mind.
>> >> >
>> >> > I've wondered if it would not help to have the R prompt include the
>> >> > directory name, as in an x terminal.
>> >>
>> >> I think file system directories aren't as central in R as they are in a
>> >> shell, so it would just be distracting.  Most of the time I work in the
>> >> R workspace, not in the file system.
>> >>
>> >> To me the solution is to allow interactive file selection by default,
>> >> i.e. the default on read.table and similar functions should be
>> >> file.choose(), rather than having no default and throwing an error.
>> >> This won't help you in the short run (because file.choose() on Linux
>> >> isn't all that friendly to beginners), but perhaps it would encourage
>> >> someone to make it better.  file.choose() is quite nice in Windows (and
>> >> I think on the Mac), so beginners there could be told
>> >>
>> >> mydf <- read.table()
>> >>
>> >> and they'd get something useful.
>> >>
>> >> Martin Maechler has disagreed with me about this in the past, but hasn't
>> >> convinced me that he's right, he's just convinced me that doing nothing
>> >> is easier than arguing about it.
>> >
>> > I agree with Martin regarding read.table; however, the underlying idea is
>> > good and could be achieved via simple wrappers which are the same
>> > as the corresponding underlying functions except for the default argument
>> > to file:
>> >
>> >    read.table.choose <- function(file = file.choose(), ...)
>> > read.table(file, ...)
>> >    read.csv.choose <- function(file = file.choose(), ...) read.csv(file, ...)
>> >    read.delim.choose <- function(file = file.choose(), ...)
>> > read.delim(file, ...)
>> >
>> >   # test
>> >   mydata <- read.table.choose()
>> >
>> > in a package available to the users or possibly even in R core.
>>
>> No, I don't think this is a good idea.  It would be just as easy to tell
>> people to type
>>
>> read.table(file=file.choose())
>>
>> with no new package or function necessary.  I want the existing basic
>> function to work when used by a beginner in a simple way.
> 
> I don't think that an idiom of multiple function calls is as simple as
> issuing a single function call with no args.
> 
> One possibility is to have
> a keyword "choose" on the file function in the same way that file
> accepts the keyword "clipboard".  Then one could write:
> 
>   mydata <- read.table("choose")
> 
> I think the wrapper approach is probably preferable though and seems
> consistent with the way R deals with this in other places such as the
> ISOdate wrapper.
> 
> 
>>
>> What is it that you find objectionable about having a default for the
>> file argument in read.table?  I think Martin has said that he doesn't
>> want non-UI functions to be involved with UI functions, but I don't see
>> that:  if your code works now, it will be completely unaffected by
>> setting a default for the argument.  (Sorry if I summarized the argument
>> incorrectly, Martin, I didn't look it up.)
> 
> That would be my objection too.  UI should not be tied to the non-UI core.
> Its basically a loose coupling argument.

I don't accept that argument, because in R everything* is interactive. 
There isn't a non-UI core.  The function arguments are part of the user 
interface.

Duncan Murdoch

* Well, maybe this should be restricted to functions visible to the 
user, but everything we've been discussing so far is visible and is part 
of the user interface.




More information about the R-help mailing list