Re: 'call' function disables echoing input

2009-05-08 Thread Kriangkrai Soatthiyanont 
Hi Alex,

Many thanks! Now it works, though it would be much better to have
'call' working correctly.

(de shell* (S)   # run shell command with interactive input
   (let Raw (raw)
  (unless Raw (raw T))
  (let Opts '(icrnl icanon iexten echo echoe echok echoctl echoke)
  #! use (call stty) to see what options need to be toggled
 (call sh -c (pack stty  (glue   Opts) ;  S ; stty
- (glue  - Opts)))
  (unless Raw (raw NIL)) )))
(shell* echo -n 'name: '; read name; echo $name)

Best regards,
KS
-- 
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe

Re: 'call' function disables echoing input

2009-05-08 Thread Randall Dow 
Hi Alex,

Do shells really?  A simple case of the opposite: start vim, kill -9
from another shell, and you have to type stty sane.  I think it is
more up to the application to save and restore.

Although, picolisp does bring surprises, whether you start with dbg.l
and *Dbg on or not.

But I think the way it works is ok, there are real advantages, once
you understand it.

Cheers
- Rand

On Fri, May 8, 2009 at 2:35 PM, Alexander Burger a...@software-lab.de wrote:
 Yes. I hope in time we'll get 'call' right. It must be possible, because
 shells do the same.
-- 
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe

Re: 'call' function disables echoing input

2009-05-08 Thread Alexander Burger 
Hi Randall,

 Do shells really?  A simple case of the opposite: start vim, kill -9
 from another shell, and you have to type stty sane.  I think it is
 more up to the application to save and restore.

That's true. What I meant, however, was the handling of terminal I/O and
the 'stop' signal in processes spawned by this shell.


When you invoke 'vim' in PicoLisp, it behaves correctly: Terminal I/O
obviously works (as you can edit in 'vim'), and if you hit Ctrl-Z 'vim'
is stopped and control is back at PicoLisp (i.e. our shell). You are
now in PicoLisp at a special prompt ('+'). When you hit Enter hat that
prompt, 'vim' gets a 'cont' signal and you can continue editing'.
Otherwise, if you hit Ctrl-Z again at the '+' prompt, you drop back into
the bash. There back to PicoLisp with 'fg', and Enter to 'vim'.

So this is the behavior I intended.


However, in Kriangkrai's situation, the spawned process (a shell) does
not receive any terminal input.

   : (call 'sh -c echo -n 'name: '; read name; echo $name)

This is not only a problem of raw mode - this can be handled with
setCooked() and setRaw() at proper places in doCall() - but of keyboard
input in general. That is, the 'read' in the shell immediately receives
EOF and returns.

I can get it to work if I take out all the set process group and set
terminal foreground process group handling from doCall(). But then
neither 'vim' nor the signal handling work any longer.

So, something must still be wrong. I just never noticed it because I
only called non-interactive processes (except 'vim').

Cheers,
- Alex
-- 
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe

Re: 'call' function disables echoing input

2009-05-08 Thread Randall Dow 
Hi Alex,

 So, something must still be wrong. I just never noticed it because I
 only called non-interactive processes (except 'vim').
But that is my point - vim goes to a lot of effort to handle the STOP
and CONT signals and get the terminal handling right.  I have created
apps similar to vim - and the onus is on the app to do it right, not
the calling shell!  The calling shell does have some things to do, but
as you point out: vim and picolisp work well together!  That can only
happen if picolisp is basically doing it's part right.

(look up onus: Beweislast, Verspflichtung)

Cheers!
- Rand
-- 
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe

'call' function disables echoing input

2009-05-07 Thread Kriangkrai Soatthiyanont 
Hi,

The 'call' function seems to disable echo. Also, The Enter key does
not end an input line, Ctrl-J must be used instead.

When I run: (call 'sh -c echo -n 'name: '; read name; echo $name)
It outputs name : and waits for input. I type something (e.g. abc)
but nothing echo. I press the Enter key, nothing happens. I press
Ctrl-J, then it prints abc.

If I instead use: (call 'sh -c stty sane; echo -n 'name: '; read
name; echo $name)
It works fine, but after returning to PicoLisp prompt, line editing broke.

How to solve this this problem?

Thanks,
KS
-- 
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe

Re: 'call' function disables echoing input

2009-05-07 Thread Alexander Burger 
Hi Kriangkrai,

 When I run: (call 'sh -c echo -n 'name: '; read name; echo $name)
 It outputs name : and waits for input. I type something (e.g. abc)
 but nothing echo. I press the Enter key, nothing happens. I press
 Ctrl-J, then it prints abc.

Hmm, I cannot reproduce it in the same way, but I recognize that this is
a problem in general. In both cases when I either run it without line
editing:

   $ bin/picolisp
   : (call 'sh -c echo -n 'name: '; read name; echo $name)
   name: 
   - T

or with:

   $ ./p dbg.l
   : (call 'sh -c echo -n 'name: '; read name; echo $name)
   name: 
   - T

it immediately returns, meaning that the 'read' got EOF immediately. Not
sure if this is correct behavior.

On the other hand, things like

   : (vi file)

work well. How is that in your case?


 It works fine, but after returning to PicoLisp prompt, line editing broke.
 How to solve this this problem?

We could either insert setCooked() and setRaw() calls to the child part
of doCall() (not tried), or do it on the Lisp level:

   : (raw NIL) (call 'sh -c echo -n 'name: '; read name; echo $name) (raw T)

This, however, does not show any different bahavior on my system.


What is actually the purpose of that call?

Cheers,
- Alex
-- 
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe