From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26376 invoked by alias); 9 Sep 2002 20:23:07 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 26341 invoked from network); 9 Sep 2002 20:23:06 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 9 Sep 2002 20:23:06 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17oVzq-0004KT-00; Mon, 09 Sep 2002 16:23:02 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17oV3q-00028f-00; Mon, 09 Sep 2002 16:23:06 -0400 Date: Mon, 09 Sep 2002 13:23:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: kraftche@cae.wisc.edu, gdb@sources.redhat.com Subject: Re: environment for 'shell' command Message-ID: <20020909202306.GA8157@nevyn.them.org> Mail-Followup-To: Andrew Cagney , kraftche@cae.wisc.edu, gdb@sources.redhat.com References: <3D359FDE.4453EA90@cae.wisc.edu> <3D7CEC52.3000504@ges.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D7CEC52.3000504@ges.redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-09/txt/msg00060.txt.bz2 On Mon, Sep 09, 2002 at 02:45:38PM -0400, Andrew Cagney wrote: > >Hi, > > > >I would like the ability to pass the file name and line number of the > >source corresponding to the selected stack frame to a program started > >via the 'shell' command. I could not find any way to do this in gdb. > >If there is a way to do this, please let me know (and disregard the rest > >of this message.) I decided to add this functionality but I am > >unfimiliar with the internal workings of gdb. The following is a > >description of what I did to implement this. I'd really appreciate any > >suggestions on better ways to implement this, error conditions I'm not > >handling, etc. > > Off hand I can think of two ways to handle this: > > -- extend what you've proposed by including commands to explicitly > manipulate the exported environment, vis: > (gdb) command-to-set-shell-env VARIABLE VALUE > (gdb) shell printenv VARIABLE > VARIABLE=VALUE > (gdb) > where VALUE is something that GDB could evaluate. Why not just use the inferior environment (set env, show env)? It's not always appropriate, but usually it would be... and it's much more natural, I think. Just a thought. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer