GNU cp question: star or no star?

[Kenny McCormack]

I frequently use "cp" under Linux to copy directory trees - usually from
hard disk to SD card or vice versa. My usual method is to cd to the target
directory (usually /mnt/test or something similar) and use "-avx" as the
command line options. So, to copy the root of the current running system to
the SD card, it would be like this:

# mount /dev/sdb2 /mnt/test
# cd /mnt/test
# cp -avx / .

This works fine. The point is that you need the "-x" to prevent it from
copying mounted filesystems (including the target itself) and also to
prevent it from copying stuff in, e.g., /proc.

Now, suppose you want to do the same thing but only copy from
/foo/bar/whatever to the SD card. So, you do:

# mount /dev/sdb1 /mnt/test
# cd /mnt/test
# cp -avx /foo/bar/whatever .

This doesn't work. Instead of copying all the files and directories from
the "whatever" directory to the root of the SD card, it instead creates a
directory called "whatever" (in the root of the SD card) and copies
everything under that. Which, of curse, is not what you want. However,
the following works:

# mount /dev/sdb1 /mnt/test
# cd /mnt/test
# cp -avx /foo/bar/whatever/* .

Now, everything ends up in the root of the SD card, as is required.

So, you say, OK, just live with it - always use the "*" form. But, alas,
the following (variation on the first example) misbehaves:

# mount /dev/sdb2 /mnt/test
# cd /mnt/test
# cp -avx /* .

Now, you end up with stuff in /proc on the target, which is not what you want.

So, is there any consistently correct and logical way to do this (that
works correctly in all cases)?

Please don't suggest other tools (i.e., other than "cp").

Also don't bother noting that at least some of these problems would go away
if I weren't copying from a live system. It can't be helped...

--
I'm building a wall.

[Rich]

In comp.os.linux.misc Kenny McCormack <gaz...@shell.xmission.com> wrote:
> So, you say, OK, just live with it - always use the "*" form. But, alas,
> the following (variation on the first example) misbehaves:

> # mount /dev/sdb2 /mnt/test
> # cd /mnt/test
> # cp -avx /* .

> Now, you end up with stuff in /proc on the target, which is not what you want.

> So, is there any consistently correct and logical way to do this (that
> works correctly in all cases)?

What happens if you reverse your positions and perform the copy while
sitting in the source directory?:

mount /dev/sdb2 /mnt/test
cd /
cp -avx . /mnt/test/

> Please don't suggest other tools (i.e., other than "cp").

Is there a reason why you have this restriction. Rsync's 'dir' vs
'dir/' syntax might just do exactly what you want in this situation.

[Kaz Kylheku]

On 2016-06-09, Kenny McCormack <gaz...@shell.xmission.com> wrote:
> Now, suppose you want to do the same thing but only copy from
> /foo/bar/whatever to the SD card. So, you do:
>
> # mount /dev/sdb1 /mnt/test
> # cd /mnt/test
> # cp -avx /foo/bar/whatever .
>
> This doesn't work. Instead of copying all the files and directories from
> the "whatever" directory to the root of the SD card, it instead creates a
> directory called "whatever" (in the root of the SD card) and copies
> everything under that. Which, of curse, is not what you want. However,
> the following works:
>
> # mount /dev/sdb1 /mnt/test
> # cd /mnt/test
> # cp -avx /foo/bar/whatever/* .

No, no, no!

cp -avx /foo/bar/whatever/. .
^^ key detail here!

We are copying "that dot" to "this dot".

Logically, what's happening is consistent with the behavior that
"cp A/B C" means "copy B under existing C as a child element".
I.e. identify "A/B" with "C/B". But if B is the dot, then this just
reduces to identifying "A/." with "C/.". And, of course,
"C/." is of course just "C"! THus "A/B" is identified with "C",
and there you go.

Some GNU Coreutils maintainer once upon a time didn't know about this
dot trick, and added the laughably superfluous -T/--no-target-directory
option to do the same thing:

cp -Tavx /foo/bar/whatever .

[Rainer Weikusat]

gaz...@shell.xmission.com (Kenny McCormack) writes:
> I frequently use "cp" under Linux to copy directory trees - usually from
> hard disk to SD card or vice versa. My usual method is to cd to the target
> directory (usually /mnt/test or something similar) and use "-avx" as the
> command line options.

[...]

> # mount /dev/sdb2 /mnt/test
> # cd /mnt/test
> # cp -avx / .

[...]

> Now, suppose you want to do the same thing but only copy from
> /foo/bar/whatever to the SD card. So, you do:
>
> # mount /dev/sdb1 /mnt/test
> # cd /mnt/test
> # cp -avx /foo/bar/whatever .
>
> This doesn't work. Instead of copying all the files and directories from
> the "whatever" directory to the root of the SD card, it instead creates a
> directory called "whatever" (in the root of the SD card) and copies
> everything under that.

Behold the wonders of deduction!

cp -avx /foo/bar/whatever/. .

does what you likely want.

[William Unruh]

On 2016-06-09, Kenny McCormack <gaz...@shell.xmission.com> wrote:

You see someone trying to nail in nails with a screwdrive, complaining
about how poorly that works. He asks for help but says the only help he
wants is how to use the screwdriver for that task-- hammers are out.

So I will just mention "rsync"
* has two problems. One is that it lists all of the files or
directories. Remember cp never sees the *. It is bash that expands the
* to the list of files. Thus it will list /proc and your command says
to copy everything in /proc on the same filesystem as /proc to thenew
place.

In rsync,
rsync -avx A B
would copy A and all its contents to B (so you would have B/A)
while
rsync -avx A/ B
would only copy the contents of A to B.

But you do not want to use rsync, so I guess I cannot help you.


>

[Kenny McCormack]

In article <njcd3l$828$1...@dont-email.me>, Rich <ri...@example.invalid> wrote:
>In comp.os.linux.misc Kenny McCormack <gaz...@shell.xmission.com> wrote:
>> So, you say, OK, just live with it - always use the "*" form. But, alas,
>> the following (variation on the first example) misbehaves:
>
>> # mount /dev/sdb2 /mnt/test
>> # cd /mnt/test
>> # cp -avx /* .
>
>> Now, you end up with stuff in /proc on the target, which is not what you want.
>
>> So, is there any consistently correct and logical way to do this (that
>> works correctly in all cases)?
>
>What happens if you reverse your positions and perform the copy while
>sitting in the source directory?:
>
> mount /dev/sdb2 /mnt/test
> cd /
> cp -avx . /mnt/test/

I could try that - but it seems like Kaz has already answered my question.
For whatever reasons, the "copy from there to here" method seems more
logical to me.

