Re: print -D and ${(D)} quoting

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Oct 13, 10:04am, Peter Stephenson wrote:
}
} On Tue, 12 Oct 2010 18:56:49 -0700
} Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> 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?