the maple interface is broken in some configurations

[was]

G Edgar reported that on his mac the maple interface fails miserably to work at all. On sage.math it works perfectly. On my laptop (osx10.5.1 w/ maple 11) it does NOT work now.

On my laptop:

sage: maple.eval('2+2')
'read "/Users/was/.sage//temp/D_69_91_158_192.dhcp4.washington.edu/10242//i'

Gerald Edgar:

13> sage
----------------------------------------------------------------------
| SAGE Version 2.8.15, Release Date: 2007-12-03                      |
| Type notebook() for the GUI, and license() for information.        |
----------------------------------------------------------------------

sage: maple.eval('2+2')
End Of File (EOF) in read_nonblocking(). Empty string style platform.
<pexpect.spawn instance at 0x9466378>
version: 2.0 ($Revision: 1.151 $)
command: /Applications/sage-2.8.15-osx10.4-ppc-PowerMacintosh-Darwin/
local/bin/maple
args: ['/Applications/sage-2.8.15-osx10.4-ppc-PowerMacintosh-Darwin/
local/bin/maple', '-t']
patterns:
   #-->
buffer (last 100 chars):
before (last 100 chars):
after: <class 'pexpect.EOF'>
match: None
match_index: None
exitstatus: None
flag_eof: 1
pid: 16993
child_fd: 3
timeout: 30
delimiter: <class 'pexpect.EOF'>
logfile: None
maxread: 100
searchwindowsize: None
delaybeforesend: 0
#-->quit;
bytes used=487432, alloc=393144, time=0.03
---------------------------------------------------------------------------
<type 'exceptions.RuntimeError'>          Traceback (most recent call
last)
...
   465         with gc_disabled():

<type 'exceptions.RuntimeError'>: Unable to start maple
sage: maple.eval('2+2')
'read "/Users/edgar/.sage//temp/dizzy.math.ohio_state.edu/16989//
interface/'
sage: maple.eval('2+2')
''
sage: maple.eval('2+2')
'4'
sage:

[tjlahey]

I get the same error (OS X 10.5.5, Sage 3.2). I first noticed it when I tried to include Maple in my integration tests. Trying the same thing:

maple.eval('2+2')
'read "/Users/tjlahey/.sage//temp/Cameron.local/61581//interface//tmp61581"'

[migeruhito]

See Ticket #12295.

[kcrisman]

I think that we should close this one in favor of #12295 and #2120, both of which already have a patch (I'm not sure if they conflict or are orthogonal).