Re: [lmi] [lmi-commits] odd/fixups 880f1a7 4/4: Add a text file with some notes

[Vadim Zeitlin]

On Mon,  6 May 2019 19:06:59 -0400 (EDT) Greg Chicares <address@hidden> wrote:

GC> diff --git a/NOTES.txt b/NOTES.txt
GC> new file mode 100644
GC> index 0000000..d23563b
GC> --- /dev/null
GC> +++ b/NOTES.txt
GC> @@ -0,0 +1,61 @@
GC> +My email is down, but my correspondents are clever enough to look here.

 Not sure if they're smart enough to find the proper way to reply to you,
but hopefully this one will do, in one way (if your email works again) or
the other (if/when you look at the list archives).

GC> +  62473f9f 'cp' a directory's contents (only)
GC> +
GC> +The commit message explains this in detail. My question is whether
GC> +'/path/to/.' is preferable to '/path/to/*' as a general rule.
GC> +
GC> +  953b23ea (HEAD -> odd/fixups) cp slash dot, not slash asterisk
GC> +The typical advice online favors '/path/to/.'. If that's preferable
GC> +here, then it must be preferable everywhere. But this is a big scary
GC> +change, so I wanted to run some tests.
GC> +
GC> +In a directory with many files...
GC> +
GC> +/opt/lmi/src/lmi[0]$ls * |wc -l
GC> +804
GC> +
GC> +/opt/lmi/src/lmi[0]$for z in ./* ; do echo $z; done |wc -l
GC> +754
GC> +/opt/lmi/src/lmi[0]$for z in ./. ; do echo $z; done |wc -l
GC> +1
GC> +
GC> +/opt/lmi/src/lmi[0]$for z in ./. ; do echo $z; done
GC> +./.
GC> +
GC> +This leads me to doubt very much that 953b23ea was a good idea,
GC> +and therefore to think that an asterisk would be better in 62473f9f.

 In practice it really doesn't matter which punctuation mark we use here,
but I don't really understand what makes you think using the dot wasn't a
good idea? The behaviour of ls isn't really relevant here, only that of cp
and mv is and for them using "foo/." inhibits the heuristic which decides
to copy "foo" itself rather than its contents to the target if it already
exists.

 I.e. our problem is that the command "cp -a foo bar" behaves differently
depending on whether "bar" exists or not. And "cp -a foo/. bar" definitely
fixes this problem because it behaves in the same way independently of
whether "bar" exists or not, so what's not about it?

 Regards,
VZ