*shell* TAB *Completions* fooled by $PWD/

*shell* TAB *Completions* fooled by $PWD/

[Dan Jacobson]

dOOds, I found a real bug!  Well! Just the other day I was, (In a
*shell* buffer) mmm, out about town you might say.  Well, at least not
in my home directory.  Oh, and did I tell you I was *root* too.
Anyways, you can see I was not in my home directory by the prompt.  I
kid you not.  Anyways, OK, I put the cursor at the end of the line you
see here

ppp# more ~/bin/modemspeedlogger.sh $PWD/

And hit TAB and low and behold, it gave me all kinds of choices
appropriate for root's home dir, not the current dir. which it knew
very well as seen by M-x pwd, M-! env also shows PWD was /etc/ppp .
-- 
http://jidanni.org/ Taiwan(04)25854780

Re: *shell* TAB *Completions* fooled by $PWD/

[Dan Jacobson]

notRMS>     ppp# more ~/bin/modemspeedlogger.sh $PWD/
notRMS>     And hit TAB and low and behold, it gave me all kinds of choices
notRMS>     appropriate for root's home dir, not the current dir. which it knew
notRMS>     very well as seen by M-x pwd, M-! env also shows PWD was /etc/ppp .

RMS> Please send a *complete precise* test case which starts with `emacs -q'.
RMS> Then I can try it.
$ cd; emacs -q
<escape> x s h e l l <return> c d SPC . . <return> m o r e SPC $ P W D / <tab>
Well, are the *Completions* those of .. or ~ ?
-- 
http://jidanni.org/ Taiwan(04)25854780

Re: *shell* TAB *Completions* fooled by $PWD/

[Miles Bader]

jidanni@dman.ddts.net (Dan Jacobson) writes:
> $ cd; emacs -q
> <escape> x s h e l l <return> c d SPC . . <return> m o r e SPC $ P W D / <tab>
> Well, are the *Completions* those of .. or ~ ?

In general, you can't rely on completion in shell-mode to know about the
exact internal state of the shell process, since there's no way for
emacs to figure that out (it tries to track the current directory, since
that's very important, but even that can sometimes get messed up).  The
value of the PWD environment variable in emacs is just whatever value it
got at startup.

-Miles
-- 
"Most attacks seem to take place at night, during a rainstorm, uphill,
 where four map sheets join."   -- Anon. British Officer in WW I

Re: *shell* TAB *Completions* fooled by $PWD/

[Dan Jacobson]

>>>>> "M" == Miles Bader <miles@lsi.nec.co.jp> writes:

M> jidanni@dman.ddts.net (Dan Jacobson) writes:
>> $ cd; emacs -q
>> <escape> x s h e l l <return> c d SPC . . <return> m o r e SPC $ P W D / <tab>
>> Well, are the *Completions* those of .. or ~ ?

M> In general, you can't rely on completion in shell-mode to know about the
M> exact internal state of the shell process, since there's no way for
M> emacs to figure that out (it tries to track the current directory, since
M> that's very important, but even that can sometimes get messed up).  The
M> value of the PWD environment variable in emacs is just whatever value it
M> got at startup.

OK, then it should admit (in the minibuffer) that it might not know
what it is/would be doing at this point, instead of confidently giving
a list that is probably wrong, and thus fooling the user into thinking
various files are/aren't in the current dir.
-- 
http://jidanni.org/ Taiwan(04)25854780

Re: *shell* TAB *Completions* fooled by $PWD/

[Kevin Rodgers]

Miles Bader wrote:

> In general, you can't rely on completion in shell-mode to know about the
> exact internal state of the shell process, since there's no way for
> emacs to figure that out (it tries to track the current directory, since
> that's very important, but even that can sometimes get messed up).  The
> value of the PWD environment variable in emacs is just whatever value it
> got at startup.


The shell.el directory tracking mechanism could be modified to update
the PWD environment variable as well as its internal variables.  But
unlike its internal variables, which can be local to the *shell* buffer,
the environment variable's value is shared via the global
process-environment Emacs variable.  (And we have to consider the case
when there's more than one *shell* buffer.)  But perhaps Shell mode could
make process-environment local to the *shell* buffer, so it would be free
to update PWD.
-- 
Kevin Rodgers <kevinr@ihs.com>

Re: *shell* TAB *Completions* fooled by $PWD/

[Miles Bader]

jidanni@dman.ddts.net (Dan Jacobson) writes:
> OK, then it should admit (in the minibuffer) that it might not know
> what it is/would be doing at this point, instead of confidently giving
> a list that is probably wrong, and thus fooling the user into thinking
> various files are/aren't in the current dir.

I'm not sure that it's worth the trouble.

-Miles
-- 
"1971 pickup truck; will trade for guns"

Re: *shell* TAB *Completions* fooled by $PWD/

[Dan Jacobson]

K> The shell.el directory tracking mechanism could be modified to update
K> the PWD environment variable as well as its internal variables.  But

actually you are going to go nuts tracking all those variables,
e.g. what if I do in a shell window,
$ cd
$ su bob
$ cd inside
etc. while you are tracking $PWD unless you somehow have a behind the
scenes connection to get the real scoop from /proc or bash itself...
Oh, and say bob's dir is mode 700
$ su -c 'echo are you still following me?; bash -i' jimmy
$ cd; echo i said su _-c_ to keep you off the trail, but then used bash -i

Anyway, it will never track perfectly.
-- 
http://jidanni.org/ Taiwan(04)25854780

Re: *shell* TAB *Completions* fooled by $PWD/

[Kevin Rodgers]

Dan Jacobson wrote:

> K> The shell.el directory tracking mechanism could be modified to update
> K> the PWD environment variable as well as its internal variables.  But
> 
> actually you are going to go nuts tracking all those variables,
> e.g. what if I do in a shell window,
> $ cd
> $ su bob
> $ cd inside
> etc. while you are tracking $PWD unless you somehow have a behind the
> scenes connection to get the real scoop from /proc or bash itself...


What do you care?  You haven't exhibited any interest at all in implementation
issues since you started bombarding this group with feature requests.

> Oh, and say bob's dir is mode 700
> $ su -c 'echo are you still following me?; bash -i' jimmy
> $ cd; echo i said su _-c_ to keep you off the trail, but then used bash -i
> 
> Anyway, it will never track perfectly.


The point is that however well it does track could be made available to
the user for completion via the PWD environment variable as well as the
default-directory Emacs variable.


-- 
Kevin Rodgers <kevinr@ihs.com>

Re: *shell* TAB *Completions* fooled by $PWD/

[David Kastrup]

jidanni@dman.ddts.net (Dan Jacobson) writes:

> K> The shell.el directory tracking mechanism could be modified to update
> K> the PWD environment variable as well as its internal variables.  But
> 
> actually you are going to go nuts tracking all those variables,
> e.g. what if I do in a shell window,
> $ cd
> $ su bob
> $ cd inside
> etc. while you are tracking $PWD unless you somehow have a behind the
> scenes connection to get the real scoop from /proc or bash itself...
> Oh, and say bob's dir is mode 700
> $ su -c 'echo are you still following me?; bash -i' jimmy
> $ cd; echo i said su _-c_ to keep you off the trail, but then used bash -i
> 
> Anyway, it will never track perfectly.

Use
M-x eshell RET
Whatever it will be tracking, Emacs will know about it.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: David.Kastrup@t-online.de

Re: *shell* TAB *Completions* fooled by $PWD/

[Richard Stallman]

    The shell.el directory tracking mechanism could be modified to update
    the PWD environment variable as well as its internal variables.  But
    unlike its internal variables, which can be local to the *shell* buffer,
    the environment variable's value is shared via the global
    process-environment Emacs variable.

shell.el could temporarily bind process-environment to a modified
value which incorporate's the shell's current directory before it
does the completion.  That would fix this particulr problem.

However, in general shell programs can set various environment
variables.  If Emacs shell completion tries to do something with
environment variables, it will be wrong a lot of the time.  Emacs
tracks the current directory but it does not track environment
variable assignments.

Perhaps this means that Shell mode commands should never expand
environment variables.  If we leave it for the shell to expand them,
it will at least expand them consistently.

What do people think about this?  Are there cases where Shell mode
commands that expand envvars which would be greatly missed?

Re: *shell* TAB *Completions* fooled by $PWD/

[Miles Bader]

rms@gnu.org (Richard Stallman) writes:
> Perhaps this means that Shell mode commands should never expand
> environment variables.  If we leave it for the shell to expand them,
> it will at least expand them consistently.
> 
> What do people think about this?  Are there cases where Shell mode
> commands that expand envvars which would be greatly missed?

YES!!  I use (constant) environment variables _constantly_ and I
heavily depend on them being expanded by completion in shell mode!

I think this `problem' is very minor, and in fact we really don't need
to change anything.

