rsync: exclude not working when using a variable
Could someone please explain to me this behaviour I noticed lately when I was sync'ing a directory to another server via rsync? I wanted to exclude the sub-directory "done" in this case.
When I put the options to use with rsync into a variable, that directory was not excluded. But it was when I put the options directly behind the rsync call.
Changes to "-av" made a difference, but the exclude didn't work.
rsync 3.0.9-18, on bash, CentOS 7.4
Not excluded:
$ RSYNC_OPTIONS='-av --exclude "done"'
$ touch done/test.ignore && rsync ${RSYNC_OPTIONS} ${SOURCEDIR} ${TARGET}
sending incremental file list
done/test.ignore
sent 132 bytes received 32 bytes 109.33 bytes/sec
total size is 0 speedup is 0.00
Excluded:
$ touch done/test.ignore && rsync -av --exclude "done" ${SOURCEDIR} ${TARGET}
sending incremental file list
sent 41 bytes received 12 bytes 106.00 bytes/sec
total size is 0 speedup is 0.00
linux bash rsync
add a comment |
Could someone please explain to me this behaviour I noticed lately when I was sync'ing a directory to another server via rsync? I wanted to exclude the sub-directory "done" in this case.
When I put the options to use with rsync into a variable, that directory was not excluded. But it was when I put the options directly behind the rsync call.
Changes to "-av" made a difference, but the exclude didn't work.
rsync 3.0.9-18, on bash, CentOS 7.4
Not excluded:
$ RSYNC_OPTIONS='-av --exclude "done"'
$ touch done/test.ignore && rsync ${RSYNC_OPTIONS} ${SOURCEDIR} ${TARGET}
sending incremental file list
done/test.ignore
sent 132 bytes received 32 bytes 109.33 bytes/sec
total size is 0 speedup is 0.00
Excluded:
$ touch done/test.ignore && rsync -av --exclude "done" ${SOURCEDIR} ${TARGET}
sending incremental file list
sent 41 bytes received 12 bytes 106.00 bytes/sec
total size is 0 speedup is 0.00
linux bash rsync
1
See this stackoverflow question: Why do bash parameter expansions cause an rsync command to operate differently?
– Gordon Davisson
Jan 23 at 18:18
add a comment |
Could someone please explain to me this behaviour I noticed lately when I was sync'ing a directory to another server via rsync? I wanted to exclude the sub-directory "done" in this case.
When I put the options to use with rsync into a variable, that directory was not excluded. But it was when I put the options directly behind the rsync call.
Changes to "-av" made a difference, but the exclude didn't work.
rsync 3.0.9-18, on bash, CentOS 7.4
Not excluded:
$ RSYNC_OPTIONS='-av --exclude "done"'
$ touch done/test.ignore && rsync ${RSYNC_OPTIONS} ${SOURCEDIR} ${TARGET}
sending incremental file list
done/test.ignore
sent 132 bytes received 32 bytes 109.33 bytes/sec
total size is 0 speedup is 0.00
Excluded:
$ touch done/test.ignore && rsync -av --exclude "done" ${SOURCEDIR} ${TARGET}
sending incremental file list
sent 41 bytes received 12 bytes 106.00 bytes/sec
total size is 0 speedup is 0.00
linux bash rsync
Could someone please explain to me this behaviour I noticed lately when I was sync'ing a directory to another server via rsync? I wanted to exclude the sub-directory "done" in this case.
When I put the options to use with rsync into a variable, that directory was not excluded. But it was when I put the options directly behind the rsync call.
Changes to "-av" made a difference, but the exclude didn't work.
rsync 3.0.9-18, on bash, CentOS 7.4
Not excluded:
$ RSYNC_OPTIONS='-av --exclude "done"'
$ touch done/test.ignore && rsync ${RSYNC_OPTIONS} ${SOURCEDIR} ${TARGET}
sending incremental file list
done/test.ignore
sent 132 bytes received 32 bytes 109.33 bytes/sec
total size is 0 speedup is 0.00
Excluded:
$ touch done/test.ignore && rsync -av --exclude "done" ${SOURCEDIR} ${TARGET}
sending incremental file list
sent 41 bytes received 12 bytes 106.00 bytes/sec
total size is 0 speedup is 0.00
linux bash rsync
linux bash rsync
asked Jan 23 at 11:44
LarsenLarsen
14817
14817
1
See this stackoverflow question: Why do bash parameter expansions cause an rsync command to operate differently?
– Gordon Davisson
Jan 23 at 18:18
add a comment |
1
See this stackoverflow question: Why do bash parameter expansions cause an rsync command to operate differently?
– Gordon Davisson
Jan 23 at 18:18
1
1
See this stackoverflow question: Why do bash parameter expansions cause an rsync command to operate differently?
– Gordon Davisson
Jan 23 at 18:18
See this stackoverflow question: Why do bash parameter expansions cause an rsync command to operate differently?
– Gordon Davisson
Jan 23 at 18:18
add a comment |
2 Answers
2
active
oldest
votes
I have replicated the problem and used set -x
to see what the both commands really look like. It turned out this command
rsync ${RSYNC_OPTIONS} ${SOURCEDIR} ${TARGET}
is in fact equivalent to this
rsync -av --exclude '"done"' ${SOURCEDIR} ${TARGET}
Note the quotes in quotes. Your pattern is not done
; it's "done"
, as if the directory you want to exclude had double quotes in its actual name.
To almost fix this you can declare the variable without these troublesome quotes:
RSYNC_OPTIONS='-av --exclude done' # poor fix, don't
rsync ${RSYNC_OPTIONS} "${SOURCEDIR}" "${TARGET}"
But this will backfire if the pattern contains spaces etc. Another approach may be with eval
:
RSYNC_OPTIONS='-av --exclude "name with double spaces"'
eval rsync "${RSYNC_OPTIONS}" '"${SOURCEDIR}" "${TARGET}"' # not recommended
eval
will parse the line for the second time. It's very hard to use it right and safely. I double quoted ${RSYNC_OPTIONS}
so "name with double spaces"
doesn't lose double spaces. I single quoted "${SOURCEDIR}" "${TARGET}"
, so these variables are not expanded right away (otherwise their content would undergo expansion). This is tricky!
Besides, what about name "with' quotes
? To get this exact string as an option-argument to rsync --exclude
you need some obscure quoting and escaping in RSYNC_OPTIONS
declaration. There are more reasons to avoid eval
.
The real solution is to use an array in Bash. Note arrays are not portable.
RSYNC_OPTIONS=(-av --exclude 'name with spaces and $u(h')
rsync "${RSYNC_OPTIONS[@]}" "${SOURCEDIR}" "${TARGET}"
I understand why you didn't quote ${RSYNC_OPTIONS}
in your original approach. You should have quoted ${SOURCEDIR}
and (separately) ${TARGET}
though. The above command quotes each variable properly.
Or maybe ${SOURCEDIR}
was meant to specify multiple sources? This would be the reason not to quote it, but then it could bring similar issues as ${RSYNC_OPTIONS}
. In this case you should definitely use an array variable here as well.
Also consider variable names in lower case.
Thanks very much for this thorough explanation! Haven't put the other variables in quotes as those really are constants (I exactly know the one value they contain). Will have a look at the "lower case" link.
– Larsen
Jan 23 at 17:10
add a comment |
What about placing your quotes like this ?
RSYNC_OPTIONS='-av --exclude '"done"''
I only tested it on a simplified command:
SEP='-F ";"'
echo "1;2;3" | awk ${SEP} '{print $2}'
(not working)
SEP='-F '";"''
echo "1;2;3" | awk ${SEP} '{print $2}'
(working)
Edit:
With @Kamil technique, array works well too:
SEP=(-F ";")
echo "1;2;3" | awk ${SEP[@]} '{print $2}'
2
A red herring.SEP='-F '";"''
defines the same variable value asSEP='-F ;'
(comparedeclare -p SEP
in both cases), therefore your working example is just my "poor fix" in disguise. I downvoted because this answer brings nothing new, except this weird quoting technique that only obfuscates the problem.
– Kamil Maciorowski
Jan 23 at 15:07
@KamilMaciorowski I'm a bash newbie, I just like to think there's a workaround with using only strings, but obviously I'm wrong.
– Yoric
Jan 23 at 15:27
Well, in fact there is a workaround. It involveseval
and it's rather awful. My answer is now updated to cover this. While I think your answer here is not useful, there are two other answers of yours I upvoted today. In my opinion there's a mishap here, but in general you're doing well.
– Kamil Maciorowski
Jan 23 at 16:25
@KamilMaciorowski Thanks for adding to your already clear explanation, and for your concern. We do learn a lot from experienced techies like you that are kind enough to take the time to even put the appropriate links to read further. I am ok to be wrong as long as I learn more :) I am just amazed with the Linux World and a bit frustrated not to know 5% of it.
– Yoric
Jan 23 at 16:42
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1397429%2frsync-exclude-not-working-when-using-a-variable%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
I have replicated the problem and used set -x
to see what the both commands really look like. It turned out this command
rsync ${RSYNC_OPTIONS} ${SOURCEDIR} ${TARGET}
is in fact equivalent to this
rsync -av --exclude '"done"' ${SOURCEDIR} ${TARGET}
Note the quotes in quotes. Your pattern is not done
; it's "done"
, as if the directory you want to exclude had double quotes in its actual name.
To almost fix this you can declare the variable without these troublesome quotes:
RSYNC_OPTIONS='-av --exclude done' # poor fix, don't
rsync ${RSYNC_OPTIONS} "${SOURCEDIR}" "${TARGET}"
But this will backfire if the pattern contains spaces etc. Another approach may be with eval
:
RSYNC_OPTIONS='-av --exclude "name with double spaces"'
eval rsync "${RSYNC_OPTIONS}" '"${SOURCEDIR}" "${TARGET}"' # not recommended
eval
will parse the line for the second time. It's very hard to use it right and safely. I double quoted ${RSYNC_OPTIONS}
so "name with double spaces"
doesn't lose double spaces. I single quoted "${SOURCEDIR}" "${TARGET}"
, so these variables are not expanded right away (otherwise their content would undergo expansion). This is tricky!
Besides, what about name "with' quotes
? To get this exact string as an option-argument to rsync --exclude
you need some obscure quoting and escaping in RSYNC_OPTIONS
declaration. There are more reasons to avoid eval
.
The real solution is to use an array in Bash. Note arrays are not portable.
RSYNC_OPTIONS=(-av --exclude 'name with spaces and $u(h')
rsync "${RSYNC_OPTIONS[@]}" "${SOURCEDIR}" "${TARGET}"
I understand why you didn't quote ${RSYNC_OPTIONS}
in your original approach. You should have quoted ${SOURCEDIR}
and (separately) ${TARGET}
though. The above command quotes each variable properly.
Or maybe ${SOURCEDIR}
was meant to specify multiple sources? This would be the reason not to quote it, but then it could bring similar issues as ${RSYNC_OPTIONS}
. In this case you should definitely use an array variable here as well.
Also consider variable names in lower case.
Thanks very much for this thorough explanation! Haven't put the other variables in quotes as those really are constants (I exactly know the one value they contain). Will have a look at the "lower case" link.
– Larsen
Jan 23 at 17:10
add a comment |
I have replicated the problem and used set -x
to see what the both commands really look like. It turned out this command
rsync ${RSYNC_OPTIONS} ${SOURCEDIR} ${TARGET}
is in fact equivalent to this
rsync -av --exclude '"done"' ${SOURCEDIR} ${TARGET}
Note the quotes in quotes. Your pattern is not done
; it's "done"
, as if the directory you want to exclude had double quotes in its actual name.
To almost fix this you can declare the variable without these troublesome quotes:
RSYNC_OPTIONS='-av --exclude done' # poor fix, don't
rsync ${RSYNC_OPTIONS} "${SOURCEDIR}" "${TARGET}"
But this will backfire if the pattern contains spaces etc. Another approach may be with eval
:
RSYNC_OPTIONS='-av --exclude "name with double spaces"'
eval rsync "${RSYNC_OPTIONS}" '"${SOURCEDIR}" "${TARGET}"' # not recommended
eval
will parse the line for the second time. It's very hard to use it right and safely. I double quoted ${RSYNC_OPTIONS}
so "name with double spaces"
doesn't lose double spaces. I single quoted "${SOURCEDIR}" "${TARGET}"
, so these variables are not expanded right away (otherwise their content would undergo expansion). This is tricky!
Besides, what about name "with' quotes
? To get this exact string as an option-argument to rsync --exclude
you need some obscure quoting and escaping in RSYNC_OPTIONS
declaration. There are more reasons to avoid eval
.
The real solution is to use an array in Bash. Note arrays are not portable.
RSYNC_OPTIONS=(-av --exclude 'name with spaces and $u(h')
rsync "${RSYNC_OPTIONS[@]}" "${SOURCEDIR}" "${TARGET}"
I understand why you didn't quote ${RSYNC_OPTIONS}
in your original approach. You should have quoted ${SOURCEDIR}
and (separately) ${TARGET}
though. The above command quotes each variable properly.
Or maybe ${SOURCEDIR}
was meant to specify multiple sources? This would be the reason not to quote it, but then it could bring similar issues as ${RSYNC_OPTIONS}
. In this case you should definitely use an array variable here as well.
Also consider variable names in lower case.
Thanks very much for this thorough explanation! Haven't put the other variables in quotes as those really are constants (I exactly know the one value they contain). Will have a look at the "lower case" link.
– Larsen
Jan 23 at 17:10
add a comment |
I have replicated the problem and used set -x
to see what the both commands really look like. It turned out this command
rsync ${RSYNC_OPTIONS} ${SOURCEDIR} ${TARGET}
is in fact equivalent to this
rsync -av --exclude '"done"' ${SOURCEDIR} ${TARGET}
Note the quotes in quotes. Your pattern is not done
; it's "done"
, as if the directory you want to exclude had double quotes in its actual name.
To almost fix this you can declare the variable without these troublesome quotes:
RSYNC_OPTIONS='-av --exclude done' # poor fix, don't
rsync ${RSYNC_OPTIONS} "${SOURCEDIR}" "${TARGET}"
But this will backfire if the pattern contains spaces etc. Another approach may be with eval
:
RSYNC_OPTIONS='-av --exclude "name with double spaces"'
eval rsync "${RSYNC_OPTIONS}" '"${SOURCEDIR}" "${TARGET}"' # not recommended
eval
will parse the line for the second time. It's very hard to use it right and safely. I double quoted ${RSYNC_OPTIONS}
so "name with double spaces"
doesn't lose double spaces. I single quoted "${SOURCEDIR}" "${TARGET}"
, so these variables are not expanded right away (otherwise their content would undergo expansion). This is tricky!
Besides, what about name "with' quotes
? To get this exact string as an option-argument to rsync --exclude
you need some obscure quoting and escaping in RSYNC_OPTIONS
declaration. There are more reasons to avoid eval
.
The real solution is to use an array in Bash. Note arrays are not portable.
RSYNC_OPTIONS=(-av --exclude 'name with spaces and $u(h')
rsync "${RSYNC_OPTIONS[@]}" "${SOURCEDIR}" "${TARGET}"
I understand why you didn't quote ${RSYNC_OPTIONS}
in your original approach. You should have quoted ${SOURCEDIR}
and (separately) ${TARGET}
though. The above command quotes each variable properly.
Or maybe ${SOURCEDIR}
was meant to specify multiple sources? This would be the reason not to quote it, but then it could bring similar issues as ${RSYNC_OPTIONS}
. In this case you should definitely use an array variable here as well.
Also consider variable names in lower case.
I have replicated the problem and used set -x
to see what the both commands really look like. It turned out this command
rsync ${RSYNC_OPTIONS} ${SOURCEDIR} ${TARGET}
is in fact equivalent to this
rsync -av --exclude '"done"' ${SOURCEDIR} ${TARGET}
Note the quotes in quotes. Your pattern is not done
; it's "done"
, as if the directory you want to exclude had double quotes in its actual name.
To almost fix this you can declare the variable without these troublesome quotes:
RSYNC_OPTIONS='-av --exclude done' # poor fix, don't
rsync ${RSYNC_OPTIONS} "${SOURCEDIR}" "${TARGET}"
But this will backfire if the pattern contains spaces etc. Another approach may be with eval
:
RSYNC_OPTIONS='-av --exclude "name with double spaces"'
eval rsync "${RSYNC_OPTIONS}" '"${SOURCEDIR}" "${TARGET}"' # not recommended
eval
will parse the line for the second time. It's very hard to use it right and safely. I double quoted ${RSYNC_OPTIONS}
so "name with double spaces"
doesn't lose double spaces. I single quoted "${SOURCEDIR}" "${TARGET}"
, so these variables are not expanded right away (otherwise their content would undergo expansion). This is tricky!
Besides, what about name "with' quotes
? To get this exact string as an option-argument to rsync --exclude
you need some obscure quoting and escaping in RSYNC_OPTIONS
declaration. There are more reasons to avoid eval
.
The real solution is to use an array in Bash. Note arrays are not portable.
RSYNC_OPTIONS=(-av --exclude 'name with spaces and $u(h')
rsync "${RSYNC_OPTIONS[@]}" "${SOURCEDIR}" "${TARGET}"
I understand why you didn't quote ${RSYNC_OPTIONS}
in your original approach. You should have quoted ${SOURCEDIR}
and (separately) ${TARGET}
though. The above command quotes each variable properly.
Or maybe ${SOURCEDIR}
was meant to specify multiple sources? This would be the reason not to quote it, but then it could bring similar issues as ${RSYNC_OPTIONS}
. In this case you should definitely use an array variable here as well.
Also consider variable names in lower case.
edited Jan 23 at 15:57
answered Jan 23 at 13:27
Kamil MaciorowskiKamil Maciorowski
28k156184
28k156184
Thanks very much for this thorough explanation! Haven't put the other variables in quotes as those really are constants (I exactly know the one value they contain). Will have a look at the "lower case" link.
– Larsen
Jan 23 at 17:10
add a comment |
Thanks very much for this thorough explanation! Haven't put the other variables in quotes as those really are constants (I exactly know the one value they contain). Will have a look at the "lower case" link.
– Larsen
Jan 23 at 17:10
Thanks very much for this thorough explanation! Haven't put the other variables in quotes as those really are constants (I exactly know the one value they contain). Will have a look at the "lower case" link.
– Larsen
Jan 23 at 17:10
Thanks very much for this thorough explanation! Haven't put the other variables in quotes as those really are constants (I exactly know the one value they contain). Will have a look at the "lower case" link.
– Larsen
Jan 23 at 17:10
add a comment |
What about placing your quotes like this ?
RSYNC_OPTIONS='-av --exclude '"done"''
I only tested it on a simplified command:
SEP='-F ";"'
echo "1;2;3" | awk ${SEP} '{print $2}'
(not working)
SEP='-F '";"''
echo "1;2;3" | awk ${SEP} '{print $2}'
(working)
Edit:
With @Kamil technique, array works well too:
SEP=(-F ";")
echo "1;2;3" | awk ${SEP[@]} '{print $2}'
2
A red herring.SEP='-F '";"''
defines the same variable value asSEP='-F ;'
(comparedeclare -p SEP
in both cases), therefore your working example is just my "poor fix" in disguise. I downvoted because this answer brings nothing new, except this weird quoting technique that only obfuscates the problem.
– Kamil Maciorowski
Jan 23 at 15:07
@KamilMaciorowski I'm a bash newbie, I just like to think there's a workaround with using only strings, but obviously I'm wrong.
– Yoric
Jan 23 at 15:27
Well, in fact there is a workaround. It involveseval
and it's rather awful. My answer is now updated to cover this. While I think your answer here is not useful, there are two other answers of yours I upvoted today. In my opinion there's a mishap here, but in general you're doing well.
– Kamil Maciorowski
Jan 23 at 16:25
@KamilMaciorowski Thanks for adding to your already clear explanation, and for your concern. We do learn a lot from experienced techies like you that are kind enough to take the time to even put the appropriate links to read further. I am ok to be wrong as long as I learn more :) I am just amazed with the Linux World and a bit frustrated not to know 5% of it.
– Yoric
Jan 23 at 16:42
add a comment |
What about placing your quotes like this ?
RSYNC_OPTIONS='-av --exclude '"done"''
I only tested it on a simplified command:
SEP='-F ";"'
echo "1;2;3" | awk ${SEP} '{print $2}'
(not working)
SEP='-F '";"''
echo "1;2;3" | awk ${SEP} '{print $2}'
(working)
Edit:
With @Kamil technique, array works well too:
SEP=(-F ";")
echo "1;2;3" | awk ${SEP[@]} '{print $2}'
2
A red herring.SEP='-F '";"''
defines the same variable value asSEP='-F ;'
(comparedeclare -p SEP
in both cases), therefore your working example is just my "poor fix" in disguise. I downvoted because this answer brings nothing new, except this weird quoting technique that only obfuscates the problem.
– Kamil Maciorowski
Jan 23 at 15:07
@KamilMaciorowski I'm a bash newbie, I just like to think there's a workaround with using only strings, but obviously I'm wrong.
– Yoric
Jan 23 at 15:27
Well, in fact there is a workaround. It involveseval
and it's rather awful. My answer is now updated to cover this. While I think your answer here is not useful, there are two other answers of yours I upvoted today. In my opinion there's a mishap here, but in general you're doing well.
– Kamil Maciorowski
Jan 23 at 16:25
@KamilMaciorowski Thanks for adding to your already clear explanation, and for your concern. We do learn a lot from experienced techies like you that are kind enough to take the time to even put the appropriate links to read further. I am ok to be wrong as long as I learn more :) I am just amazed with the Linux World and a bit frustrated not to know 5% of it.
– Yoric
Jan 23 at 16:42
add a comment |
What about placing your quotes like this ?
RSYNC_OPTIONS='-av --exclude '"done"''
I only tested it on a simplified command:
SEP='-F ";"'
echo "1;2;3" | awk ${SEP} '{print $2}'
(not working)
SEP='-F '";"''
echo "1;2;3" | awk ${SEP} '{print $2}'
(working)
Edit:
With @Kamil technique, array works well too:
SEP=(-F ";")
echo "1;2;3" | awk ${SEP[@]} '{print $2}'
What about placing your quotes like this ?
RSYNC_OPTIONS='-av --exclude '"done"''
I only tested it on a simplified command:
SEP='-F ";"'
echo "1;2;3" | awk ${SEP} '{print $2}'
(not working)
SEP='-F '";"''
echo "1;2;3" | awk ${SEP} '{print $2}'
(working)
Edit:
With @Kamil technique, array works well too:
SEP=(-F ";")
echo "1;2;3" | awk ${SEP[@]} '{print $2}'
edited Jan 23 at 14:13
answered Jan 23 at 14:05
YoricYoric
3196
3196
2
A red herring.SEP='-F '";"''
defines the same variable value asSEP='-F ;'
(comparedeclare -p SEP
in both cases), therefore your working example is just my "poor fix" in disguise. I downvoted because this answer brings nothing new, except this weird quoting technique that only obfuscates the problem.
– Kamil Maciorowski
Jan 23 at 15:07
@KamilMaciorowski I'm a bash newbie, I just like to think there's a workaround with using only strings, but obviously I'm wrong.
– Yoric
Jan 23 at 15:27
Well, in fact there is a workaround. It involveseval
and it's rather awful. My answer is now updated to cover this. While I think your answer here is not useful, there are two other answers of yours I upvoted today. In my opinion there's a mishap here, but in general you're doing well.
– Kamil Maciorowski
Jan 23 at 16:25
@KamilMaciorowski Thanks for adding to your already clear explanation, and for your concern. We do learn a lot from experienced techies like you that are kind enough to take the time to even put the appropriate links to read further. I am ok to be wrong as long as I learn more :) I am just amazed with the Linux World and a bit frustrated not to know 5% of it.
– Yoric
Jan 23 at 16:42
add a comment |
2
A red herring.SEP='-F '";"''
defines the same variable value asSEP='-F ;'
(comparedeclare -p SEP
in both cases), therefore your working example is just my "poor fix" in disguise. I downvoted because this answer brings nothing new, except this weird quoting technique that only obfuscates the problem.
– Kamil Maciorowski
Jan 23 at 15:07
@KamilMaciorowski I'm a bash newbie, I just like to think there's a workaround with using only strings, but obviously I'm wrong.
– Yoric
Jan 23 at 15:27
Well, in fact there is a workaround. It involveseval
and it's rather awful. My answer is now updated to cover this. While I think your answer here is not useful, there are two other answers of yours I upvoted today. In my opinion there's a mishap here, but in general you're doing well.
– Kamil Maciorowski
Jan 23 at 16:25
@KamilMaciorowski Thanks for adding to your already clear explanation, and for your concern. We do learn a lot from experienced techies like you that are kind enough to take the time to even put the appropriate links to read further. I am ok to be wrong as long as I learn more :) I am just amazed with the Linux World and a bit frustrated not to know 5% of it.
– Yoric
Jan 23 at 16:42
2
2
A red herring.
SEP='-F '";"''
defines the same variable value as SEP='-F ;'
(compare declare -p SEP
in both cases), therefore your working example is just my "poor fix" in disguise. I downvoted because this answer brings nothing new, except this weird quoting technique that only obfuscates the problem.– Kamil Maciorowski
Jan 23 at 15:07
A red herring.
SEP='-F '";"''
defines the same variable value as SEP='-F ;'
(compare declare -p SEP
in both cases), therefore your working example is just my "poor fix" in disguise. I downvoted because this answer brings nothing new, except this weird quoting technique that only obfuscates the problem.– Kamil Maciorowski
Jan 23 at 15:07
@KamilMaciorowski I'm a bash newbie, I just like to think there's a workaround with using only strings, but obviously I'm wrong.
– Yoric
Jan 23 at 15:27
@KamilMaciorowski I'm a bash newbie, I just like to think there's a workaround with using only strings, but obviously I'm wrong.
– Yoric
Jan 23 at 15:27
Well, in fact there is a workaround. It involves
eval
and it's rather awful. My answer is now updated to cover this. While I think your answer here is not useful, there are two other answers of yours I upvoted today. In my opinion there's a mishap here, but in general you're doing well.– Kamil Maciorowski
Jan 23 at 16:25
Well, in fact there is a workaround. It involves
eval
and it's rather awful. My answer is now updated to cover this. While I think your answer here is not useful, there are two other answers of yours I upvoted today. In my opinion there's a mishap here, but in general you're doing well.– Kamil Maciorowski
Jan 23 at 16:25
@KamilMaciorowski Thanks for adding to your already clear explanation, and for your concern. We do learn a lot from experienced techies like you that are kind enough to take the time to even put the appropriate links to read further. I am ok to be wrong as long as I learn more :) I am just amazed with the Linux World and a bit frustrated not to know 5% of it.
– Yoric
Jan 23 at 16:42
@KamilMaciorowski Thanks for adding to your already clear explanation, and for your concern. We do learn a lot from experienced techies like you that are kind enough to take the time to even put the appropriate links to read further. I am ok to be wrong as long as I learn more :) I am just amazed with the Linux World and a bit frustrated not to know 5% of it.
– Yoric
Jan 23 at 16:42
add a comment |
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1397429%2frsync-exclude-not-working-when-using-a-variable%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
See this stackoverflow question: Why do bash parameter expansions cause an rsync command to operate differently?
– Gordon Davisson
Jan 23 at 18:18