Re: Using zle outside zsh

[DervishD <disposable1@xxxxxxxxxxxxxx>]

    Hi Bart :)

 * Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> dixit:
> > # This worked as before since the line is exactly 'ftp> '.
> > # Same for telnet
> > zpty -r ftp response '(|*\n)ftp> '
> zpty -r ftp response $'(|*\n)ftp> '
> Note the dollar-sign.  Without that the \n is not converted to a newline.

    I see... I assumed the single quote was enough because it was
enough in a 'print' statement. Obviously, I did not remember that $''
does exactly that: interpret the string as if it were passed to the
'print' builtin...
 
> Also, you do NOT want "zpty -b".  It makes the PTY non-blocking in *both*
> directions, which confuses ftp into insanity.  It may even have exited by
> the time you first try to write to it.

    I was testing first with telnet and used '-b' for a test. And I
forgot to remove it O:) Yes, ftp gets confused (and telnet too) if
'-b' is used.

> As for other reads hanging forever ... well, "ftp> " isn't the only prompt
> that might be printed.  It may be asking for a username or a password, for
> example, and "password: " won't match the pattern.  Try something like
> 
> zpty -r ftp response $'(|*\n)(ftp> |*[[:punct:]]: |Password:)'

    Oh, don't worry, I'm just testing the read-write loop. After that
I'll check which other prompts I must take care of. For example, if
you issue 'open' in the ftp main prompt, ftp asks you the address
using '(to)' (at least the client I'm using).
 
> Finally, vared is probably printing a carriage return and thereby erasing 
> the last line of the "print -nr" output, which might fool you into 
> thinking the read is hung.

    Yes, that's exactly what is happening. If I insert a delay
between the first read and the vared call, I can see the output from
the "print -nr" command.

>  So pick the last line out of $response and
> pass that to vared as the prompt, like so:
> pmpt=${response##$'*\n'}

    I must use "${response##*$'\n'}" or it doesn't work because the
'*' is quoted, but otherwise it works perfectly. Is there a way of
making 'vared' not to print a carriage return?

    OTOH, I think that, for a program like 'ftp' that not only prints
its own set of prompts but uses some server responses as prompts, it
would be better to read line by line until no more lines are present,
then use the last line as the prompt, but that involves using a while
loop and using 'zpty -rt', and that leads to a minor race, when we
write in the pty and wait for a response. Obviously the answer
doesn't need to be instantaneous, and that makes the first 'zpty -rt'
to fail :( Using the delay doesn't solve the problem, either: the
last line (that one containing the prompt) is not returned.

    Seems that the only possible solutions is to know in advance all
possible prompts and use 'zpty -r COMMAND NAME PATTERN', or using
zselect, or even using a proxy program that translates and normalizes
all received prompts including a '\n', or something like that...

    Thanks, Bart, for you answer :)

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736
http://www.pleyades.net & http://raul.pleyades.net/