[ESS] feature request: shell support

[Vitalie Spinu]

More I think about it more I am inclined towards adding it. The reason
is data pre-processing which is often done with one-line tools like sed
and awk. New pyed piper is coming in force http://code.google.com/p/pyp/.

I am still not sure I want to see it as part of ESS. In a long run
isolating our ess-inf into a separate package is a very good idea. Such
a package should come with a lot of load like support for eldoc,
documentation and auto-completion. So it's quite a lot of ESS to be
factored out and it is not easy without rewriting a lot of it.


   Vitalie



 >>> Rodney Sparapani on Thu, 10 Oct 2013 15:45:09 -0500 wrote:

 > On 10/10/2013 03:07 PM, Andreas Leha wrote:
 >> As I wrote the feature request, let me comment a bit.
 >> 
 >> I completely understand your point.  And since (unfortunately) it won't
 >> be me who implements shell support in ess, I of course accept your
 >> point.
 >> 
 >> That said, see my inline comments below.
 >> 

 > Hi Andreas:

 > Well, I enjoy arguing more than actually working so see below...

 >> Rodney Sparapani<rsparapa at mcw.edu>  writes:
 >>> >Well then...  Although I am an ESS developer, this is only my
 >>> >personal opinion.  I too find myself writing Bourne shell scripts
 >>> >(for the last 20 years now ;o)  However, I feel that the emacs
 >>> >community is well aware of the Bourne shell and its imitators.
 >> Can you point to any emacs shell support, that comes close to what ess
 >> can do for real (?) statistical languages in terms of connecting the
 >> script with a process?
 >> 

 > No.  But, that doesn't mean it doesn't exist.  I can't keep up with
 > all of the different emacs modes that are floating around cyberspace.

 >>> >
 >>> >IMHO the ESS developers want to fill the niche that
 >>> >statisticians and statistical programmers/analysts find
 >>> >in emacs.  There are a lot of things that would be nice to
 >>> >have that we are not going to be able to add due to time,
 >>> >warm bodies, climate change, etc.
 >> As also others have argued, shell scripting can be seen as being part of
 >> the full statistical workflow.  I assume, you'd not want to do your real
 >> (?) statistical scripting without ess' support for sending code from
 >> your script to the process.  Why would you not want similar support for
 >> the part of the data analysis, that is done in the shell?
 >> So, the step to shell support, for me, is a natural one, the step to
 >> climate change is not.
 >> 

 > My point is that as statisticians, we pick our battles.  There is a
 > reason that SAS and R are prevalent in statistics while other
 > interactive languages like Perl and Python are not.  I do agree that
 > Bourne shell scripting is worth learning; but then I am a Linux/UNIX
 > bigot who has seen the error of my OS/2 ways; lots of Windows
 > folks would disagree.

 >>> >
 >>> >When we get to that point (and I feel it is a ways off yet),
 >>> >then we could re-consider.  Normally, at this point, I would
 >>> >say glibly "patches welcome".  However, I don't think they
 >>> >really are right now.  Whenever we accept a patch, then we
 >>> >end up maintaining it (except in the rare exception when we
 >>> >can convince the author to stick around).  So, I personally
 >>> >am in no hurry; I would postpone this until the rewrite is
 >>> >complete when we can consider what languages to add then.
 >> This already sounds as if such a rewrite will definitely happen -- even
 >> if ways off.  That is nice.
 >> 

 > Yes, we have been talking about it, but talk is cheap ;o)

 >>> >
 >>> >I have my doubts whether the Bourne shell will be able to compete
 >>> >for attention with julia, polymode, SLIME[R] and/or whatever new
 >>> >fangled flavor of the month the kids come up with.  But that's
 >>> >just the opinion of one eternal pessimist.
 >> Given that you have done shell scripts for 20 years, you probably agree,
 >> that shell scripting is not one of the 'new fangled flavor[s] of the
 >> month'.

 > I do.  But, I meant it in the mindshare sense.  IMHO there will always
 > be something that we would rather add than shell scripting whether
 > right or wrong.  Polymode and SLIME[R] are just too sexy to resist
 > while it's easy to poo poo stodgy old shell scripts.