TAB is something you don't want to send thru *shell*

TAB is something you don't want to send thru *shell*

[Dan Jacobson]

What is the big problem with TAB in *shell* now (21.2)?
No matter how you get a TAB into the command line, ^Q^I or paste, you
are going to get the 329 etc. possibilities treatment:
$ cat -t /tmp/a
 echo '^I'|cat -vte
$ cat /tmp/a
 echo '	'|cat -vte  <---- ok now cut and paste this line
                          at the next prompt and hit RET
$  echo '	'|cat -vte
Display all 329 possibilities? (y or n)
.AbiSuite/                               dianlidiff.txt ...
-- 
http://jidanni.org/ Taiwan(04)25854780

Re: TAB is something you don't want to send thru *shell*

[Miles Bader]

jidanni@dman.ddts.net (Dan Jacobson) writes:
> What is the big problem with TAB in *shell* now (21.2)?
> No matter how you get a TAB into the command line, ^Q^I or paste, you
> are going to get the 329 etc. possibilities treatment:

I think this is because the pty emacs uses to communciate with the
shell process is kept in cooked mode, and so it's interpreting any
terminal control characters it gets in the input.

It's a bug, though I'm not sure the right place to fix it offhand.

You can work around it by prefixing `wierd' characters like tab with a
literal ^V character (inserted using `C-q C-v').

-Miles

-- 
I have seen the enemy, and he is us.  -- Pogo

Re: TAB is something you don't want to send thru *shell*

[Andreas Schwab]

Miles Bader <miles@gnu.org> writes:

|> jidanni@dman.ddts.net (Dan Jacobson) writes:
|> > What is the big problem with TAB in *shell* now (21.2)?
|> > No matter how you get a TAB into the command line, ^Q^I or paste, you
|> > are going to get the 329 etc. possibilities treatment:
|> 
|> I think this is because the pty emacs uses to communciate with the
|> shell process is kept in cooked mode, and so it's interpreting any
|> terminal control characters it gets in the input.

TAB is not a terminal control character.  It is interpreted by readline,
because bash does not know that there is already an editing interface
running on top of it.

|> It's a bug, though I'm not sure the right place to fix it offhand.

There should be a way to tell bash not to use its readline interface when
running in a shell buffer.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: TAB is something you don't want to send thru *shell*

[Miles Bader]

Andreas Schwab <schwab@suse.de> writes:
> |> It's a bug, though I'm not sure the right place to fix it offhand.
> 
> There should be a way to tell bash not to use its readline interface when
> running in a shell buffer.

[at which point we'll start having problems with cooked mode!]

I'd prefer to change something in emacs, because it's just not
reasonable to try and figure out what the underlying program is and do
something program-specific.

For most programs that just use cooked mode, we could probably figure
out someway to do, but for programs that are directly interpreting
control characters like readline, I'm not sure what to do.

Does bash _always_ use readline, regardless of the state of the tty, or
is there some tty state that makes it think `something's funny, I'd
better not use readline' (I'd think -echo would be a clue, but I guess
not)?

-Miles
-- 
`Cars give people wonderful freedom and increase their opportunities.
 But they also destroy the environment, to an extent so drastic that
 they kill all social life' (from _A Pattern Language_)

Re: TAB is something you don't want to send thru *shell*

[Andreas Schwab]

Miles Bader <miles@gnu.org> writes:

|> Does bash _always_ use readline, regardless of the state of the tty, or
|> is there some tty state that makes it think `something's funny, I'd
|> better not use readline' (I'd think -echo would be a clue, but I guess
|> not)?

AFAIK, the only way to stop bash using readline is to pass it --noediting.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: TAB is something you don't want to send thru *shell*

[Dale Hagglund]

schwab@suse.de (Andreas Schwab) writes:

> Miles Bader <miles@gnu.org> writes:
> 
> |> jidanni@dman.ddts.net (Dan Jacobson) writes:
> |> > What is the big problem with TAB in *shell* now (21.2)?
> |> > No matter how you get a TAB into the command line, ^Q^I or paste, you
> |> > are going to get the 329 etc. possibilities treatment:
> |> 
> |> I think this is because the pty emacs uses to communciate with the
> |> shell process is kept in cooked mode, and so it's interpreting any
> |> terminal control characters it gets in the input.
> 
> TAB is not a terminal control character.  It is interpreted by readline,
> because bash does not know that there is already an editing interface
> running on top of it.

I believe that readline interprets ^V as its literal-next-char
escape.  So try the sequence

        C-q C-v C-q TAB

from inside the shell buffer and see if that helps.

Dale Hagglund.