<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
Thanks for duplicating this. Even though it's a very small issue,
it would be good to fix it (make it an error) because this almost
invisible scripting error can lead to very unpredictable results
just depending on the current working directory which shouldn't have
any impact at all unless it is explicitly referenced in the
parameters.<br>
<br>
Your approach gets all the substitutions done before rsync gets to
see it, so "sometimes a blank is really just a blank" ;) .<br>
Joe<br>
<br>
On 11/05/2012 11:06 AM, Kevin Korb wrote:<br>
<span style="white-space: pre;">> Very interesting. It does
appear to take '' or "" as if it were "./"<br>
> in fact it appears to tale " " or ' ' as "./ " which throws
an error.<br>
><br>
> I think the reason I haven't seen this before is that I
always built<br>
> up a $RSYNC_PARAMS variable and passed that to rsync. That
variable<br>
> always had some params in it just they weren't always the
same.<br>
><br>
> On 11/05/12 02:39, Joe wrote:<br>
><br>
> > No. I traced the heck out of it (bash -vx ...) and I was
actually<br>
> > sending a null parameter as the first argument to rsync
and that<br>
> > made it get out of bed on the wrong side.<br>
><br>
> > Here are some more details as to what happened:<br>
><br>
> >
<a class="moz-txt-link-freetext" href="http://askubuntu.com/questions/112717/rsync-copies-files-from-working-directory-in-addition-to-the-requested-ones/113431">http://askubuntu.com/questions/112717/rsync-copies-files-from-working-directory-in-addition-to-the-requested-ones/113431</a><br>
><br>
> > Essentially, rsync worked, but additionally processed
all the<br>
> > files in the current working directory when that wasn't
expressly<br>
> > requested. Since null parameters are almost totally
invisible, it<br>
> > took awhile to find.<br>
><br>
> > Sorry I didn't include more details in my original post.<br>
><br>
> > On the bright side, this is what caused me to join this
list.<br>
> > I've learned a lot - mostly by lurking.<br>
><br>
> > Thanks. Joe<br>
><br>
> > On 11/04/2012 10:35 PM, Kevin Korb wrote:<br>
> >> I suspect you are missing a space somewhere and are
ending up<br>
> >> with 2 parameters stuck together. You can have bash
output the<br>
> >> rsync command line it intends to run to make sure or
you can just<br>
> >> use " " instead of "" as extra spaces between
parameters will<br>
> >> have no effect.<br>
><br>
> >> On 11/04/12 22:23, Joe wrote:<br>
> >>> I'm working on a bash backup script using rsync.
(kubuntu<br>
> >>> precise 12.04, rsync 3.0.9-1ubuntu1)<br>
><br>
> >>> To avoid having a number of slightly different
rsync commands,<br>
> >>> I would like to use shell variables as part of
the rsync<br>
> >>> command. I.e.: DRYRUN="-n" rsync "${DRYRUN}"
more parameters<br>
> >>> ...<br>
><br>
> >>> This does not work if DRYRUN="" - apparently
because this<br>
> >>> command becomes rsync "" more parameters ...
instead of rsync<br>
> >>> more parameters ...<br>
><br>
> >>> and rsync uses the null parameter for something
and does not<br>
> >>> perform as expected. It does not generate any
error or<br>
> >>> diagnostic message.<br>
><br>
> >>> Is there a way to get around this problem -
other than coding<br>
> >>> each permutation of the command separately?<br>
><br>
> >>> I'm experimenting with putting the whole rsync
command in a<br>
> >>> string so I can run it after any null parameters
revert to pure<br>
> >>> white space. Once I get the quoting to work
(preserving those<br>
> >>> quotes I still need), this method should work,
but it's less<br>
> >>> than elegant.<br>
><br>
> >>> Is this a bug in rsync? (Shouldn't it at least
complain/error<br>
> >>> exit if it gets something like this that it
doesn't<br>
> >>> understand?) If it is, what's the best way to
report it?<br>
><br>
> >>> Ideally (for me anyway), I would like it to
completely ignore<br>
> >>> any null parameters, but I don't know what
problems that might<br>
> >>> cause for other people.<br>
><br>
> >>> TIA<br>
><br>
> >>> Joe<br>
><br>
><br>
><br>
></span><br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1.4.11 (GNU/Linux)<br>
Comment: Using GnuPG with Mozilla - <a class="moz-txt-link-freetext" href="http://www.enigmail.net/">http://www.enigmail.net/</a><br>
<br>
iQEcBAEBAgAGBQJQl+1MAAoJELWM3hHMxTQOGU8H/3J5jsMe1QqcSfnhiR1Y3PNK<br>
RseQLv1CMpxX6pQom9rxmpOWaH9IhgmZxt8bPkb9qsWa7HMnaGC1o3xPq8V9fSdo<br>
HKKXiy+V9AlEqyFIVR+rNh1Qdcc9Gs3h5nb3gMWFEga8fTTN9FzEqzEZYKrIA0MQ<br>
qDm03iOkV3XjlGygUFAUeMUe0zJA5evqgRFhzqPRAjT2nzyH6hjBZ3MHmuk94mMQ<br>
mIiYILD0nx3EQpFnUXJSYqa4861R8tV1u+7t9JyKMUWY00MWZ/8Go4UZyn9kjfdQ<br>
TAz7cXqsZm1xAaNDahEM5muZ2lEdv99pAmUjpHsX6m1wHw6KqvTw8FlGKPB7M6Y=<br>
=IPqG<br>
-----END PGP SIGNATURE-----<br>
<br>
</body>
</html>