From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id gNhHBsGgCGZXwhwAWB0awg (envelope-from ) for ; Sat, 30 Mar 2024 19:31:13 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; secure) header.d=lancelotsix.com header.i=@lancelotsix.com header.a=rsa-sha256 header.s=2021 header.b=KGMLyugo; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 0862E1E0C0; Sat, 30 Mar 2024 19:31:13 -0400 (EDT) Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 5F7DB1E08C for ; Sat, 30 Mar 2024 19:31:10 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 8F5A73858C62 for ; Sat, 30 Mar 2024 23:31:09 +0000 (GMT) Received: from lndn.lancelotsix.com (lndn.lancelotsix.com [51.195.220.111]) by sourceware.org (Postfix) with ESMTPS id 77BCE3858D28 for ; Sat, 30 Mar 2024 23:30:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 77BCE3858D28 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=lancelotsix.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=lancelotsix.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 77BCE3858D28 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=51.195.220.111 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1711841449; cv=none; b=MVmaBHFSWVGW7Dw/NsFp0Q2TcC+hueDNa0DDsMkXByLmYMqE1zIa6Af/J3c7x8VehDwCE9KftH7da4lCsOVm0G1bT5uDCjhAKV6bgu84hLCDKDg3GmruIl28Nnavc2f4gbOUrhomaJvyx1vI+Q6YXOZt0KuB+Mhn6vk/C5pE0VM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1711841449; c=relaxed/simple; bh=QsH279Ly+TFuqlfjZXz2t+TL3GGv/oWo93KH4bzvBKk=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=gSHujHZ/dCeIj5KuZOuhm2xdZJZM0dgpAcfWHZoyV1qkDO7v84Eu/BAM/hSgYmap5xi2iOT6MhZrPTe3jkKNLpFbRwEUgRmmkv3h5ho6LFdCg1GLO8HgAScgzMiomY7gagYAHCK2DTG03yScpSJ65cnKA3DT8vpoco15qi5GwxQ= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from octopus (cust120-dsl54.idnet.net [212.69.54.120]) by lndn.lancelotsix.com (Postfix) with ESMTPSA id 3144E810A0; Sat, 30 Mar 2024 23:30:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lancelotsix.com; s=2021; t=1711841444; bh=QsH279Ly+TFuqlfjZXz2t+TL3GGv/oWo93KH4bzvBKk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=KGMLyugoCLw4JlenJWT8MDZKmE+1hfehsMT0M57rDkxwfg8a7VMIxL0piW//F6MRi Hq7MpguIWew6KH6oJo5Is8RC2XHcbmRp3Fp/UOGs7OL4TlxP9WMtAWwSONS/UDV7Yn KD4zin8CWY7ym4ltwNEgLymFXLYYXwTB5Dcn8GWr1HPS/xZ7BaNyvwS1pgQYaD/AsL RpI9t+9Xa8KxiS/iIa7+a/2AJ5dm7oSDHulfDGq7/sM1vK6tByUrcWvYPYTuV/6djW VLw8bll1542gaw+Q2bujHbVikfuDW0z5GEsSKmWUfE8gqaIrSf/8DAPdHBvqb7MtPE omeCqPfYBdRnA== Date: Sat, 30 Mar 2024 23:30:38 +0000 From: Lancelot SIX To: Eli Zaretskii Cc: Andrew Burgess , gdb-patches@sourceware.org Subject: Re: [PATCH 2/6] gdb: move display of completion results into completion_result class Message-ID: <20240330233038.sol5j3cp7vsym4uz@octopus> References: <86v855dyls.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <86v855dyls.fsf@gnu.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (lndn.lancelotsix.com [0.0.0.0]); Sat, 30 Mar 2024 23:30:44 +0000 (UTC) X-Spam-Status: No, score=-5.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces+public-inbox=simark.ca@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": $ 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) The problem Andrew is trying to solve is that the current completer for this command completes to something that is not a valid input. Moreover, the completer as it is currently is is not entirely functional for commands that expect "raw" filenames either. If you take the same directory structure, it can complete up to "test/aa bb", but can’t complete the directory: $ gdb -q (gdb) complete file test/aa file test/aa bb (gdb) complete file test/aa bb (gdb) complete file test/aa bb/ (gdb) Where I do agree with you is that GDB is inconsistent: some command expect "shell escaped filenames", and some do not. For example, "set logging file" will take its argument verbatim and use that: (gdb) set logging file "/tmp/test/aa bb/file.txt" (gdb) show logging file The current logfile is ""/tmp/test/aa bb/file.txt"". (gdb) set logging file /tmp/test/aa\ bb/file.txt (gdb) show logging file The current logfile is "/tmp/test/aa\ bb/file.txt". Part of the issue you are raising is that both commands use the same completer, so if the completer works for some commands, it will be wrong for the others. I have not reached the end of this series so I am not sure if this is addressed (I do not expect it is), but I guess we should either: 1) have 2 filename completers, and make sure that each function using a filename completer uses the appropriate one, or 2) have GDB be consistent regarding how commands consume filenames. I would prefer consistency, but implementing 2 would strictly speaking be an interface breaking change, so it needs careful consideration. My experience is that I tend to use "file" / "add-symbol-file" more than other commands dealing with filenames, so I would prefer to have a completer that works for those. Also, the current completer does not completely work for commands that consume "raw" filenames anyway, so having a completer that works properly for some commands rather than for none sounds appealing to me. That being said, this is just my 2 cent, I am looking forward to hearing other people’s thoughts on the subject. Best, Lancelot. > > So I'm not sure I understand what is being intended here, and I'm > afraid you will uncover a lot of problems as you go with this (as you > already discovered). > > Apologies if I'm missing something important here.