-Miles
-- 
Come now, if we were really planning to harm you, would we be waiting here, 
 beside the path, in the very darkest part of the forest?

Re: *shell* TAB *Completions* fooled by $PWD/

[David Kastrup]

miles@gnu.org (Miles Bader) writes:

> rms@gnu.org (Richard Stallman) writes:
> > Perhaps this means that Shell mode commands should never expand
> > environment variables.  If we leave it for the shell to expand them,
> > it will at least expand them consistently.
> > 
> > What do people think about this?  Are there cases where Shell mode
> > commands that expand envvars which would be greatly missed?
> 
> YES!!  I use (constant) environment variables _constantly_ and I
> heavily depend on them being expanded by completion in shell mode!
> 
> I think this `problem' is very minor, and in fact we really don't need
> to change anything.

Well, perhaps one could make C-u TAB ask the shell itself for
an update on the shell's environment in some manner?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: David.Kastrup@t-online.de

Re: *shell* TAB *Completions* fooled by $PWD/

[Miles Bader]

David.Kastrup@t-online.de (David Kastrup) writes:
> Well, perhaps one could make C-u TAB ask the shell itself for
> an update on the shell's environment in some manner?

This is a hard problem to solve, and I suspect that very few people are
bitten by it (the sort of person who uses env vars like that is also
usually clueful enough to realize why it won't work in some cases).

We can add a hack for PWD if that makes people feel fuzzy.

-Miles
-- 
`The suburb is an obsolete and contradictory form of human settlement'

Re: *shell* TAB *Completions* fooled by $PWD/

[David Kastrup]

miles@gnu.org (Miles Bader) writes:

> David.Kastrup@t-online.de (David Kastrup) writes:
> > Well, perhaps one could make C-u TAB ask the shell itself for
> > an update on the shell's environment in some manner?
> 
> This is a hard problem to solve,

Well, that's why I wanted to use a prefix argument in order to tell
Emacs it better ask the shell itself for the environment variable.

> and I suspect that very few people are bitten by it (the sort of
> person who uses env vars like that is also usually clueful enough to
> realize why it won't work in some cases).
> 
> We can add a hack for PWD if that makes people feel fuzzy.

Don't think that would be much needed: after all, one can use ~
expansion instead.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: David.Kastrup@t-online.de

Re: *shell* TAB *Completions* fooled by $PWD/

[Kevin Rodgers]

David Kastrup wrote:

> miles@gnu.org (Miles Bader) writes:
>>David.Kastrup@t-online.de (David Kastrup) writes:
>>> Well, perhaps one could make C-u TAB ask the shell itself for
>>> an update on the shell's environment in some manner?
>>
>>and I suspect that very few people are bitten by it (the sort of
>>person who uses env vars like that is also usually clueful enough to
>>realize why it won't work in some cases).
>>
>>We can add a hack for PWD if that makes people feel fuzzy.
>>
> 
> Don't think that would be much needed: after all, one can use ~
> expansion instead.

What does PWD have to do with ~?

-- 
Kevin Rodgers <kevinr@ihs.com>

Re: *shell* TAB *Completions* fooled by $PWD/

[David Kastrup]

kevinr@ihs.com (Kevin Rodgers) writes:

> David Kastrup wrote:
> 
> > miles@gnu.org (Miles Bader) writes:
> >>David.Kastrup@t-online.de (David Kastrup) writes:
> >>> Well, perhaps one could make C-u TAB ask the shell itself for
> >>> an update on the shell's environment in some manner?
> >>
> >>and I suspect that very few people are bitten by it (the sort of
> >>person who uses env vars like that is also usually clueful enough to
> >>realize why it won't work in some cases).
> >>
> >>We can add a hack for PWD if that makes people feel fuzzy.
> >>
> > Don't think that would be much needed: after all, one can use ~
> > expansion instead.
> 
> What does PWD have to do with ~?

Nothing.  I confused this with HOME.  But you could use ./, or even
`pwd`.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: David.Kastrup@t-online.de

Re: *shell* TAB *Completions* fooled by $PWD/

[Andreas Schwab]

Kevin Rodgers <kevinr@ihs.com> writes:

|> What does PWD have to do with ~?

In Bash (and ksh) ~+ == $PWD.

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: *shell* TAB *Completions* fooled by $PWD/

[Kai Großjohann]

miles@gnu.org (Miles Bader) writes:

> David.Kastrup@t-online.de (David Kastrup) writes:
>> Well, perhaps one could make C-u TAB ask the shell itself for
>> an update on the shell's environment in some manner?
>
> This is a hard problem to solve,

Isn't it enough to just send the current contents of the line,
followed by TAB, to the shell and to parse the output?

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: *shell* TAB *Completions* fooled by $PWD/

[Miles Bader]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> > This is a hard problem to solve,
> 
> Isn't it enough to just send the current contents of the line,
> followed by TAB, to the shell and to parse the output?

There are many annoying little wrinkles involved in doing this
correctly, so that it's definitely not a `just' thing.

Annoying little wrinkle (1): you don't actually know who's listening
when you send input to the subprocess -- it may be the shell you
started, it may be some process running under the shell...

[The recent conversation about python-mode is a somewhat different case,
because there you can make more assumptions about what the subprocess is
doing.]

-Miles
-- 
Saa, shall we dance?  (from a dance-class advertisement)

Re: *shell* TAB *Completions* fooled by $PWD/

[Kai Großjohann]

miles@gnu.org (Miles Bader) writes:

> Annoying little wrinkle (1): you don't actually know who's listening
> when you send input to the subprocess -- it may be the shell you
> started, it may be some process running under the shell...

That could be "solved" by documenting it properly: just say that C-u
TAB sends input to the remote shell and that things will break if
there is no remote shell.

After all, RET isn't all that different: it also just sends input to
the remote end, and it doesn't care whether it's really a shell...

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: *shell* TAB *Completions* fooled by $PWD/

[Andreas Schwab]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai writes:

|> miles@gnu.org (Miles Bader) writes:
|> 
|> > Annoying little wrinkle (1): you don't actually know who's listening
|> > when you send input to the subprocess -- it may be the shell you
|> > started, it may be some process running under the shell...
|> 
|> That could be "solved" by documenting it properly: just say that C-u
|> TAB sends input to the remote shell and that things will break if
|> there is no remote shell.
|> 
|> After all, RET isn't all that different: it also just sends input to
|> the remote end, and it doesn't care whether it's really a shell...

This is quite different because after sending input with RET you don't
expect any particular response.

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."