From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 91E1A3858D28 for ; Sun, 31 Mar 2024 05:49:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 91E1A3858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gnu.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gnu.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 91E1A3858D28 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2001:470:142:3::10 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1711864156; cv=none; b=F9Vkky7JRWMSKlDd+MK/6YVTSHCGYTMVd38AAfN2Z3rquQoKdhptuSMOoaAh/+iN1w9IrAZ3nDrHInvO4/6icKXMx22X5fyIByVLMW2oYRaAqcBpeQZXeFHkQHvGyDjpz9lvzGMKZjYSL498tN1UDL+jXws9/VPSsDQBd+kxdrI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1711864156; c=relaxed/simple; bh=bBz76D1NldOkbIus5gz3ipj7FFaQKqy0uaaf7j6vIi8=; h=DKIM-Signature:Date:Message-Id:From:To:Subject:MIME-version; b=EgdsJC7EKAje5OshD9/W/cPgKH+W+1U2xr+Ty/Yb3Gtx0Z1Hh9IaRrEioJncWeS0Hsz2J+uO/QG89wwf5HRDoGv/Xc9+zRFCk0xmNmyBs8iDa+/Dvy1gAxoiRvtyVdkwzoLHdZFuWLRhq7CkuzGHyWV6lJONuX4toyKKyZdGrZ4= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rqo49-0000fj-QB; Sun, 31 Mar 2024 01:49:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=GaI4ROcFyo65hwh3pZpdW6rAtKdWblONQsY3AKAdIa0=; b=NasSAbAEmBqgxqEM2NbO narT5mZckkqj5cJ6RqshQLQXr5kMN1NkBvmKOBmS2yCRqL956n3ZKUISLtB3cZoDRsfJfqzLnEePa 1qqEwOAIadEmEjoR4iB799ZjMp2fmUGKAVqNmJn7PYUuSVD4AthJxc8cERF4Jt7kRlWx/SXmKlD0R cn06U3BkqQHXEWplYHL7gpUhb4d+lFeZWIao0gCmDN4P006JmFDfd4h0eyr/qm4SmVqmLSgaEfERk D3mqqHeMGR6g4kUBTr7c/fVFn7UFydSZoMYGLI7lWkqMCz8hYa7C3f4YksiDd1P1+iQPfm79H4KTE a/0uAoYgJiv4dQ==; Date: Sun, 31 Mar 2024 08:49:11 +0300 Message-Id: <86v853ar3c.fsf@gnu.org> From: Eli Zaretskii To: Lancelot SIX Cc: aburgess@redhat.com, gdb-patches@sourceware.org In-Reply-To: <20240330233038.sol5j3cp7vsym4uz@octopus> (message from Lancelot SIX on Sat, 30 Mar 2024 23:30:38 +0000) Subject: Re: [PATCH 2/6] gdb: move display of completion results into completion_result class References: <86v855dyls.fsf@gnu.org> <20240330233038.sol5j3cp7vsym4uz@octopus> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.2 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_PASS,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: > Date: Sat, 30 Mar 2024 23:30:38 +0000 > From: Lancelot SIX > Cc: Andrew Burgess , gdb-patches@sourceware.org > > On Fri, Mar 29, 2024 at 03:14:07PM +0300, Eli Zaretskii wrote: > > > From: Andrew Burgess > > > Cc: Andrew Burgess > > > Date: Fri, 29 Mar 2024 11:42:28 +0000 > > > > > > When using the 'complete' command to complete file names we have some > > > problems. The suggested completion should include any required > > > escaping, so if there is a filename '/tmp/aa"bb' (without the single > > > quotes), then this should be displayed in the completion output like: > > > > > > (gdb) complete file /tmp/aa > > > file /tmp/aa\"bb > > > > Why should it be displayed with the backslash? And would the > > completed name, if passed to a command, also have the backslash added? > > If so, it could cause some commands to fail; basically, you are adding > > shell file-name semantics into commands that don't work via the shell. > > Hi, > > The "file" command currently expects "shell file-name semantics": For starters, this fact, if it is true, is not really documented. > $ gdb -q > (gdb) file test/aa bb/a.out > test/aa: No such file or directory. > (gdb) file "test/aa bb/a.out" > Reading symbols from test/aa bb/a.out... > (gdb) file test/aa\ bb/a.out > Load new symbol table from "test/aa bb/a.out"? (y or n) y > Reading symbols from test/aa bb/a.out... > (gdb) Next, if 'file' indeed expects shell file-name semantics, then the question is: which shell? Should the above behave differently on, for example, MS-Windows, since file-name quoting there works differently? For example, escaping whitespace with a backslash will not work on Windows. Also, Andrew used the 'file' command in his examples, but completion in GDB is used in many other commands, including those who don't necessarily expect/need shell file-name semantics. And last, but not least: the manual says about the 'complete' command: This is intended for use by GNU Emacs. So one other thing we should consider is how Emacs handles these cases and what it expects from GDB in response. > The problem Andrew is trying to solve is that the current completer for > this command completes to something that is not a valid input. My point is that we need to have a clear idea what is a "valid input" before we decide whether the current behavior is invalid, and if so, how to fix it. IOW, we should step back and discuss the valid behavior first. Andrew's patch series started from postulating a certain desired result without any such discussion, and I think we should discuss these aspects before we decide what is the desired result. > That being said, this is just my 2 cent, I am looking forward to > hearing other people’s thoughts on the subject. Same here. Thanks.