>> Please don't suggest other tools (i.e., other than "cp").
>
>Is there a reason why you have this restriction. Rsync's 'dir' vs
>'dir/' syntax might just do exactly what you want in this situation.

I know that newsgroup types think that rsync is the cat's pajamas, but I
don't like it. It's way too complicated. Don't get me wrong, I've taught
myself rsync on a few occasions, and it has worked, but it didn't "stick"
(which is why I had to re-teach it the next time I needed it). For me, it
just doesn't pass the "good enough to justify the complexity" sniff test.

In this case, it seems like it suffers the same basic problem though as
does "cp". That is, funny ambiguity about whether or not to create a
target directory.

In any case, rsync is a non-starter for me.

--
The randomly generated signature file that would have appeared here is more than 4
lines in length. As such, it violates one or more Usenet RFPs. In order to remain in
compliance with said RFPs, the actual sig can be found at the following web address:
http://www.xmission.com/~gazelle/Sigs/WeekendAwayFromHome

[Kenny McCormack]

In article <201606091...@kylheku.com>,
Kaz Kylheku <545-06...@kylheku.com> wrote:
...
>Try this:
>
> cp -avx /foo/bar/whatever/. .

>
>We are copying "that dot" to "this dot".

That looks right. Next time I need to do this, I'll give that a try.

Note, BTW, that although I've never tried "/foo/bar/whatever/.", I have
tried it like this: /foo/bar/whatever/
This has led to inconsistent results.

...

>Some GNU Coreutils maintainer once upon a time didn't know about this
>dot trick, and added the laughably superfluous -T/--no-target-directory
>option to do the same thing:
>
> cp -Tavx /foo/bar/whatever .
>

That looks like it should work as well.
Next time I need to do this, I'll give that a try.

--
Rich people pay Fox people to convince middle class people to blame poor people.

(John Fugelsang)

[Rainer Weikusat]

gaz...@shell.xmission.com (Kenny McCormack) writes:
> In article <201606091...@kylheku.com>,
> Kaz Kylheku <545-06...@kylheku.com> wrote:
> ...
>>Try this:
>>
>> cp -avx /foo/bar/whatever/. .
>>
>>We are copying "that dot" to "this dot".
>
> That looks right. Next time I need to do this, I'll give that a try.

If using cp in this way causes it to create the final directory of the
source path at the destination and copy the tree to the created
directory, referring to the top-level source directory such that the
final component will end up being the intended target directory instead
of a subdirectory of that would seem to be a pretty obvious idea ...

[Kenny McCormack]

In article <87shwmq...@doppelsaurus.mobileactivedefense.com>,

61 word sentence. I'm impressed.

--
Shikata ga nai...

[Robert Heller]

Right. The main issue with '*' (in fact fill all **SHELL** wildcard
characters) is that it is a **SHELL** wildcard. The OP is not experiencing a
problem with cp, he is simply not even remotely understanding how the shell
works. Rule of thumb: whenever you want to copy/access/delete/whatever a
directory of files, DO NOT USE shell wildcards. *EVEN IF YOU WANT TO COPY/ETC.
ALL OF THE FILES IN A DIRECTORY. ALLWAYS USE THE NAME OF THE DIRECTORY ITSELF.
IF YOU DON'T WANT THE DIRECTORY ITSELF INVOLVED, YOU CAN USE THE DIRECTORY'S
ALIAS ".".* Whenever you use a shell wildcard you will often get 'unintended'
results. This is always because of how shell wildcard expansion is performed.
Shell wildcard expansion is very powerfull -- be careful you don't shot
yourself in the foot.

*Some* commands should almost *never* be used with shell wildcards: typically
almost all archiving commands (eg tar, zip, rzync, cpio, etc.), and ANY
command that is going to do a 'readdir()' system call -- this would be any
file utility taking a '-r' option. Using shell wildcards with many base file
utilities (cp, mv, ls, rm, etc.) will often have unexpected results, unless
you really understand how the shell expands wildcards. Next rule of thumb:
readdir() trumps shell wildcards. Commands that use readdir():

tar, zip, etc.
rsync
find
any file util with the -r or -R option
ls

Using a shell wildcard AND readdir() can be redundent and is *additive*.

(Yes, sometimes that is really what you want, but you need to understand what
is going on or you will get unexpected results.)

>
> In rsync,
> rsync -avx A B
> would copy A and all its contents to B (so you would have B/A)
> while
> rsync -avx A/ B
> would only copy the contents of A to B.
>
> But you do not want to use rsync, so I guess I cannot help you.
>
>
> >
>

--
Robert Heller -- 978-544-6933
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
hel...@deepsoft.com -- Webhosting Services

[Kaz Kylheku]

["Followup-To:" header set to comp.unix.programmer.]

On 2016-06-09, Kenny McCormack <gaz...@shell.xmission.com> wrote:

> In article <201606091...@kylheku.com>,
> Kaz Kylheku <545-06...@kylheku.com> wrote:
> ...
>>Try this:
>>
>> cp -avx /foo/bar/whatever/. .
>>
>>We are copying "that dot" to "this dot".
>
> That looks right. Next time I need to do this, I'll give that a try.
>
> Note, BTW, that although I've never tried "/foo/bar/whatever/.", I have
> tried it like this: /foo/bar/whatever/
> This has led to inconsistent results.

This is not much different from /foo/bar/whatever except that there is
the additional constraint that /foo/bar/whatever/ must refer to
a directory. If you do "cp /foo/bar/file.c/ ..." and file.c
is just a file, it will refuse. (Perhaps depending on the OS!
The Linux kernel rejects trailing slash syntax that doesn't
refer to a directory, but that might historically not be the case in
every Unix-like OS).

We really need that dot to say that we are copying that dot object.
The basename is then ".", which makes the difference.

>>Some GNU Coreutils maintainer once upon a time didn't know about this
>>dot trick, and added the laughably superfluous -T/--no-target-directory
>>option to do the same thing:
>>
>> cp -Tavx /foo/bar/whatever .
>>
>
> That looks like it should work as well.
> Next time I need to do this, I'll give that a try.

I asked on Unix stackexchange what -T is good for. Basically there is
one thing you can't do without it: copy a file while renaming it, such
that if a directory of the target name exists, there will be an error.

mkdir -p /path/to/should-be-file-but-isnt

# error: "cannot overwrite directory ... with non-directory"
cp -T /path/to/file /path/to/should-be-file-but-isnt

Without the -T, file is copied as a child of the unexpected directory.

But if we aren't renaming file, the dot trick serves us just fine:

cp /path/a/file /path/b/.

If /path/b/file exists as a directory, the same error is produced:
cannot overwrite ... directory with non-directory.

