X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-workers-bounces using -f Date: Sun, 3 Mar 2002 13:50:24 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: djgpp-workers AT delorie DOT com cc: Morten Welinder Subject: Re: bash seems a little confused In-Reply-To: <200203031058.g23Awqw03448@mother.ludd.luth.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Sun, 3 Mar 2002, Martin Str|mberg wrote: > > emacs a/b > > In emacs I press C-Z and get a bash shell (1): > > pwd > e:/hackery/bash_emacs_confusion > > ls > b > > So bash thinks it's in e:/hackery/bash_emacs_confusion but ls shows us > being in e:/hackery/bash_emacs_confusion/b! Sounds like Bash doesn't expect the application to chdir? Can you try something similar with another program, like `less', or even command.com? In that other application, change the directory, then exit, and see if Bash gets confused in the same way. Emacs chdirs to the directory of the file when you edit that file. This is a feature (it's a long story, but believe me Morten was right when he coded that ;-). So when you shell out, you should land in the directory of the file from whose buffer you shelled out. If Bash wants to return you to the directory where you started (I could understand why it wants to do that, since that's what you'd see on Unix), it should do that manually. In other words, no program should assume that child programs stay in the same directory where they were launched. > 1) Another mystification, sometimes the screen after shelling out has > white-grey background and black text - the emacs colours sticks. This > is not easily reproduced. This isn't a Bash issue, I think: it's Emacs that restores the screen when you shell out. Are you sure this happens when you shell out, not when you exit Emacs immediately after starting it? If the latter, it's a feature: an exit that is too close to start usually means Emacs crashed. So Emacs deliberately doesn't clear the screen in that case, to leave any important info about the crash on the display.