From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8467 invoked by alias); 13 Oct 2010 16:15:05 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 28348 Received: (qmail 20103 invoked from network); 13 Oct 2010 16:15:01 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 Received-SPF: none (ns1.primenet.com.au: domain at closedmail.com does not designate permitted sender hosts) From: Bart Schaefer Message-id: <101013091442.ZM25227@torch.brasslantern.com> Date: Wed, 13 Oct 2010 09:14:42 -0700 In-reply-to: <20101013100435.4d3ae3f7@pwslap01u.europe.root.pri> Comments: In reply to Peter Stephenson "Re: print -D and ${(D)} quoting" (Oct 13, 10:04am) References: <4637.1286902367@csr.com> <20101012215339.26037042@pws-pc> <101012185649.ZM20220@torch.brasslantern.com> <20101013100435.4d3ae3f7@pwslap01u.europe.root.pri> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: print -D and ${(D)} quoting MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Oct 13, 10:04am, Peter Stephenson wrote: } } On Tue, 12 Oct 2010 18:56:49 -0700 } Bart Schaefer wrote: } > Is quoting the rest of the string really the correct thing to do? } } My contention is that a string of the form "~/with space" is neither } nowt nor something. As that stands, I agree (though I'm not sure whether you intend to include the quote marks as part of the form). However, what we have is not simply a string. It's the value of a parameter, and therefore subject to all the rules for when (not) to split it or expand it. BTW my intention here is not to insist the patch is wrong, merely to understand why it expresses the preferred semantics. } > Consider ${${(D)foo}:r} or ${=${(D)foo}}. } } ${(D)${foo:r}} is the right way round, since the initial $foo is (by } hypothesis) a path understood by the OS, while ${(D)foo} isn't Neither (D) nor :r truly care whether the value they're operating upon is a path understood by the OS, but in that sense arguably (D) is more rather than less dependent on path semantics than :r. } even without the quoting. But why are you doing file operations on a } parameter and then turning it into something that's no longer a file Maybe my problem is that I can't conceive of (D) as a file operation. As far as I can tell as soon as you use (D) the result has been turned into something that's no longer a file, and therefore it shouldn't be treated specially. Skipping ahead for an interlude: } Under what circumstances do you think it's useful to have a tilde } expression that's not usable as a shell command line argument, anyway? What does "usable as a shell command line argument" mean here? Why convert something into a contraction and then back again if you're operating entirely within a shell program? } Surely this can only be cosmetic, in which case having to add (Q) if } you really want a string purely for display is perfectly reasonable? The ONLY reason I understand for using (D) is for human consumption, e.g., for display, so from my point of view (Q) is never not required. Unless you're positing a case like somevar="/some/path/or/other/with spaces" hash -d foo=/some/path/or/other x=${(D)somevar} hash -d foo=/a/different/path/now blather $~x I guess that's sort of what dynamic directory naming accomplishes, so maybe that's not as farfetched as I first thought. However, even in that case having backslashes in the value of $x is not the right thing, is it? With your proposed change the argument passed to blather is going to include the literal backslash before the space, because of the parameter rules. Unless I misunderstand something, that last line would still have to be one of blather ${(Q)~x} or eval blather $x instead? If that's the usage for which you want to optimize, that's OK, I'm just wondering why; dynamic directory naming may be the answer. That's something I never use, so ... } (or, perhaps better put given what :r is typically used for, that } doesn't allow you to construct a file name you can use in a shell } expression)? I was thinking of the case where the expansion of ~name itself has a file extension. In that case ${(D)${foo:r}} and ${${(D)foo}:r} may be quite different when [[ "$foo" == "$(echo -n ~name)" ]]. } I don't know what ${=${(D)foo}} is supposed to be useful for. I was only demonstrating that if you split up the result of (D) when quoted as you propose, you get backslashes in potentially unexpected places. } Yes. With dynamic directory naming you can have } ~[complexexpression]/stuff. It's valid to have a "/" in the complex } expression. It's not a simple obvious operation to get a correctly } formatted string even without that. So your patch ends up quoting everything after the [complexexpression], but not quoting ~[complexexpression] itself. Becaue you then need to do some programmatic operations on the value that don't involve simple $~x replacement?