So that's what T is good for; an extra error check and defense against
wrong behavior when renaming a file or copying to a different name.

[Kaz Kylheku]

On 2016-06-09, Kenny McCormack <gaz...@shell.xmission.com> wrote:

You haven't read "supercat" in comp.std.c.

[Kenny McCormack]

In article <201606091...@kylheku.com>,
Kaz Kylheku <545-06...@kylheku.com> wrote:
...

>> 61 word sentence. I'm impressed.
>
>You haven't read "supercat" in comp.std.c.

Not for lack of trying.

I know of whom you speak, and I've seen his stuff [*], but I confess it makes
my eyes glaze over. Life is too short, and all that...

[*] And I think I basically agree with it (i.e., with what supercat
writes), because it tends to be against the CLC culture (anything that
makes Kiki mad is probably a good thing).

[William Unruh]

On 2016-06-09, Kenny McCormack <gaz...@shell.xmission.com> wrote:

> In article <njcd3l$828$1...@dont-email.me>, Rich <ri...@example.invalid> wrote:
>>In comp.os.linux.misc Kenny McCormack <gaz...@shell.xmission.com> wrote:

...

>
> I know that newsgroup types think that rsync is the cat's pajamas, but I
> don't like it. It's way too complicated. Don't get me wrong, I've taught
> myself rsync on a few occasions, and it has worked, but it didn't "stick"
> (which is why I had to re-teach it the next time I needed it). For me, it
> just doesn't pass the "good enough to justify the complexity" sniff test.

It does more than cp. a) it does not copy over the file if it already
exists and is identical. b) It does a hash to make sure that the copy is
bit for bit the same as the original. Both are really valuable.

>
> In this case, it seems like it suffers the same basic problem though as
> does "cp". That is, funny ambiguity about whether or not to create a
> target directory.

There is absolutely no ambiguity with rsync. If the directory source
name ends in /, copy the contents, if it does not end with / copy the
directory and the contents.

>
> In any case, rsync is a non-starter for me.

I hate hammers. If I need to pound in a nail I will either use a screwdriver or
a rock.


>

[Rich]

In comp.os.linux.misc William Unruh <un...@invalid.ca> wrote:
> On 2016-06-09, Kenny McCormack <gaz...@shell.xmission.com> wrote:
> > In article <njcd3l$828$1...@dont-email.me>, Rich <ri...@example.invalid> wrote:
> > >In comp.os.linux.misc Kenny McCormack <gaz...@shell.xmission.com> wrote:
> ...
> >
> > I know that newsgroup types think that rsync is the cat's pajamas,
> > but I don't like it. It's way too complicated. Don't get me
> > wrong, I've taught myself rsync on a few occasions, and it has
> > worked, but it didn't "stick" (which is why I had to re-teach it
> > the next time I needed it). For me, it just doesn't pass the "good
> > enough to justify the complexity" sniff test.

> It does more than cp. a) it does not copy over the file if it already
> exists and is identical. b) It does a hash to make sure that the copy
> is bit for bit the same as the original. Both are really valuable.

c) It (rsync) also copies over a network just as easily as within a
local system.

Is rsync complicated - yes.

Do you (Kenny have to learn all of rsync's complications to effectively
use it - most definetly no.

You (as in Kenny) can get by using rsync as a "cp" replacement for the
most part by knowing only the -a and -v options, and the distinction
between "dir" and "dir/" (which this distinction was explained in the
article that this one is a reply to).

> > In any case, rsync is a non-starter for me.
> I hate hammers. If I need to pound in a nail I will either use a
> screwdriver or a rock.

Agreed.

[Kenny McCormack]

In article <njct4r$311$1...@dont-email.me>, Rich <ri...@example.invalid> wrote:
...

>> I hate hammers. If I need to pound in a nail I will either use a
>> screwdriver or a rock.

You guys are like Bernie Sanders.

You've lost. The ship has sailed. Give it up.

--
Christianity is not a religion.

- Rick C Hodgin -

[William Unruh]

On 2016-06-09, Kenny McCormack <gaz...@shell.xmission.com> wrote:

> In article <njct4r$311$1...@dont-email.me>, Rich <ri...@example.invalid> wrote:
> ...
>>> I hate hammers. If I need to pound in a nail I will either use a
>>> screwdriver or a rock.
>
> You guys are like Bernie Sanders.
>
> You've lost. The ship has sailed. Give it up.

Lost? Lost what? Did you think our trying to help you was a competition?
>

[Barry Margolin]

In article <njcs82$f1$1...@dont-email.me>,

William Unruh <un...@invalid.ca> wrote:

> On 2016-06-09, Kenny McCormack <gaz...@shell.xmission.com> wrote:
> > In article <njcd3l$828$1...@dont-email.me>, Rich <ri...@example.invalid>
> > wrote:
> >>In comp.os.linux.misc Kenny McCormack <gaz...@shell.xmission.com> wrote:
> ...
> >
> > I know that newsgroup types think that rsync is the cat's pajamas, but I
> > don't like it. It's way too complicated. Don't get me wrong, I've taught
> > myself rsync on a few occasions, and it has worked, but it didn't "stick"
> > (which is why I had to re-teach it the next time I needed it). For me, it
> > just doesn't pass the "good enough to justify the complexity" sniff test.
>
> It does more than cp. a) it does not copy over the file if it already
> exists and is identical. b) It does a hash to make sure that the copy is
> bit for bit the same as the original. Both are really valuable.
>
> >
> > In this case, it seems like it suffers the same basic problem though as
> > does "cp". That is, funny ambiguity about whether or not to create a
> > target directory.
>
> There is absolutely no ambiguity with rsync. If the directory source
> name ends in /, copy the contents, if it does not end with / copy the
> directory and the contents.

But you have to be consistent about it when specifying the source and
destination. I think that's where it gets confusing.

I like rsync, and use it frequently, but I still sometimes get this
wrong and end up with a subdirectory when I didn't want it.

--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

[Rich]

Actually, what it takes is finally internalizing that rsync considers a
trailing slash on the source directory to be meaningful. [1] That took
me a while to "internalize" before I finally "got it". Once you've
"got" that part, then rsync is 100% deterministic in this aspect.

Give rsync a source of: foo/bar

It will end up creating a new "bar" at the destination, and everything
transfered will be inside the new "bar".

Give rsync a source of: foo/bar/

No "bar" will be created at the destination, what gets transfered is
instead just the contents of the source foo/bar, and those contents
will be literally dropped into where-ever the destination is pointing
at.



[1] this is different from almost every other CLI tool where for the
most part foo/bar and foo/bar/ are treated as identical, or at most
treated as requiring that "bar" actually be a directory.

[William Unruh]

