Re: Q on using shell mode remotely

[Kevin Rodgers <ihs_4664@yahoo.com>]

Drew Adams wrote:
> Kevin Rodgers wrote:
>     Why can't you just add a time pattern to telnet-prompt-pattern, which is
>     used to set the buffer-local value of comint-prompt-pattern:
> 
>     (eval-after-load "telnet"
>        '(setq telnet-prompt-pattern
>            (concat telnet-prompt-pattern
>     "\\([12]?[0-9]:[0-5][0-9][ap]m\\)?")))
> 
> Thanks again. I didn't know about `telnet-prompt-pattern'. I used `C-h m'
> and searched for "prompt", but the only occurences there are
> `comint-next-prompt' and `comint-previous-prompt'. I found nothing in the
> manual either. (I should have just used completion or apropos to look for a
> "telnet-" prompt variable.)
> 
> I'll use `telnet-prompt-pattern', myself, to hack this problem,

Please let us know if it works.  Looking at telnet.el:

1. M-x telnet runs telnet-program via make-comint, with
    telnet-initial-filter as the process filter, then calls telnet-mode.

2. telnet-mode sets the buffer-local value of comint-prompt-regexp to
    telnet-prompt-pattern.

3. telnet-initial-filter calls invokes
    telnet-check-software-type-initialize, then resets the process filter
    to telnet-filter.

    a. If telnet-check-software-type-initialize sees "unix" in its STRING
    argument, it resets telnet-prompt-pattern to comint-prompt-regexp;
    then regardless of STRING, it resets comint-prompt-regexp to
    telnet-prompt-pattern.

So it seems that (3) could prevent (2) from accomplishing its intended
effect, if (3) ran before (2).

Then, comint.el ignores comint-prompt-regexp anyway unless
comint-use-prompt-regexp is non-nil -- but it is nil by default, and
telnet doesn't set it.  So comint is assigning `field' text properties
to distinguish program (csh) output such as prompts from user input.

> but it would
> be good if there were a variable that dealt with $rprompt somehow.

I don't see how it could.  The remote csh presumably displays $rprompt
on the right side of the screen via terminal escape codes or simple
ASCII control characters; but the telnet subprocess is discarding that
data, either explicitly via telnet-filter or implicitly via process-
connection-type.  So you end up with $rprompt displayed immediately
adjacent to $prompt in your *telnet-HOST* buffer, and you've got to
account for that via telnet-prompt-regexp.

-- 
Kevin