lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Greg Chicares
Subject: Re: [lmi] [lmi-commits] odd/fixups 880f1a7 4/4: Add a text file with some notes
Date: Mon, 6 May 2019 23:59:39 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1

On 2019-05-06 23:27, Vadim Zeitlin wrote:
> 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).

Yahoo is back up again, at least for the moment, so I'll try
replying here.

> 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,

That's like telling Bobby Fischer that it doesn't matter whether he
starts with P-K4 or some other move. There can only be One True Move
to begin a game.

> but I don't really understand what makes you think using the dot wasn't a
> good idea?

Obviously it's a good idea in Ilya's patch; the whole internet says
so, at least according to the way I searched.

But if '/.' is better than '/*', then it must always be better;
that's just axiomatic for me. And therefore '/.' should be used
everywhere '/*' is used today, throughout lmi.

Yet I found a testcase where '/.' seemed incorrect.

> 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.

But...I thought the shell handled all expansions.

Maybe what I'm missing is that
  /path/to/*
contains the wildcard '*', so the shell must expand it; but
  /path/to/.
contains no wildcard, so the shell doesn't expand it. Is that right?

So why doesn't
  for z in ./. ; do echo $z; done
display anything except the literal string "./."?

And when I try this:

/opt/lmi/src/lmi[0]$ls ./. |wc -l    
754
/opt/lmi/src/lmi[0]$ls ./* |wc -l 
804

the results differ. Why? After these repeated 'cp' problems, I'm
doubting my understanding of the basics.

>  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?

I want there to be One True Way, and I want to follow it in all cases.
If
  cp -a foo/. bar
is the One True Way, that's okay with me, as long as I write it that
way everywhere. Isn't it a corollary that
  mv foo/. bar
  ls foo/.
are orthodox, and that
  mv foo/* bar
  ls foo/*
are heretical? If so, then it is axiomatic that they must be changed,
everywhere. And if they must be changed, then they should be changed
now, while you and Ilya are testing everything comprehensively with
cygwin.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]