On 2016-06-10, Barry Margolin <bar...@alum.mit.edu> wrote:
> In article <njcs82$f1$1...@dont-email.me>,
> William Unruh <un...@invalid.ca> wrote:
>
>> On 2016-06-09, Kenny McCormack <gaz...@shell.xmission.com> wrote:
>> > In article <njcd3l$828$1...@dont-email.me>, Rich <ri...@example.invalid>
>> > wrote:
>> >>In comp.os.linux.misc Kenny McCormack <gaz...@shell.xmission.com> wrote:
>> ...
>> >
>> > I know that newsgroup types think that rsync is the cat's pajamas, but I
>> > don't like it. It's way too complicated. Don't get me wrong, I've taught
>> > myself rsync on a few occasions, and it has worked, but it didn't "stick"
>> > (which is why I had to re-teach it the next time I needed it). For me, it
>> > just doesn't pass the "good enough to justify the complexity" sniff test.
>>
>> It does more than cp. a) it does not copy over the file if it already
>> exists and is identical. b) It does a hash to make sure that the copy is
>> bit for bit the same as the original. Both are really valuable.
>>
>> >
>> > In this case, it seems like it suffers the same basic problem though as
>> > does "cp". That is, funny ambiguity about whether or not to create a
>> > target directory.
>>
>> There is absolutely no ambiguity with rsync. If the directory source
>> name ends in /, copy the contents, if it does not end with / copy the
>> directory and the contents.
>
> But you have to be consistent about it when specifying the source and
> destination. I think that's where it gets confusing.

The rule is consistant and well defined. Your (and my) memory of the
rule may be inconsistant.

>
> I like rsync, and use it frequently, but I still sometimes get this
> wrong and end up with a subdirectory when I didn't want it.

Yes, forgetting about the / is an easy mistake to make.

>

[Barry Margolin]

In article <njdae6$47h$1...@dont-email.me>, Rich <ri...@example.invalid>
wrote:

So there's no difference between

rsync src/foo/ dest/foo

and

rsync src/foo/ dest/foo/

?

[Bit Twister]

On Fri, 10 Jun 2016 01:17:45 -0400, Barry Margolin wrote:
>
> So there's no difference between
>
> rsync src/foo/ dest/foo
>
> and
>
> rsync src/foo/ dest/foo/
>
> ?

As for directory contents, no.
As to actual destination directory path, yes.

dest/foo will have dest/foo :)
dest/foo/ will have dest/foo/foo :(

[Anssi Saari]

gaz...@shell.xmission.com (Kenny McCormack) writes:

> I know that newsgroup types think that rsync is the cat's pajamas, but I
> don't like it. It's way too complicated.

I agree although I've gotten used to it in the last few years at least
enough that if I try to sync /foo/whatever with /bar/whatever I don't
usually end up with /foo/bar/whatever any more.

OTOH, there's unison which uses rsync but has a UI, text or gui, and
tells you what files have changed and which way it thinks they should be
synced. I used it to sync a directory tree between two computers in
different networks via an external drive some time ago and it worked
great.

[Robert Heller]

Yes, for the *destination* side it makes no difference (whether the trailing
slash is present or not). *Only* the source side treats the trailing slash (/)
as a 'special' case.

> ?

[Barry Margolin]

In article <slrnnlklmm.o...@wb.home.test>,

Bit Twister <BitTw...@mouse-potato.com> wrote:

> On Fri, 10 Jun 2016 01:17:45 -0400, Barry Margolin wrote:
> >
> > So there's no difference between
> >
> > rsync src/foo/ dest/foo
> >
> > and
> >
> > rsync src/foo/ dest/foo/
> >
> > ?
>
> As for directory contents, no.
> As to actual destination directory path, yes.

Which is the whole point of the confusion. You have to remember whether
to put the trailing slash on the source or the destination.

>
> dest/foo will have dest/foo :)
> dest/foo/ will have dest/foo/foo :(

[Rich]

Did you test it before posting?:

Test with "dest/foo":

/tmp/rsync-test$ tree -anF
.
|-- dest/
`-- source/
`-- foo/
`-- bar/
|-- 123
`-- xyz

4 directories, 2 files
/tmp/rsync-test$ rsync -av source/foo/bar dest/foo
sending incremental file list
created directory dest/foo
bar/
bar/123
bar/xyz

sent 186 bytes received 89 bytes 550.00 bytes/sec
total size is 0 speedup is 0.00
/tmp/rsync-test$ tree -anF
.
|-- dest/
| `-- foo/
| `-- bar/
| |-- 123
| `-- xyz
`-- source/
`-- foo/
`-- bar/
|-- 123
`-- xyz

6 directories, 4 files

A "dest/foo" was created".

Now, test with "dest/foo/":

/tmp/rsync-test$ rm -fr dest/foo
/tmp/rsync-test$ tree -anF
.
|-- dest/
`-- source/
`-- foo/
`-- bar/
|-- 123
`-- xyz

4 directories, 2 files
/tmp/rsync-test$ rsync -av source/foo/bar dest/foo/
sending incremental file list
created directory dest/foo
bar/
bar/123
bar/xyz

sent 186 bytes received 89 bytes 550.00 bytes/sec
total size is 0 speedup is 0.00
/tmp/rsync-test$ tree -anF
.
|-- dest/
| `-- foo/
| `-- bar/
| |-- 123
| `-- xyz
`-- source/
`-- foo/
`-- bar/
|-- 123
`-- xyz

6 directories, 4 files

A "dest/foo" was created.

Both versions (with and without trailing slash) on the destination
produced the identical outcome.

Trailing slash only has meaning to rsync on sources, not on
destinations.

[Ian Zimmerman]

On 2016-06-10 11:42 +0300, Anssi Saari wrote:

> OTOH, there's unison which uses rsync but has a UI, text or gui, and
> tells you what files have changed and which way it thinks they should be
> synced. I used it to sync a directory tree between two computers in
> different networks via an external drive some time ago and it worked
> great.

I love unison. I use it, among other things, as a fetchmail replacement
:)

That said:

1. unison doesn't "use rsync", but it uses the same incremental checksum
algo to detect if local and remote copies of a file are identical.

2. unison has some practical problems:

2a. the protocol changes after every major release, so you _must_ have
the same major version on both sides.

2b. it is written in Ocaml which is cool, but:

2b1. if you install it from source, you must install Ocaml first.

2b2. only some (not latest) versions of Ocaml will work; if you compile
with a "too recent" Ocaml the compile will seem to work but your unison
binary will fail to communicate with a remote compiled with an earlier
Ocaml version.

--
Please *no* private copies of mailing list or newsgroup messages.
Rule 420: All persons more than eight miles high to leave the court.

[Kenny McCormack]

