rsync: exclude not working when using a variable












0















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









share|improve this question


















  • 1





    See this stackoverflow question: Why do bash parameter expansions cause an rsync command to operate differently?

    – Gordon Davisson
    Jan 23 at 18:18
















0















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









share|improve this question


















  • 1





    See this stackoverflow question: Why do bash parameter expansions cause an rsync command to operate differently?

    – Gordon Davisson
    Jan 23 at 18:18














0












0








0








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









share|improve this question














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






share|improve this question













share|improve this question











share|improve this question




share|improve this question










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














  • 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










2 Answers
2






active

oldest

votes


















2














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.






share|improve this answer


























  • 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



















-1














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}'





share|improve this answer





















  • 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











  • @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











  • @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













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
});


}
});














draft saved

draft discarded


















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









2














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.






share|improve this answer


























  • 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
















2














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.






share|improve this answer


























  • 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














2












2








2







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.






share|improve this answer















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.







share|improve this answer














share|improve this answer



share|improve this answer








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



















  • 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













-1














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}'





share|improve this answer





















  • 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











  • @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











  • @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


















-1














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}'





share|improve this answer





















  • 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











  • @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











  • @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
















-1












-1








-1







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}'





share|improve this answer















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}'






share|improve this answer














share|improve this answer



share|improve this answer








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











  • 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
















  • 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











  • @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











  • @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




















draft saved

draft discarded




















































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.




draft saved


draft discarded














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





















































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







Popular posts from this blog

Plaza Victoria

In PowerPoint, is there a keyboard shortcut for bulleted / numbered list?

How to put 3 figures in Latex with 2 figures side by side and 1 below these side by side images but in...