From: Phillip Wood Date: Fri, 02 Jun 2023 13:29:08 GMT Subject: Re: [PATCH v5 1/1] cat-file: quote-format name in error when using -z Message-ID: <5b83dba0-e900-ebae-2ad8-f036a40a15c5@gmail.com> In-Reply-To: Hi Junio Sorry for the slow reply, I had intended to reply before but got distracted and forgot about it. On 15/05/2023 18:20, Junio C Hamano wrote: > Phillip Wood writes: > >> On 12/05/2023 17:57, Junio C Hamano wrote: >>> Toon Claes writes: >>> Stepping back a bit, how big a problem is this in real life? It >>> certainly is possible to create a pathname with funny byte values in >>> it, and in some environments,letters like single-quote that are >>> considered cumbersome to handle by those who are used to CLI >>> programs may be commonplace. But a path with newline? Or any >>> control character for that matter? And this is not even the primary >>> output from the program but is an error message for consumption by >>> humans, no? >>> I am wondering if it is simpler to just declare that the paths >>> output in error messages have certain bytes, probably all control >>> characters other than HT, replaced with a dot, and tell the users >>> not to rely on the pathnames being intact if they contain funny >>> bytes in them. >> >> We could only c-quote the name when it contains a control character >> other that HT. That way names containing double quotes and backslashes >> are unchanged but it will still be possible to parse the path from the >> error message. If we're going to munge the name we might as well use >> our standard quoting rather than some ad-hoc scheme. > > In the above suggestion, I gave up and no longer aim to do > "quoting". A more appropriate word for the approach is "redacting". > The message essentially is: If you use truly problematic bytes in > your path, they are redacted (so do not use them if it hurts). > > This is because I am not sure how "names containing dq and bs are > unchanged" can be done without ambiguity. D'oh, I should have thought of that. You're right it ends up being ambiguous. Anyway Patrick has just posted a patch to add NUL terminated output which looks like a cleaner approach. Best Wishes Phillip > If I see a message that > comes out of this: > > printf("%s missing\n", obj_name); > > and it looks like > > "a\nb" missing > > how do I tell if it is complaining about the object the user named > with a three-byte string (i.e. lowercase-A, newline, lowercase-B), > or a six-byte string (i.e. dq, lowercase-A, bs, lowercase-N, > lowercase-B, dq)? > > If we were forbidding '"' to appear in a refname, then we could take > advantage of the fact that the name of an object inside a tree at a > funny path would not start with '"', to disambiguate. For the > three- and six-byte string cases above, the formatting function will > give these messages (referred to as "sample output" below): > > "master:a\nb" missing > master:"a\nb" missing > > because of your "we do not exactly do our standard c-quote; we > exempt dq and bs from the bytes to be quoted" rule. > > But it still feels a bit misleading. This codepath may have the > whole objectname as a single string so that c-quoting the entire > " " inside a single c-quoted string that > begins with a dq is easy, but not all codepaths are lucky and some > may have to show and separately, concatenated with > at the outermost output layer, which means that the second > one from the sample output may still mean the path with three-byte > name in the tree of 'master' commit. > > And worse yet, because > > git branch '"master' > > is possible (even though nobody sane would do that), so "treat the > string as c-quoted only if the object name as a whole begins with a > dq", this disambiguation idea would not work. The first one from > the sample output could be the blob at the path with a five-byte > string name (i.e. lowercase-A, bs, lowercase-N, lowercase-B, dq) > in the tree of the commit at the tip of branch with seven-byte > string name (i.e. dq followed by 'master'). > > So, I dunno.