In article <vg3ziqt...@coffee.modeemi.fi>, Anssi Saari <a...@sci.fi> wrote:
>gaz...@shell.xmission.com (Kenny McCormack) writes:
>
>> I know that newsgroup types think that rsync is the cat's pajamas, but I
>> don't like it. It's way too complicated.
>
>I agree although I've gotten used to it in the last few years at least
>enough that if I try to sync /foo/whatever with /bar/whatever I don't
>usually end up with /foo/bar/whatever any more.

Now, that's re-assuring and comforting.

Note that there is nothing in this thread to indicate that syncing to/from
remote systems has anything to do with anything. And note that although I
am sure it can do it, using (and thus having to learn) rsync when you're
just working with local filesystems is a bit absurd.

>OTOH, there's unison which uses rsync but has a UI, text or gui, and
>tells you what files have changed and which way it thinks they should be
>synced. I used it to sync a directory tree between two computers in
>different networks via an external drive some time ago and it worked
>great.

I've browsed the unison site a couple of times and it looks interesting,
but I've never gotten to the point of actually downloading it and
test-driving it. The fact that it is written in 0caml is a bit
off-putting, as the comments made by Ian attest to.

Note also (as Ian has also noted) that saying it "uses rsync" is not really
accurate.

Finally, another tool that I have started using lately, and which I really
like and can heartily recommend, is "meld". This a GUI program, written in
Python, that looks and feels a lot like a certain "sync up" program for MS
Windows.

--
The randomly generated signature file that would have appeared here is more than 4
lines in length. As such, it violates one or more Usenet RFPs. In order to remain in
compliance with said RFPs, the actual sig can be found at the following web address:

http://www.xmission.com/~gazelle/Sigs/Infallibility

[Carlos E. R.]

On 2016-06-11 08:37, Kenny McCormack wrote:

>> I agree although I've gotten used to it in the last few years at least
>> enough that if I try to sync /foo/whatever with /bar/whatever I don't
>> usually end up with /foo/bar/whatever any more.
>
> Now, that's re-assuring and comforting.
>
> Note that there is nothing in this thread to indicate that syncing to/from
> remote systems has anything to do with anything. And note that although I
> am sure it can do it, using (and thus having to learn) rsync when you're
> just working with local filesystems is a bit absurd.

Well, another feature of rsync is that it compares original and copy,
byte by byte, to ensure the copy is accurate. That's the reason I use it
whenever I copy a large number of files.

> I've browsed the unison site a couple of times and it looks interesting,
> but I've never gotten to the point of actually downloading it and
> test-driving it. The fact that it is written in 0caml is a bit
> off-putting, as the comments made by Ian attest to.

It is a stable project. Whatever was used to build it is not very
important. The main feature is that it keeps two directories in sync,
choosing the copy direction automatically for each file. This is just
the thing, for example, to keep in sync the documents folder between
desktop and laptop, say.

Caveat: both machines need to have the same unison version; if not, the
application may refuse to sync, possibly because the database of changes
is different version (guessing).

> Finally, another tool that I have started using lately, and which I really
> like and can heartily recommend, is "meld". This a GUI program, written in
> Python, that looks and feels a lot like a certain "sync up" program for MS
> Windows.

Yes, very good tool, for plain text files. I use it a lot with config files.


--
Cheers,
Carlos E.R.

[Kenny McCormack]

In article <4sbt2d-...@minas-tirith.valinor>,
Carlos E. R. <robin_...@invalid.es> wrote:
...
>Yes, very good tool, for plain text files. I use it (meld) a lot with config files.

Curious comment. Why only for text files?

--
The randomly generated signature file that would have appeared here is more than 4
lines in length. As such, it violates one or more Usenet RFPs. In order to remain in
compliance with said RFPs, the actual sig can be found at the following web address:

http://www.xmission.com/~gazelle/Sigs/TedCruz

[Carlos E. R.]

On 2016-06-11 15:05, Kenny McCormack wrote:
> In article <4sbt2d-...@minas-tirith.valinor>,

> Carlos E. R. <> wrote:
> ...
>> Yes, very good tool, for plain text files. I use it (meld) a lot with config files.
>
> Curious comment. Why only for text files?

It can not edit binary files. Only can edit and compare text files.

--
Cheers,
Carlos E.R.

[Kenny McCormack]

In article <baft2d-...@minas-tirith.valinor>,

Carlos E. R. <robin_...@invalid.es> wrote:

Not my experience.

