From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 93282 invoked by alias); 22 Sep 2017 18:00:56 -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 92161 invoked by uid 89); 22 Sep 2017 18:00:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-6.9 required=5.0 tests=BAYES_00,GIT_PATCH_1,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 22 Sep 2017 18:00:53 +0000 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9F8CB7F3F6; Fri, 22 Sep 2017 18:00:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 9F8CB7F3F6 Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=sergiodj@redhat.com Received: from localhost (unused-10-15-17-193.yyz.redhat.com [10.15.17.193]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7342F67CC8; Fri, 22 Sep 2017 18:00:52 +0000 (UTC) From: Sergio Durigan Junior To: Eli Zaretskii Cc: gdb-patches@sourceware.org, palves@redhat.com Subject: Re: [PATCH v3 4/5] Implement "set cwd" command on GDB References: <20170912042325.14927-1-sergiodj@redhat.com> <20170921225926.23132-1-sergiodj@redhat.com> <20170921225926.23132-5-sergiodj@redhat.com> <83poajcg9a.fsf@gnu.org> Date: Fri, 22 Sep 2017 18:00:00 -0000 In-Reply-To: <83poajcg9a.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 22 Sep 2017 11:02:57 +0300") Message-ID: <878th64nqk.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2017-09/txt/msg00686.txt.bz2 On Friday, September 22 2017, Eli Zaretskii wrote: >> +@kindex set cwd >> +@cindex change inferior's working directory >> +@item set cwd @r{[}@var{directory}@r{]} >> +Set the inferior's working directory to @var{directory}. If not >> +given, @var{directory} uses @file{'~'}. > > I think we should document here what does "~" mean on MS-Windows, > especially since, when HOME is not in the environment, Gnulib's glob > module doesn't behave according to MS platform recommendations (which > say not to create files directly below %HOMEDRIVE%%HOMEPATH%). Sure, but just to be clear, this text was strongly based on another part of the docs, which also mentions '~' without explaining further. As I am totally out of the loop when it comes to Windows environments, I'd appreciate a suggestion for the new text. > More generally, I think we should say here that the argument is > glob-expanded, because this is user-visible behavior (right?). Also, > how will TAB-completion react to input of this command? will it expand > the input typed so far? TAB-completion will not change anything; we don't have such a facility on GDB AFAIK. But it will complete the input. >> +@kindex show cwd >> +@cindex show inferior's working directory >> +@item show cwd >> +Show the inferior's working directory. If no directory has been >> +specified by @code{set cwd}, then the default inferior's working >> +directory is the same as @value{GDBN}'s working directory. > > Does this show the original value typed by the user, or the expanded > value? E.g., if the user types "set cwd ~/foo", what will "show cwd" > display? If it shows the unexpanded form, does that mean the actual > cwd will change if, say, HOME changes? Pedro and I had a conversation about this specific topic yesterday, and the decision was that the host should not do any path expansion on this case. Therefore, whatever the user sets with "set cwd" is not expanded until the inferior starts, which means that it is the target who performs the expansion. > Should we store the cwd after tilde-expansion? I don't think so. Or at least I cannot see a reason to do that. >> @@ -2461,6 +2462,7 @@ windows_create_inferior (struct target_ops *ops, const char *exec_file, >> BOOL ret; >> DWORD flags = 0; >> const char *inferior_io_terminal = get_inferior_io_terminal (); >> + const char *inferior_cwd = get_inferior_cwd (); >> >> if (!exec_file) >> error (_("No executable specified, use `target exec'.")); >> @@ -2488,8 +2490,15 @@ windows_create_inferior (struct target_ops *ops, const char *exec_file, >> error (_("Error starting executable: %d"), errno); >> cygallargs = (wchar_t *) alloca (len * sizeof (wchar_t)); >> mbstowcs (cygallargs, allargs, len); >> + >> + len = mbstowcs (NULL, inferior_cwd, 0) + 1; >> + if (len == (size_t) -1) >> + error (_("Invalid cwd for inferior: %d"), errno); >> + infcwd = (wchar_t *) alloca (len * sizeof (wchar_t)); >> + mbstowcs (infcwd, inferior_cwd, len); >> #else /* !__USEWIDE */ >> cygallargs = allargs; >> + infcwd = (cygwin_buf_t *) inferior_cwd; >> #endif >> } >> else >> @@ -2574,7 +2583,7 @@ windows_create_inferior (struct target_ops *ops, const char *exec_file, >> TRUE, /* inherit handles */ >> flags, /* start flags */ >> w32_env, /* environment */ >> - NULL, /* current directory */ >> + infcwd, /* current directory */ >> &si, >> &pi); >> if (w32_env) >> @@ -2697,7 +2706,7 @@ windows_create_inferior (struct target_ops *ops, const char *exec_file, >> TRUE, /* inherit handles */ >> flags, /* start flags */ >> w32env, /* environment */ >> - NULL, /* current directory */ >> + inferior_cwd, /* current directory */ >> &si, >> &pi); >> if (tty != INVALID_HANDLE_VALUE) > > This seems to pass the unexpanded cwd directly to CreateProcess. I > don't think this will work on Windows, as this directory is not > interpreted by any shell, so "~" will cause errors. I think we should > pass this via gdb_tilde_expand, like we do in the Unix case, and I > also think we should mirror all the slashes in the result, just in > case. Hm, you're right. I will call "gdb_tilde_expand" here. I'm not sure what you mean by "mirror all the slashes in the result". Do you mean "escape the slashes"? Thanks, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/