From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 07E733858D38 for ; Fri, 12 Apr 2024 17:31:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 07E733858D38 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 07E733858D38 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712943088; cv=none; b=IEhbijjUfHTg3OJpX1jg8801qjDCRfcBwMXqV5XhtGF/iqIRbAIxt4jOutGwpg/tLYNobmmCfEf0xPkPFETwea065iq9oRXqcRD+rK9pYoebL4oIkccVJ1Hi2BdOic5zsaQTea8eUqOsXMQpPo7Sf8PopHu1mnhZAVoIPgQZ7sg= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712943088; c=relaxed/simple; bh=WMT1b4WP7tflGky1dtwyiDWsxjRSzjm0kvgDFT59j1Q=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=o4IHm6Uw/EhpZm+yIRly4sPxOPaGY09STVYfMtmNmmpjIOKCHmRl18taRnJfLtZWRw48CbMTvIdn50AXhQEov0TYIN1HN+CxQykUcpOCHdehObvXGGdBeSGP5qoGTu6/0szPQvgy75q67TtmeduyOIJqhtkVOhII7PixVinjh2g= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1712943083; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=8jgIYGGjlbwkj1DasDu8Vmq8a4KgGXRTyMictPCspC4=; b=R/DCRhsHjisBoMk01jvsFewcRLRAJ3gTMZleeKWRNxoHi+QCIHxD2zBbqQHR79C7hMf/kv cKNWxf4RM8Bsozr+2rL/kxxXZqZD1KgfPLipaycRwET1R3USc+WpnE6ZSCjlir1Ft/GCyx zHlU+R6gqSGLtdTfU7Fdwc3TXuoo0IE= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-189-nVeynkcfPS2fJyx-yi-UAg-1; Fri, 12 Apr 2024 13:31:22 -0400 X-MC-Unique: nVeynkcfPS2fJyx-yi-UAg-1 Received: by mail-wr1-f70.google.com with SMTP id ffacd0b85a97d-3418f237c0bso798781f8f.3 for ; Fri, 12 Apr 2024 10:31:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712943080; x=1713547880; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=8kjCLfCY4OG96mkmGGRHmU+MFqqeKxTfUDsQZXQRuiI=; b=OnlTI6b9r7q+EQbjU7qUn3f2b+sx7J078b5XBzG6zU1TsTCdCLYm/9IDRlfV9+vskZ RjFRkEW9Y+C2CHyufK3r4Z7COA5o5IpmhpzWPGaYQ+e2R6bIxMqj/rXSLIwmEpAsrNHG 11VAi9nGg76J/ONOhgL43V4qEbBHwlK1yBE3f27JphY/5jbbklDOfFV98cLJxGtFm4Rl JGMvOCgUDAtxqFD0KhVKBxEn5RJ5sv/+77Y2w/6pYpOJJm2v79Ef8ALX5tQAZHObbbtP nf29b7EEOcAxdEOr3UFXTVturss8AB9SKLoVDhcUJnEQlgZkyQ6Nty78u2dK6SkVCyVR HnnQ== X-Gm-Message-State: AOJu0Yw9OHiYKN26gFBn2YajIJjVI5YS/ps5PCZjUFUi94yz/cPXF4nw HmE80GuPTbEmzHCGfGeV7b6uPuFqhVuQQJcYU8eH4w61m9e7yOKoe5TRRWlW376IPTR7zk/BYJT SNCZfQUnqzhRW7OvDlF3OOpS16gZW3oZ92KTBp+ddwBTk5zYMtAD6HDwGGT1jgKuqHqY= X-Received: by 2002:adf:e611:0:b0:33e:7133:ee31 with SMTP id p17-20020adfe611000000b0033e7133ee31mr1958227wrm.40.1712943080465; Fri, 12 Apr 2024 10:31:20 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHRNHMuxnaIhh1+/4HAPkdT4KylVb9yzpRsdWIjo2IoxlmJqzlAJlP3xrE0lGRf5zN4o1Ttzg== X-Received: by 2002:adf:e611:0:b0:33e:7133:ee31 with SMTP id p17-20020adfe611000000b0033e7133ee31mr1958221wrm.40.1712943079944; Fri, 12 Apr 2024 10:31:19 -0700 (PDT) Received: from localhost (185.223.159.143.dyn.plus.net. [143.159.223.185]) by smtp.gmail.com with ESMTPSA id f10-20020a056000128a00b003436a3cae6dsm4684299wrx.98.2024.04.12.10.31.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 12 Apr 2024 10:31:19 -0700 (PDT) From: Andrew Burgess To: Lancelot SIX , Eli Zaretskii Cc: gdb-patches@sourceware.org Subject: Re: [PATCH 2/6] gdb: move display of completion results into completion_result class In-Reply-To: <20240330233038.sol5j3cp7vsym4uz@octopus> References: <86v855dyls.fsf@gnu.org> <20240330233038.sol5j3cp7vsym4uz@octopus> Date: Fri, 12 Apr 2024 18:31:19 +0100 Message-ID: <87sezq4heg.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,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 List-Id: Lancelot SIX writes: > 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 >> >=20 >> > 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: >> >=20 >> > (gdb) complete file /tmp/aa >> > file /tmp/aa\"bb >>=20 >> 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=E2=80=99= 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. I wasn't aware of this difference. I would also rather just have consistent parsing. The 'set logging file' command gets away with this parsing because the filename is always the last thing on the command line, but for other commands this is not always the case. We could probably arrange a mostly backward compatible solution for this case. I'll see if I can spot any other problem cases. Thanks, Andrew