Edit, maybe, but I don't think I'd ever consider using meld as a file
editor (that's what vi is for).

But (IME) it certainly does compare (and flag as different) binary files
(in my testing, even if the file size and timestamps on the files are the
same - this happened because one of the copies had become corrupt).

[Barry Margolin]

In article <4sbt2d-...@minas-tirith.valinor>,

"Carlos E. R." <robin_...@invalid.es> wrote:

> On 2016-06-11 08:37, Kenny McCormack wrote:
>
> >> I agree although I've gotten used to it in the last few years at least
> >> enough that if I try to sync /foo/whatever with /bar/whatever I don't
> >> usually end up with /foo/bar/whatever any more.
> >
> > Now, that's re-assuring and comforting.
> >
> > Note that there is nothing in this thread to indicate that syncing to/from
> > remote systems has anything to do with anything. And note that although I
> > am sure it can do it, using (and thus having to learn) rsync when you're
> > just working with local filesystems is a bit absurd.
>
> Well, another feature of rsync is that it compares original and copy,
> byte by byte, to ensure the copy is accurate. That's the reason I use it
> whenever I copy a large number of files.

I use it when I snapshot a large number of files so that it only copies
the files that have changed since the last snapshot.

For instance, on our webserver I have a sandbox with a personal copy of
the application (while most testing can be done on a development server,
there are some things that work better on the production server). So I do

rsync -a client/<latest-version>/ client/barmar/

whenever I want to get my sandbox up to date.

[Carlos E. R.]

On 2016-06-11 16:34, Kenny McCormack wrote:
> In article <baft2d-...@minas-tirith.valinor>,
> Carlos E. R. <robin_...@invalid.es> wrote:
>> On 2016-06-11 15:05, Kenny McCormack wrote:
>>> In article <4sbt2d-...@minas-tirith.valinor>,
>>> Carlos E. R. <> wrote:
>>> ...
>>>> Yes, very good tool, for plain text files. I use it (meld) a lot with
>>>> config files.
>>>
>>> Curious comment. Why only for text files?
>>
>> It can not edit binary files. Only can edit and compare text files.
>
> Not my experience.
>
> Edit, maybe, but I don't think I'd ever consider using meld as a file
> editor (that's what vi is for).

But that's the strength of meld. It signals not only that a file is
different, but what paragraph are different, or which letter. In the
double pane editor you can change either of the files, or click to copy
entire sections of one file to the other, and save the modifications.

I have never used it on binary files.

--
Cheers,
Carlos E.R.

[James K. Lowden]

On Fri, 10 Jun 2016 02:59:18 -0000 (UTC)
Rich <ri...@example.invalid> wrote:

> [1] this is different from almost every other CLI tool where for the
> most part foo/bar and foo/bar/ are treated as identical, or at most
> treated as requiring that "bar" actually be a directory.

That's not a feature.

The probability that the rsync authors would outsmart the rest of the
Posix community could have been predicted to be near zero, and indeed
that was the outcome. There are very few standard utlities for which a
trailing / is significant, and none of them involve pathname creation.
rsync should have looked at tar, pax, cpio, cp, and others I'm sure,
before inventing their own convention. They should have recognized
that tab-completion introduces a trailing slash, while environment
variables generally don't have them. They should, in short, have
accepted the fact that the trailing slash is not a semantic part of the
name.

--jkl

[James K. Lowden]

On Thu, 9 Jun 2016 19:57:08 +0000 (UTC)
gaz...@shell.xmission.com (Kenny McCormack) wrote:

> >> Please don't suggest other tools (i.e., other than "cp").
> >
> > Rsync's 'dir' vs 'dir/' syntax might just do exactly what you want
> > in this situation.

>
> I know that newsgroup types think that rsync is the cat's pajamas,
> but I don't like it. It's way too complicated.

I agree with you. To copy trees, I long ago adopted pax(1). Its
syntax is almost exactly like cp, and it has the benefit of retaining
timestamps (and, if need be, ownership). Your syntax would be:

# mount /dev/sdb1 /mnt/test
# cd /dev/sdb1
# pax -rw . /mnt/test

Learning pax saves you from dealing with tar, and from systems without
GNU cp.

> That is, funny ambiguity about whether or not to create a target
> directory.

The pax rule is there's no ambiguity: the target path is the source
path. In simple cases, these are all the same:

# pax -rw . /mnt/test
# pax -rw ./ /mnt/test
# pax -rw ./* /mnt/test
# pax -rw * /mnt/test

(There are options to transform the output filename; -s is much more
powerful than "use the source path or not". But "cd to src" keeps
things simple.)

There are good reasons not to use wildcards, though:

1. They ignore "hidden" files, such as .profile.
2. They introduce "flag" files (names with a leading hyphen).

For predictability, I always name the directory unless I want specific
files.

--jkl

[Kenny McCormack]

In article <20160611181636.d070...@speakeasy.net>,

James K. Lowden <jklo...@speakeasy.net> wrote:
>On Thu, 9 Jun 2016 19:57:08 +0000 (UTC)
>gaz...@shell.xmission.com (Kenny McCormack) wrote:
>
>> >> Please don't suggest other tools (i.e., other than "cp").
>> >
>> > Rsync's 'dir' vs 'dir/' syntax might just do exactly what you want
>> > in this situation.
>>
>> I know that newsgroup types think that rsync is the cat's pajamas,
>> but I don't like it. It's way too complicated.
>
>I agree with you. To copy trees, I long ago adopted pax(1). Its
>syntax is almost exactly like cp, and it has the benefit of retaining
>timestamps (and, if need be, ownership).

So does "cp" when you use the "-a" option.

>Your syntax would be:
> # mount /dev/sdb1 /mnt/test
> # cd /dev/sdb1

^^^^^^^^^

I doubt that line is correct. I think you mean "cd /"
(or, more generally, cd to your source directory)

> # pax -rw . /mnt/test
>
>Learning pax saves you from dealing with tar, and from systems without
>GNU cp.

I've never really had the inclination to learn pax, but pax is, basically,
cpio in a pretty, modern, wrapper, right?

Long and far away, the first method I ever learned to do this was:

# cd source directory
# find . | cpio -pvadum /path/to/dest

This is nice because you can use the flexibility and power of "find" to
accurately specify which files to copy.

>> That is, funny ambiguity about whether or not to create a target
>> directory.
>
>The pax rule is there's no ambiguity: the target path is the source
>path. In simple cases, these are all the same:
>
> # pax -rw . /mnt/test
> # pax -rw ./ /mnt/test
> # pax -rw ./* /mnt/test
> # pax -rw * /mnt/test
>
>(There are options to transform the output filename; -s is much more
>powerful than "use the source path or not". But "cd to src" keeps
>things simple.)

Yeah, I get it, but I still kinda prefer the model of cd'ing to the
destination and copy "from there to here", rather than the alternative of
copying "from here to there".

>There are good reasons not to use wildcards, though:

Agreed. No need to sell me on this.

But note that the *real* issue here is the "x" (in cp -avx).
Does pax have that functionality? If not, then it is a non-starter.

Note that "find" has "-xdev".

--
Modern Conservative: Someone who can take time out from flashing her
wedding ring around and bragging about her honeymoon to complain that a
fellow secretary who keeps a picture of her girlfriend on her desk is
"flauting her sexuality" and "forcing her lifestyle down our throats".

[Michael Baeuerle]

Kenny McCormack wrote:
>
> [...]

> But note that the *real* issue here is the "x" (in cp -avx).
> Does pax have that functionality?

pax has:
|
| -X
| When traversing the file hierarchy specified by a pathname, pax
| shall not descend into directories that have a different device ID
| (st_dev; see the System Interfaces volume of POSIX.1-2008, stat()).

> If not, then it is a non-starter.
>
> Note that "find" has "-xdev".

Also note that POSIX specify neither of "avx" for cp. All of them are
operating system specific extensions and not portable:
<http://pubs.opengroup.org/onlinepubs/9699919799/utilities/cp.html>


[Fup2 set to comp.os.linux.misc]

[Kenny McCormack]

In article <AABXXR4x/ewAAAt6....@Server4.micha.freeshell.org>,

Michael Baeuerle <michael....@gmx.net> wrote:
>Kenny McCormack wrote:
>>
>> [...]
>> But note that the *real* issue here is the "x" (in cp -avx).
>> Does pax have that functionality?
>
>pax has:
>|
>| -X
>| When traversing the file hierarchy specified by a pathname, pax
>| shall not descend into directories that have a different device ID
>| (st_dev; see the System Interfaces volume of POSIX.1-2008, stat()).

Good to know.

...

>> Note that "find" has "-xdev".
>
>Also note that POSIX specify neither of "avx" for cp. All of them are
>operating system specific extensions and not portable:
><http://pubs.opengroup.org/onlinepubs/9699919799/utilities/cp.html>

Not really "operating system specific". Rather, "GNU cp" specific.
Since this was noted in the original thread Subject, I don't see any
problem here.

Interestingly, I had thought that "pax" was a GNU thing as well, but I see
that it is present in OSX, so I'm assuming it is standardized. In any
case, it looks like just yet another thing to learn, so I think I'll stick
with (GNU) "cp".

--
"Insisting on perfect safety is for people who don't have the balls to live
in the real world."

- Mary Shafer, NASA Ames Dryden -

[Eric Pozharski]

with <20160611181630.e449...@speakeasy.net> James K.

Lowden wrote:
> On Fri, 10 Jun 2016 02:59:18 -0000 (UTC)
> Rich <ri...@example.invalid> wrote:

>> [1] this is different from almost every other CLI tool where for the
>> most part foo/bar and foo/bar/ are treated as identical, or at most
>> treated as requiring that "bar" actually be a directory.
> That's not a feature.

Yes, it is.

*SKIP*

> They should have recognized that tab-completion introduces a trailing
> slash, while environment variables generally don't have them.

The tab-completion is interactive only, there's no tab-completion in
scripts. Even worse, it's possible that they considered the
tab-completion is for pussies (it's from 1996). And speaking of
interactive, a tab-completion of zsh outsmarts one of bash.

*CUT*

--
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom

[James K. Lowden]

On Sun, 12 Jun 2016 10:24:43 +0000 (UTC)
gaz...@shell.xmission.com (Kenny McCormack) wrote:

> Interestingly, I had thought that "pax" was a GNU thing as well, but
> I see that it is present in OSX, so I'm assuming it is standardized.
> In any case, it looks like just yet another thing to learn, so I
> think I'll stick with (GNU) "cp".

AIUI pax was invented by Posix to, yes, make peace between the tar and
cpio camps.

http://pubs.opengroup.org/onlinepubs/7908799/xcu/pax.html

I think the popular trio for file-copying is cp, tar, and rsync.
Because I seldom have need for the synchronization feature, but do
frequently copy between machines, I use pax (& ssh) for all three.

It's certainly something else to learn. Despite the commissions, I
don't try to convert every prospect into a new customer. ;-)

> Long and far away, the first method I ever learned to do this was:
>
> # cd source directory
> # find . | cpio -pvadum /path/to/dest

I've used cpio occasionally, when pathnames were more than
100 bytes, because of the ustar format limitation. It's an oddball; I
can't think of another filter that reads names on input and produces
data on output.

--jkl

[Kaz Kylheku]

On 2016-06-12, Eric Pozharski <why...@pozharski.name> wrote:
> with <20160611181630.e449...@speakeasy.net> James K.
> Lowden wrote:
>> On Fri, 10 Jun 2016 02:59:18 -0000 (UTC)
>> Rich <ri...@example.invalid> wrote:
>
>>> [1] this is different from almost every other CLI tool where for the
>>> most part foo/bar and foo/bar/ are treated as identical, or at most
>>> treated as requiring that "bar" actually be a directory.
>> That's not a feature.
>
> Yes, it is.
>
> *SKIP*
>> They should have recognized that tab-completion introduces a trailing
>> slash, while environment variables generally don't have them.
>
> The tab-completion is interactive only, there's no tab-completion in
> scripts. Even worse, it's possible that they considered the
> tab-completion is for pussies (it's from 1996). And speaking of
> interactive, a tab-completion of zsh outsmarts one of bash.

Rsync's trailing slash hack is superfluous. The dot trick is portable
to rsync just fine:

Demo:

$ find .
.
./a
./a/file
./b
$ rsync -au a/. b
$ find .
.
./a
./a/file
./b
./b/file
$ rm b/file
$ rsync -au a b
$ find
.
./a
./a/file
./b
./b/a
./b/a/file

[James K. Lowden]

On Sun, 12 Jun 2016 17:25:54 +0300
Eric Pozharski <why...@pozharski.name> wrote:

> with <20160611181630.e449...@speakeasy.net> James K.
> Lowden wrote:
> > On Fri, 10 Jun 2016 02:59:18 -0000 (UTC)
> > Rich <ri...@example.invalid> wrote:
>
> >> [1] this is different from almost every other CLI tool where for
> >> the most part foo/bar and foo/bar/ are treated as identical, or at
> >> most treated as requiring that "bar" actually be a directory.
> > That's not a feature.
>
> Yes, it is.

If by that you mean "It's a feature, because that's how it works", the
statement is tautological and so adds nothing to the discussion.

If you mean, "It's a good thing", you have added only your unsupported
opinion, which if not nothing is epsilon away.

As Kaz says, the feature is unnecessary because redundant. Beyond
that, it is inconsistent with most other utilities, and imposes
meaning where none exists. (A directory name may have zero or more
trailing slashes with no change in semantics.)

If you want to argue in favor of unnecessary and inconsistent, by all
means, be my guest. You wont be the first, and it might be
entertaining.

--jkl

[Ian Zimmerman]

Will this also work for duplicating the current directory on the remote?
I.e. will this work as expected:

$ pwd
/some/path/a
$ find ..
..
../a
../a/file
../b
$ rsync -au ./. ../b/a
$ find ..
..
../a
../a/file
../b
../b/a
../b/a/file

This (or rather the translation of this into the slash hack version)
accounts for 90% of my uses of rsync ...

--
Please *no* private copies of mailing list or newsgroup messages.

Why does the arrow on Hillary signs point to the right?

[Eric Pozharski]

with <20160612183905.8cc2...@speakeasy.net> James K.

Lowden wrote:
> On Sun, 12 Jun 2016 17:25:54 +0300 Eric Pozharski
> <why...@pozharski.name> wrote:
>> with <20160611181630.e449...@speakeasy.net> James K.
>> Lowden wrote:
>>> On Fri, 10 Jun 2016 02:59:18 -0000 (UTC) Rich <ri...@example.invalid>
>>> wrote:

>>>> [1] this is different from almost every other CLI tool where for
>>>> the most part foo/bar and foo/bar/ are treated as identical, or at
>>>> most treated as requiring that "bar" actually be a directory.
>>> That's not a feature.
>> Yes, it is.

*SKIP*

> If you want to argue in favor of unnecessary and inconsistent, by all
> means, be my guest. You wont be the first, and it might be
> entertaining.

That's a negative -- I'm not interested. I just have one question: Are
you going to make world a better place, a place without trailing slash?

[Eric Pozharski]

with <201606121...@kylheku.com> Kaz Kylheku wrote:
> On 2016-06-12, Eric Pozharski <why...@pozharski.name> wrote:
>> with <20160611181630.e449...@speakeasy.net> James K.
>> Lowden wrote:
>>> On Fri, 10 Jun 2016 02:59:18 -0000 (UTC) Rich <ri...@example.invalid>
>>> wrote:

>>>> [1] this is different from almost every other CLI tool where for
>>>> the most part foo/bar and foo/bar/ are treated as identical, or at
>>>> most treated as requiring that "bar" actually be a directory.
>>> That's not a feature.
>> Yes, it is.
*SKIP*

> Rsync's trailing slash hack is superfluous. The dot trick is portable
> to rsync just fine:

Because slash-dot is handled by rsync itself. Eg, flist.c,
send_if_directory(), first statement:

char is_dot_dir = fbuf[ol-1] == '.' && (ol == 1 || fbuf[ol-2] == '/');

What was your point again?

[Valentin Nechayev]

>>> James K. Lowden wrote:

>> [1] this is different from almost every other CLI tool where for the
>> most part foo/bar and foo/bar/ are treated as identical, or at most
>> treated as requiring that "bar" actually be a directory.

JKL> That's not a feature.

JKL> The probability that the rsync authors would outsmart the rest of the
JKL> Posix community could have been predicted to be near zero, and indeed
JKL> that was the outcome. There are very few standard utlities for which a
JKL> trailing / is significant, and none of them involve pathname creation.
JKL> rsync should have looked at tar, pax, cpio, cp, and others I'm sure,
JKL> before inventing their own convention. They should have recognized
JKL> that tab-completion introduces a trailing slash, while environment
JKL> variables generally don't have them. They should, in short, have
JKL> accepted the fact that the trailing slash is not a semantic part of the
JKL> name.

The problem is really deeper. With standard utilities like cp/mv, it's
obscure to predict what would happen, for example, in the
following case:

$ mkdir foo
$ touch foo/a
$ mkdir bar
[... some event can delete or move bar ...]
$ mv foo bar

and why it renamed foo to bar/foo instead of deleting directory bar, or
merging with it, or stopping with complaint that bar already exists?
OTOH, if I expect bar exists and it's a directory, if it's deleted
from outside, foo will be renamed to bar, not bar/foo. It's a weird
race condition.

Even the current behavior is a good default for interactive work, I
would see here an option with values "force the same level" or "force one
deeper level". Rsync does practically the same ("the same level" if
final /, "deeper by 1" otherwise), but this would be consistent with
other tools and allow the same syntax for both local and remote
operations.


--netch--

[Scott Lurndal]

Valentin Nechayev <ne...@segfault.kiev.ua> writes:
>

>The problem is really deeper. With standard utilities like cp/mv, it's
>obscure to predict what would happen, for example, in the
>following case:
>
>$ mkdir foo
>$ touch foo/a
>$ mkdir bar
>[... some event can delete or move bar ...]
>$ mv foo bar
>

renaming 'foo' to 'bar/foo' is not at all obscure. It is the behavior
defined by POSIX (which codified 40+ years of Unix behavior).

[Valentin Nechayev]

>>> Scott Lurndal wrote:

>>$ mkdir foo
>>$ touch foo/a
>>$ mkdir bar
>>[... some event can delete or move bar ...]
>>$ mv foo bar
>>

SL> renaming 'foo' to 'bar/foo' is not at all obscure. It is the behavior
SL> defined by POSIX (which codified 40+ years of Unix behavior).

If `foo' is really `/a/long/path/ago/in/far/galaxy/foo', you start
requiring `basename' to separate the last part, so, one more brick of
cumbering... and all this instead of simply constraining already coded
functionality of cp/mv/etc.


--netch--

[Kaz Kylheku]

["Followup-To:" header set to comp.unix.shell.]

On 2016-06-23, Valentin Nechayev <ne...@segfault.kiev.ua> wrote:
>
>>>> James K. Lowden wrote:
>
>>> [1] this is different from almost every other CLI tool where for the
>>> most part foo/bar and foo/bar/ are treated as identical, or at most
>>> treated as requiring that "bar" actually be a directory.
>
> JKL> That's not a feature.
>
> JKL> The probability that the rsync authors would outsmart the rest of the
> JKL> Posix community could have been predicted to be near zero, and indeed
> JKL> that was the outcome. There are very few standard utlities for which a
> JKL> trailing / is significant, and none of them involve pathname creation.
> JKL> rsync should have looked at tar, pax, cpio, cp, and others I'm sure,
> JKL> before inventing their own convention. They should have recognized
> JKL> that tab-completion introduces a trailing slash, while environment
> JKL> variables generally don't have them. They should, in short, have
> JKL> accepted the fact that the trailing slash is not a semantic part of the
> JKL> name.
>
> The problem is really deeper. With standard utilities like cp/mv, it's
> obscure to predict what would happen, for example, in the
> following case:
>
> $ mkdir foo
> $ touch foo/a
> $ mkdir bar
> [... some event can delete or move bar ...]
> $ mv foo bar

If some event can delete or move bar, then there is a concurrency
problem that you're not solving. Combining the mkdir with the mv
into an atomic operation is not a solution for that problem.

See, if some asynchronous event delete or move bar, then this execution
scenario is also possible:

$ mkdir foo
$ touch foo/a
$ mkdir bar

$ mv foo bar

[... some event can delete or move bar ...]

In this order, we predictably get bar/foo/a. Then the event
moves it or deletes it. Oops!

This order is also possible:

$ mkdir foo
$ touch foo/a

[... some event *tries* unsuccessfully to delete/move bar ...]
$ mkdir bar
$ mv foo bar

If there *can* be such an event, you have to rethink the whole problem
and solution from the big picture on down to the details.

[lawren...@gmail.com]

On Friday, June 10, 2016 at 6:21:12 AM UTC+12, Kenny McCormack wrote:
> So, to copy the root of the current running system to
> the SD card, it would be like this:
>
> # mount /dev/sdb2 /mnt/test
> # cd /mnt/test
> # cp -avx / .

In Linux, you could use a bind mount, e.g.

# mkdir /mnt/{src,dst}
# mount --bind / /mnt/src
# mount /dev/sdb2 /mnt/dst
# cp -av /mnt/src /mnt/dst

[Kenny McCormack]

In article <5ee65e85-f477-4844...@googlegroups.com>,

That's interesting. Seriously, I am fond of "mount --bind", as it can, on
occasion, be really useful.

But I don't see how/why your solution is any better than mine. Can you
elaborate?

--
"There's no chance that the iPhone is going to get any significant market share. No chance." - Steve Ballmer

[lawren...@gmail.com]

On Friday, July 15, 2016 at 1:43:18 PM UTC+12, Kenny McCormack wrote:

> But I don't see how/why your solution is any better than mine. Can you
> elaborate?

It works in the situation you had trouble with.