From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30099 invoked by alias); 23 Dec 2016 08:07:30 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 30088 invoked by uid 89); 23 Dec 2016 08:07:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.8 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=unix-like, Unixlike, unixlike, Unix-like X-HELO: eggs.gnu.org Received: from eggs.gnu.org (HELO eggs.gnu.org) (208.118.235.92) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 23 Dec 2016 08:07:19 +0000 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cKKsm-0003G5-37 for gdb-patches@sourceware.org; Fri, 23 Dec 2016 03:07:17 -0500 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:46366) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cKKsf-0003BG-2s; Fri, 23 Dec 2016 03:07:09 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1691 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cKKse-0005lK-8x; Fri, 23 Dec 2016 03:07:08 -0500 Date: Fri, 23 Dec 2016 08:07:00 -0000 Message-Id: <83y3z7ysq2.fsf@gnu.org> From: Eli Zaretskii To: Sergio Durigan Junior CC: gdb-patches@sourceware.org, palves@redhat.com In-reply-to: <1482464361-4068-7-git-send-email-sergiodj@redhat.com> (message from Sergio Durigan Junior on Thu, 22 Dec 2016 22:39:21 -0500) Subject: Re: [PATCH 6/6] Implement proper "startup-with-shell" support on gdbserver Reply-to: Eli Zaretskii References: <1482464361-4068-1-git-send-email-sergiodj@redhat.com> <1482464361-4068-7-git-send-email-sergiodj@redhat.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-IsSubscribed: yes X-SW-Source: 2016-12/txt/msg00397.txt.bz2 > From: Sergio Durigan Junior > Cc: palves@redhat.com, Sergio Durigan Junior > Date: Thu, 22 Dec 2016 22:39:21 -0500 > > gdb/doc/ChangeLog: > 2016-12-22 Sergio Durigan Junior > > * gdb.texinfo (startup-with-shell): Add note mentioning that the > setting is also used by remote targets. > (set remote startup-shell): New item. The text in parentheses should be the name of the node where you make the change. If you want to refer to specific symbols within the node, either mention them as part of the text or put them in <..>, like this: * gdb.texinfo (Starting) : Add note ... > diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo > index a0de7d1..3250cae 100644 > --- a/gdb/doc/gdb.texinfo > +++ b/gdb/doc/gdb.texinfo > @@ -2174,6 +2174,10 @@ initialization file---such as @file{.cshrc} for C-shell, > $@file{.zshenv} for the Z shell, or the file specified in the > @samp{BASH_ENV} environment variable for BASH. > > +This setting is also used by @code{target extended-remote} to > +determine whether the target system will start the inferior using the > +shell (@pxref{set remote startup-shell}). I would add here a qualification: only on Unix-like target systems. (Is it true that this is a necessary condition for the applicability of that feature?) > +@item set remote startup-shell @var{shell} > +@itemx show remote startup-shell > +@anchor{set remote startup-shell} > +@cindex startup shell, for remote target > +Set the shell that is going to be used to start the inferior with > +@code{target extended-remote}. This should be set to a valid shell on > +the target system, and is only effective when > +@code{startup-with-shell} is on. If it is not set, the target system > +will use the shell pointed by the @code{SHELL} environment variable. Three comments on this: . What is a "valid shell" in this context? Is the DOS command.com a valid shell, for example (probably not)? I think we should be more explicit about which shells are acceptable. . What exactly is the value supposed to be? Is it a full absolute file name of the shell executable? We should say so explicitly, IMO. . Does it really make sense to require that both this option and startup-with-shell be on? Why cannot the user set only this option to achieve that effect, with some special value standing for "use $SHELL"? Also, is it possible that a user will want remote targets to use a shell, while avoiding that for native debugging, in the same session? A minor nit: environment variables should have the @env markup, not @code. I think this warrants a NEWS entry. Thanks.