* *shell* TAB *Completions* fooled by $PWD/ @ 2002-07-07 21:13 Dan Jacobson [not found] ` <200207081820.g68IKeP12935@aztec.santafe.edu> 0 siblings, 1 reply; 21+ messages in thread From: Dan Jacobson @ 2002-07-07 21:13 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
[parent not found: <200207081820.g68IKeP12935@aztec.santafe.edu>]
* Re: *shell* TAB *Completions* fooled by $PWD/ [not found] ` <200207081820.g68IKeP12935@aztec.santafe.edu> @ 2002-07-09 0:24 ` Dan Jacobson 2002-07-09 7:54 ` Miles Bader 0 siblings, 1 reply; 21+ messages in thread From: Dan Jacobson @ 2002-07-09 0:24 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: *shell* TAB *Completions* fooled by $PWD/ 2002-07-09 0:24 ` Dan Jacobson @ 2002-07-09 7:54 ` Miles Bader 2002-07-10 6:03 ` Dan Jacobson 2002-07-10 16:48 ` Kevin Rodgers 0 siblings, 2 replies; 21+ messages in thread From: Miles Bader @ 2002-07-09 7:54 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: *shell* TAB *Completions* fooled by $PWD/ 2002-07-09 7:54 ` Miles Bader @ 2002-07-10 6:03 ` Dan Jacobson 2002-07-10 17:31 ` Miles Bader 2002-07-10 16:48 ` Kevin Rodgers 1 sibling, 1 reply; 21+ messages in thread From: Dan Jacobson @ 2002-07-10 6:03 UTC (permalink / raw) >>>>> "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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: *shell* TAB *Completions* fooled by $PWD/ 2002-07-10 6:03 ` Dan Jacobson @ 2002-07-10 17:31 ` Miles Bader 0 siblings, 0 replies; 21+ messages in thread From: Miles Bader @ 2002-07-10 17:31 UTC (permalink / raw) 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" ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: *shell* TAB *Completions* fooled by $PWD/ 2002-07-09 7:54 ` Miles Bader 2002-07-10 6:03 ` Dan Jacobson @ 2002-07-10 16:48 ` Kevin Rodgers 2002-07-10 17:45 ` Dan Jacobson 2002-07-11 12:01 ` Richard Stallman 1 sibling, 2 replies; 21+ messages in thread From: Kevin Rodgers @ 2002-07-10 16:48 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: *shell* TAB *Completions* fooled by $PWD/ 2002-07-10 16:48 ` Kevin Rodgers @ 2002-07-10 17:45 ` Dan Jacobson 2002-07-10 18:21 ` Kevin Rodgers 2002-07-10 18:30 ` David Kastrup 2002-07-11 12:01 ` Richard Stallman 1 sibling, 2 replies; 21+ messages in thread From: Dan Jacobson @ 2002-07-10 17:45 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: *shell* TAB *Completions* fooled by $PWD/ 2002-07-10 17:45 ` Dan Jacobson @ 2002-07-10 18:21 ` Kevin Rodgers 2002-07-10 18:30 ` David Kastrup 1 sibling, 0 replies; 21+ messages in thread From: Kevin Rodgers @ 2002-07-10 18:21 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: *shell* TAB *Completions* fooled by $PWD/ 2002-07-10 17:45 ` Dan Jacobson 2002-07-10 18:21 ` Kevin Rodgers @ 2002-07-10 18:30 ` David Kastrup 1 sibling, 0 replies; 21+ messages in thread From: David Kastrup @ 2002-07-10 18:30 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: *shell* TAB *Completions* fooled by $PWD/ 2002-07-10 16:48 ` Kevin Rodgers 2002-07-10 17:45 ` Dan Jacobson @ 2002-07-11 12:01 ` Richard Stallman 2002-07-11 13:26 ` Miles Bader 1 sibling, 1 reply; 21+ messages in thread From: Richard Stallman @ 2002-07-11 12:01 UTC (permalink / raw) Cc: gnu-emacs-bug 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? ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: *shell* TAB *Completions* fooled by $PWD/ 2002-07-11 12:01 ` Richard Stallman @ 2002-07-11 13:26 ` Miles Bader 2002-07-11 13:30 ` David Kastrup 0 siblings, 1 reply; 21+ messages in thread From: Miles Bader @ 2002-07-11 13:26 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: *shell* TAB *Completions* fooled by $PWD/ 2002-07-11 13:26 ` Miles Bader @ 2002-07-11 13:30 ` David Kastrup 2002-07-11 13:55 ` Miles Bader 0 siblings, 1 reply; 21+ messages in thread From: David Kastrup @ 2002-07-11 13:30 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: *shell* TAB *Completions* fooled by $PWD/ 2002-07-11 13:30 ` David Kastrup @ 2002-07-11 13:55 ` Miles Bader 2002-07-11 14:31 ` David Kastrup 2002-07-17 16:58 ` Kai Großjohann 0 siblings, 2 replies; 21+ messages in thread From: Miles Bader @ 2002-07-11 13:55 UTC (permalink / raw) 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' ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: *shell* TAB *Completions* fooled by $PWD/ 2002-07-11 13:55 ` Miles Bader @ 2002-07-11 14:31 ` David Kastrup 2002-07-11 17:06 ` Kevin Rodgers 2002-07-17 16:58 ` Kai Großjohann 1 sibling, 1 reply; 21+ messages in thread From: David Kastrup @ 2002-07-11 14:31 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: *shell* TAB *Completions* fooled by $PWD/ 2002-07-11 14:31 ` David Kastrup @ 2002-07-11 17:06 ` Kevin Rodgers 2002-07-11 23:05 ` David Kastrup 2002-07-12 8:09 ` Andreas Schwab 0 siblings, 2 replies; 21+ messages in thread From: Kevin Rodgers @ 2002-07-11 17:06 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: *shell* TAB *Completions* fooled by $PWD/ 2002-07-11 17:06 ` Kevin Rodgers @ 2002-07-11 23:05 ` David Kastrup 2002-07-12 8:09 ` Andreas Schwab 1 sibling, 0 replies; 21+ messages in thread From: David Kastrup @ 2002-07-11 23:05 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: *shell* TAB *Completions* fooled by $PWD/ 2002-07-11 17:06 ` Kevin Rodgers 2002-07-11 23:05 ` David Kastrup @ 2002-07-12 8:09 ` Andreas Schwab 1 sibling, 0 replies; 21+ messages in thread From: Andreas Schwab @ 2002-07-12 8:09 UTC (permalink / raw) Cc: gnu-emacs-bug 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." ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: *shell* TAB *Completions* fooled by $PWD/ 2002-07-11 13:55 ` Miles Bader 2002-07-11 14:31 ` David Kastrup @ 2002-07-17 16:58 ` Kai Großjohann 2002-07-17 18:26 ` Miles Bader 1 sibling, 1 reply; 21+ messages in thread From: Kai Großjohann @ 2002-07-17 16:58 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: *shell* TAB *Completions* fooled by $PWD/ 2002-07-17 16:58 ` Kai Großjohann @ 2002-07-17 18:26 ` Miles Bader 2002-07-18 12:01 ` Kai Großjohann 0 siblings, 1 reply; 21+ messages in thread From: Miles Bader @ 2002-07-17 18:26 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: *shell* TAB *Completions* fooled by $PWD/ 2002-07-17 18:26 ` Miles Bader @ 2002-07-18 12:01 ` Kai Großjohann 2002-07-18 12:18 ` Andreas Schwab 0 siblings, 1 reply; 21+ messages in thread From: Kai Großjohann @ 2002-07-18 12:01 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: *shell* TAB *Completions* fooled by $PWD/ 2002-07-18 12:01 ` Kai Großjohann @ 2002-07-18 12:18 ` Andreas Schwab 0 siblings, 0 replies; 21+ messages in thread From: Andreas Schwab @ 2002-07-18 12:18 UTC (permalink / raw) 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." ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2002-07-18 12:18 UTC | newest] Thread overview: 21+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2002-07-07 21:13 *shell* TAB *Completions* fooled by $PWD/ Dan Jacobson [not found] ` <200207081820.g68IKeP12935@aztec.santafe.edu> 2002-07-09 0:24 ` Dan Jacobson 2002-07-09 7:54 ` Miles Bader 2002-07-10 6:03 ` Dan Jacobson 2002-07-10 17:31 ` Miles Bader 2002-07-10 16:48 ` Kevin Rodgers 2002-07-10 17:45 ` Dan Jacobson 2002-07-10 18:21 ` Kevin Rodgers 2002-07-10 18:30 ` David Kastrup 2002-07-11 12:01 ` Richard Stallman 2002-07-11 13:26 ` Miles Bader 2002-07-11 13:30 ` David Kastrup 2002-07-11 13:55 ` Miles Bader 2002-07-11 14:31 ` David Kastrup 2002-07-11 17:06 ` Kevin Rodgers 2002-07-11 23:05 ` David Kastrup 2002-07-12 8:09 ` Andreas Schwab 2002-07-17 16:58 ` Kai Großjohann 2002-07-17 18:26 ` Miles Bader 2002-07-18 12:01 ` Kai Großjohann 2002-07-18 12:18 ` Andreas Schwab
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).