shivers@cs.cmu.edu (Olin Shivers) (02/25/90)
From: scott@grlab.UUCP (Scott Blachowicz) Newsgroups: comp.emacs Date: 21 Feb 90 15:35:59 GMT Is it possible to have the shell mode re-sync its current-directory on a pwd command? Either by recognizing that a pwd command was typed or by a key-binding that somehow figures it out (send a pwd command and get the response)? Maybe there could be a regexp that describes what a "pwd" command will look like that gets matched against the command. Now, I don't know enough to know how possible it would be to grab the command's output (if it can even be reliably identified). It is not possible to reliably track the current working directory %100 of the time. Forget it. You can always run some random program under your shell that takes "cd" or "pwd" arguments and does strange things with them; the gnumacs code will never know this. FTP's "cd" command is one example. Stuffing a "dirs" or "pwd" command to the shell and analysing the result is just as ugly and fragile a hack, for similar reasons. That's why I haven't put these things into cmushell mode. The attitude you have to take in situations like this is that simple heuristics like cd/pushd/popd tracking will get you 95% of the cases, and for the rest, you just have to reset the buffer's idea of where you are with a M-x cd <dir> command. Don't stress out about it. Does the new directory tracking stuff allow me to say "cd -" to "goto the previous directory"? My ksh allows that (actually, I think it's a bunch of functions that get loaded up that do it). I don't use ksh, so I'm not familiar enough with it to hack in ksh-specific things. That's a fine idea, though, and you should not find it very hard to modify the standard directory-tracking function to handle this case. -Could it recognize a "Password:" prompt at the beginning of a line and not echo the chars? or is there a better way to get a super-user shell? Comint provides a general send-invisible command for entering text that should be sent to a process but should not be echoed. M-x send-invisible <password> return is what you do when you're prompted for your password, for instance. -A lot of times, when I run an interactive command I start getting commands echoed back at me, and sometimes "^M" at the end of each line... Would this be because the command is doing some stty/ioctl commands? Anyone know of the magic incantation to give stty to correct things? Either the command or your shell has decided to do echoing in raw/cbreak mode. If you can turn this off, you win. At CMU, we run a locally-developed shell that does line-editing, command history and filename completion. There are a lot of shells like it: ksh, tcsh, I don't know -- a bunch. The point is, this shell puts the tty in raw mode, so when you run it under emacs in cmushell mode, it echoes everything, and tosses in ^M's as well. The solution is make sure that cmushell runs the vanilla /bin/csh that doesn't do any of this stuff, which you arrange with (setq explicit-shell-file-name "/bin/csh") in your .emacs. -Olin
rsm@math.arizona.edu (Robert S. Maier) (02/26/90)
In article <wZtrldm00htFFhJS9X@cs.cmu.edu> Olin Shivers writes, apropos of cmushell-mode and shell-mode getting confused by `cd' commands: >It is not possible to reliably track the current working directory >100% of the time. Forget it. It's certainly not possible with shell-cd-regexp, which is a bit of a hack. But in cmushell.el, authored by Olin Shivers, I find an intriguing alternative suggestion: ;;; The right way would be to hack the shell so that when it changes ;;; its pwd, for any reason, it notifies emacs via some ipc channel or ;;; something. This sounds like a very good idea. Has anyone actually implemented it? Are there any other pieces of the inferior shell's internal state, besides the current directory, that it would be desirable for Emacs to know about? Perhaps the IPC channel should really be two-way, so that the shell can respond to arbitrary queries about its current state. BASH developers, please note... -- Robert S. Maier | Internet: rsm@math.arizona.edu [128.196.128.99] Dept. of Math. | UUCP: ..{allegra,cmcl2,hao!noao}!arizona!amethyst!rsm Univ. of Arizona | Bitnet: maier@arizrvax Tucson, AZ 85721 | FAX: +1 602 621 8322 U.S.A. | Voice(POTS): +1 602 621 6893 / +1 602 621 2617
jr@bbn.com (John Robinson) (02/26/90)
In article <RSM.90Feb25184117@coral.math.arizona.edu>, rsm@math (Robert S. Maier) writes: >In article <wZtrldm00htFFhJS9X@cs.cmu.edu> Olin Shivers writes, >>It is not possible to reliably track the current working directory >>100% of the time. Forget it. > >It's certainly not possible with shell-cd-regexp, which is a bit of a >hack. But in cmushell.el, authored by Olin Shivers, I find an >intriguing alternative suggestion: > >;;; The right way would be to hack the shell so that when it changes >;;; its pwd, for any reason, it notifies emacs via some ipc channel or >;;; something. > >This sounds like a very good idea. Has anyone actually implemented >it? Well, you could take xterm's approach. Define a character sequence that has the effect of notifying the terminal emulator to change state. For xterm, this lets you put CWD in the title bar. Then, you can alias cd and friends to also spit out the magic sequence. Bash does this one better, because of PROMPT_COMMAND. Here's the bash definition I use: function xtitle () { if [ "$oldxtitle" != "$*" ] then oldxtitle="$*" echo -n "]0;$*" fi } PROMPT_COMMAND='xtitle "$HOST: $PWD"' bash executes prompt_command every time it's about to print the prompt. The echo -n inside there wraps the $HOST: $PWD inside the right character sequence to tell xterm to modify its title. In shell mode, a process-filter could pick off this (or a similar) sequence and update the shell's buffer's cwd. It's too late for me tonight, but if anyone writes this process filter please post or mail me - I'd use it! >Are there any other pieces of the inferior shell's internal state, >besides the current directory, that it would be desirable for Emacs to >know about? What host you're on, as in the above example. SubJobs might be another. >BASH developers, please note... ... maybe they already have :-) bash, by the way, works fine inside shell buffers (it respects the stty modes and doesn't start spewing needless ^M's and echos). But, given that it has to emulate /bin/sh, this is de rigeur. free of csh (and issue) at last! -- /jr, nee John Robinson Life did not take over the globe by combat, jr@bbn.com or bbn!jr but by networking -- Lynn Margulis