Match ASCII codes in shell regex












1














I've trouble about matching ASCII codes in regex in my bash script.



My payload is : payload='#1243669, start 2018-12-17 16:32:50 CET'



My old regex is : regold='(#[^,]+),'
My new regex is : regnew='(#[^x2c]+)x2c'



When I do the test in shell, it confirms that new regex doesn't work, whereas it works on regex101.com :



root@test# payload='#1243669, start 2018-12-17 16:32:50 CET'
root@test# regold='(#[^,]+),'
root@test# regnew='(#[^x2c]+)x2c'
root@test# if [[ $payload =~ $regold ]]; then echo yes; fi
yes
root@test# if [[ $payload =~ $regnew ]]; then echo yes; fi


Edit:



Question partially answered by telling bash doesn't support PCRE expressions.
So I move my regex to this one :



root@test# regex=$'(x23[^x2c]+)x2c[[:space:]]start[[:space:]][[:digit:]]{4}x2d[[:digit:]]{2}x2d[[:digit:]]{2}[[:space:]]([^[:space:]]+)[[:space:]][^x2c]+x2c[^x2c]+x2c[[:space:]](captureme)'
root@test# pattern='Message #1243669, start 2018-12-17 16:32:50 CET, duration 20, captureme'


Again, my expression works great on regex101, sample here https://regex101.com/r/g4UsUN/1



Expression works to this point : ... [[:space:]][^x2c]+ ... but bash had some difficulties when I add the x2c



What's going on ?










share|improve this question
























  • Dont' be logged in as root, unless you want a broken operating system.
    – ctrl-alt-delor
    Dec 18 at 13:10
















1














I've trouble about matching ASCII codes in regex in my bash script.



My payload is : payload='#1243669, start 2018-12-17 16:32:50 CET'



My old regex is : regold='(#[^,]+),'
My new regex is : regnew='(#[^x2c]+)x2c'



When I do the test in shell, it confirms that new regex doesn't work, whereas it works on regex101.com :



root@test# payload='#1243669, start 2018-12-17 16:32:50 CET'
root@test# regold='(#[^,]+),'
root@test# regnew='(#[^x2c]+)x2c'
root@test# if [[ $payload =~ $regold ]]; then echo yes; fi
yes
root@test# if [[ $payload =~ $regnew ]]; then echo yes; fi


Edit:



Question partially answered by telling bash doesn't support PCRE expressions.
So I move my regex to this one :



root@test# regex=$'(x23[^x2c]+)x2c[[:space:]]start[[:space:]][[:digit:]]{4}x2d[[:digit:]]{2}x2d[[:digit:]]{2}[[:space:]]([^[:space:]]+)[[:space:]][^x2c]+x2c[^x2c]+x2c[[:space:]](captureme)'
root@test# pattern='Message #1243669, start 2018-12-17 16:32:50 CET, duration 20, captureme'


Again, my expression works great on regex101, sample here https://regex101.com/r/g4UsUN/1



Expression works to this point : ... [[:space:]][^x2c]+ ... but bash had some difficulties when I add the x2c



What's going on ?










share|improve this question
























  • Dont' be logged in as root, unless you want a broken operating system.
    – ctrl-alt-delor
    Dec 18 at 13:10














1












1








1







I've trouble about matching ASCII codes in regex in my bash script.



My payload is : payload='#1243669, start 2018-12-17 16:32:50 CET'



My old regex is : regold='(#[^,]+),'
My new regex is : regnew='(#[^x2c]+)x2c'



When I do the test in shell, it confirms that new regex doesn't work, whereas it works on regex101.com :



root@test# payload='#1243669, start 2018-12-17 16:32:50 CET'
root@test# regold='(#[^,]+),'
root@test# regnew='(#[^x2c]+)x2c'
root@test# if [[ $payload =~ $regold ]]; then echo yes; fi
yes
root@test# if [[ $payload =~ $regnew ]]; then echo yes; fi


Edit:



Question partially answered by telling bash doesn't support PCRE expressions.
So I move my regex to this one :



root@test# regex=$'(x23[^x2c]+)x2c[[:space:]]start[[:space:]][[:digit:]]{4}x2d[[:digit:]]{2}x2d[[:digit:]]{2}[[:space:]]([^[:space:]]+)[[:space:]][^x2c]+x2c[^x2c]+x2c[[:space:]](captureme)'
root@test# pattern='Message #1243669, start 2018-12-17 16:32:50 CET, duration 20, captureme'


Again, my expression works great on regex101, sample here https://regex101.com/r/g4UsUN/1



Expression works to this point : ... [[:space:]][^x2c]+ ... but bash had some difficulties when I add the x2c



What's going on ?










share|improve this question















I've trouble about matching ASCII codes in regex in my bash script.



My payload is : payload='#1243669, start 2018-12-17 16:32:50 CET'



My old regex is : regold='(#[^,]+),'
My new regex is : regnew='(#[^x2c]+)x2c'



When I do the test in shell, it confirms that new regex doesn't work, whereas it works on regex101.com :



root@test# payload='#1243669, start 2018-12-17 16:32:50 CET'
root@test# regold='(#[^,]+),'
root@test# regnew='(#[^x2c]+)x2c'
root@test# if [[ $payload =~ $regold ]]; then echo yes; fi
yes
root@test# if [[ $payload =~ $regnew ]]; then echo yes; fi


Edit:



Question partially answered by telling bash doesn't support PCRE expressions.
So I move my regex to this one :



root@test# regex=$'(x23[^x2c]+)x2c[[:space:]]start[[:space:]][[:digit:]]{4}x2d[[:digit:]]{2}x2d[[:digit:]]{2}[[:space:]]([^[:space:]]+)[[:space:]][^x2c]+x2c[^x2c]+x2c[[:space:]](captureme)'
root@test# pattern='Message #1243669, start 2018-12-17 16:32:50 CET, duration 20, captureme'


Again, my expression works great on regex101, sample here https://regex101.com/r/g4UsUN/1



Expression works to this point : ... [[:space:]][^x2c]+ ... but bash had some difficulties when I add the x2c



What's going on ?







bash regular-expression






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Dec 18 at 9:34

























asked Dec 17 at 16:06









CLB

112




112












  • Dont' be logged in as root, unless you want a broken operating system.
    – ctrl-alt-delor
    Dec 18 at 13:10


















  • Dont' be logged in as root, unless you want a broken operating system.
    – ctrl-alt-delor
    Dec 18 at 13:10
















Dont' be logged in as root, unless you want a broken operating system.
– ctrl-alt-delor
Dec 18 at 13:10




Dont' be logged in as root, unless you want a broken operating system.
– ctrl-alt-delor
Dec 18 at 13:10










1 Answer
1






active

oldest

votes


















1














In bash, you may insert the literal character that the hexadecimal codes are the codes for with $'xHH'. bash will not recognise them in a string otherwise, and the regular expression [^x2c] would match any character that is not a , x, 2, or c. The regex101.com site that you tested your expression in may have used a PCRE regular expression engine. This is not what bash uses, it uses POSIX extended regular expressions (which does not seem to be supported by that web site). This also means that bash does not support other regular expression syntax that you would otherwise use in a PCRE, such as d for digits, s for space characters, or look-aheads or similar things.



POSIX regular expression (both basic and extended) should be documented on your system in the re_format(7) manual (man 7 re_format), and are also described in detail by the POSIX standard.



Therefore, use



regnew=$'#[^x2c]+x2c'


(the parenthesis seemed unused, so I removed it). Since bash would expand the escape-sequences before assigning the string to the variable, and since they may expand to characters that may have special meaning in regular expressions, care must be taken to escaped the escape-sequences to match literal values. One may want to prefix x2e (a dot character) with \ (\x2e) when a literal dot is to be matched, for example.



From the bash manual:




Words of the form $'string' are treated specially. The word expands to
string, with backslash-escaped characters replaced as specified by the
ANSI C standard. Backslash escape sequences, if present, are decoded
as follows:



[...]



xHH



the eight-bit character whose value is the hexadecimal
value HH (one or two hex digits)




Note that using $'...' would make the shell also replace any other escape sequences that it recognises.






share|improve this answer























  • Hello, simple like that :) Now it works : root@test# regnew=$'(x23[^x2c]+)x2csstart' root@test# if [[ $pattern =~ $regnew ]]; then echo yes; fi yes root@test# echo ${BASH_REMATCH[1]} #1243669 Thank you so much!
    – CLB
    Dec 17 at 16:24












  • Might be worth noting that since the escapes are expanded before passing to the regexp engine, a $'x2e' (. in ASCII) would still be the . operator and $'[xx5d] would be [x]]. But [[ x = $'.' ]] would not match as that . is quoted to bash (since 3.2) replaces it with . before calling the regex engine.
    – Stéphane Chazelas
    Dec 18 at 9:49












  • @StéphaneChazelas Thanks, I overlooked that.
    – Kusalananda
    Dec 18 at 9:50










  • x2c expands to , not . so is OK here, I was thinking of characters that are regexp operators or special within [...] to watch out for.
    – Stéphane Chazelas
    Dec 18 at 10:18










  • Note that xHH only works for single-byte characters. For multi-byte characters, you can use xHHxHH... to encode each byte of the character, or use uXXXX or UXXXXXXXX to use the unicode code point of the character.
    – Stéphane Chazelas
    Dec 18 at 10:35











Your Answer








StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
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: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
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%2funix.stackexchange.com%2fquestions%2f489515%2fmatch-ascii-codes-in-shell-regex%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









1














In bash, you may insert the literal character that the hexadecimal codes are the codes for with $'xHH'. bash will not recognise them in a string otherwise, and the regular expression [^x2c] would match any character that is not a , x, 2, or c. The regex101.com site that you tested your expression in may have used a PCRE regular expression engine. This is not what bash uses, it uses POSIX extended regular expressions (which does not seem to be supported by that web site). This also means that bash does not support other regular expression syntax that you would otherwise use in a PCRE, such as d for digits, s for space characters, or look-aheads or similar things.



POSIX regular expression (both basic and extended) should be documented on your system in the re_format(7) manual (man 7 re_format), and are also described in detail by the POSIX standard.



Therefore, use



regnew=$'#[^x2c]+x2c'


(the parenthesis seemed unused, so I removed it). Since bash would expand the escape-sequences before assigning the string to the variable, and since they may expand to characters that may have special meaning in regular expressions, care must be taken to escaped the escape-sequences to match literal values. One may want to prefix x2e (a dot character) with \ (\x2e) when a literal dot is to be matched, for example.



From the bash manual:




Words of the form $'string' are treated specially. The word expands to
string, with backslash-escaped characters replaced as specified by the
ANSI C standard. Backslash escape sequences, if present, are decoded
as follows:



[...]



xHH



the eight-bit character whose value is the hexadecimal
value HH (one or two hex digits)




Note that using $'...' would make the shell also replace any other escape sequences that it recognises.






share|improve this answer























  • Hello, simple like that :) Now it works : root@test# regnew=$'(x23[^x2c]+)x2csstart' root@test# if [[ $pattern =~ $regnew ]]; then echo yes; fi yes root@test# echo ${BASH_REMATCH[1]} #1243669 Thank you so much!
    – CLB
    Dec 17 at 16:24












  • Might be worth noting that since the escapes are expanded before passing to the regexp engine, a $'x2e' (. in ASCII) would still be the . operator and $'[xx5d] would be [x]]. But [[ x = $'.' ]] would not match as that . is quoted to bash (since 3.2) replaces it with . before calling the regex engine.
    – Stéphane Chazelas
    Dec 18 at 9:49












  • @StéphaneChazelas Thanks, I overlooked that.
    – Kusalananda
    Dec 18 at 9:50










  • x2c expands to , not . so is OK here, I was thinking of characters that are regexp operators or special within [...] to watch out for.
    – Stéphane Chazelas
    Dec 18 at 10:18










  • Note that xHH only works for single-byte characters. For multi-byte characters, you can use xHHxHH... to encode each byte of the character, or use uXXXX or UXXXXXXXX to use the unicode code point of the character.
    – Stéphane Chazelas
    Dec 18 at 10:35
















1














In bash, you may insert the literal character that the hexadecimal codes are the codes for with $'xHH'. bash will not recognise them in a string otherwise, and the regular expression [^x2c] would match any character that is not a , x, 2, or c. The regex101.com site that you tested your expression in may have used a PCRE regular expression engine. This is not what bash uses, it uses POSIX extended regular expressions (which does not seem to be supported by that web site). This also means that bash does not support other regular expression syntax that you would otherwise use in a PCRE, such as d for digits, s for space characters, or look-aheads or similar things.



POSIX regular expression (both basic and extended) should be documented on your system in the re_format(7) manual (man 7 re_format), and are also described in detail by the POSIX standard.



Therefore, use



regnew=$'#[^x2c]+x2c'


(the parenthesis seemed unused, so I removed it). Since bash would expand the escape-sequences before assigning the string to the variable, and since they may expand to characters that may have special meaning in regular expressions, care must be taken to escaped the escape-sequences to match literal values. One may want to prefix x2e (a dot character) with \ (\x2e) when a literal dot is to be matched, for example.



From the bash manual:




Words of the form $'string' are treated specially. The word expands to
string, with backslash-escaped characters replaced as specified by the
ANSI C standard. Backslash escape sequences, if present, are decoded
as follows:



[...]



xHH



the eight-bit character whose value is the hexadecimal
value HH (one or two hex digits)




Note that using $'...' would make the shell also replace any other escape sequences that it recognises.






share|improve this answer























  • Hello, simple like that :) Now it works : root@test# regnew=$'(x23[^x2c]+)x2csstart' root@test# if [[ $pattern =~ $regnew ]]; then echo yes; fi yes root@test# echo ${BASH_REMATCH[1]} #1243669 Thank you so much!
    – CLB
    Dec 17 at 16:24












  • Might be worth noting that since the escapes are expanded before passing to the regexp engine, a $'x2e' (. in ASCII) would still be the . operator and $'[xx5d] would be [x]]. But [[ x = $'.' ]] would not match as that . is quoted to bash (since 3.2) replaces it with . before calling the regex engine.
    – Stéphane Chazelas
    Dec 18 at 9:49












  • @StéphaneChazelas Thanks, I overlooked that.
    – Kusalananda
    Dec 18 at 9:50










  • x2c expands to , not . so is OK here, I was thinking of characters that are regexp operators or special within [...] to watch out for.
    – Stéphane Chazelas
    Dec 18 at 10:18










  • Note that xHH only works for single-byte characters. For multi-byte characters, you can use xHHxHH... to encode each byte of the character, or use uXXXX or UXXXXXXXX to use the unicode code point of the character.
    – Stéphane Chazelas
    Dec 18 at 10:35














1












1








1






In bash, you may insert the literal character that the hexadecimal codes are the codes for with $'xHH'. bash will not recognise them in a string otherwise, and the regular expression [^x2c] would match any character that is not a , x, 2, or c. The regex101.com site that you tested your expression in may have used a PCRE regular expression engine. This is not what bash uses, it uses POSIX extended regular expressions (which does not seem to be supported by that web site). This also means that bash does not support other regular expression syntax that you would otherwise use in a PCRE, such as d for digits, s for space characters, or look-aheads or similar things.



POSIX regular expression (both basic and extended) should be documented on your system in the re_format(7) manual (man 7 re_format), and are also described in detail by the POSIX standard.



Therefore, use



regnew=$'#[^x2c]+x2c'


(the parenthesis seemed unused, so I removed it). Since bash would expand the escape-sequences before assigning the string to the variable, and since they may expand to characters that may have special meaning in regular expressions, care must be taken to escaped the escape-sequences to match literal values. One may want to prefix x2e (a dot character) with \ (\x2e) when a literal dot is to be matched, for example.



From the bash manual:




Words of the form $'string' are treated specially. The word expands to
string, with backslash-escaped characters replaced as specified by the
ANSI C standard. Backslash escape sequences, if present, are decoded
as follows:



[...]



xHH



the eight-bit character whose value is the hexadecimal
value HH (one or two hex digits)




Note that using $'...' would make the shell also replace any other escape sequences that it recognises.






share|improve this answer














In bash, you may insert the literal character that the hexadecimal codes are the codes for with $'xHH'. bash will not recognise them in a string otherwise, and the regular expression [^x2c] would match any character that is not a , x, 2, or c. The regex101.com site that you tested your expression in may have used a PCRE regular expression engine. This is not what bash uses, it uses POSIX extended regular expressions (which does not seem to be supported by that web site). This also means that bash does not support other regular expression syntax that you would otherwise use in a PCRE, such as d for digits, s for space characters, or look-aheads or similar things.



POSIX regular expression (both basic and extended) should be documented on your system in the re_format(7) manual (man 7 re_format), and are also described in detail by the POSIX standard.



Therefore, use



regnew=$'#[^x2c]+x2c'


(the parenthesis seemed unused, so I removed it). Since bash would expand the escape-sequences before assigning the string to the variable, and since they may expand to characters that may have special meaning in regular expressions, care must be taken to escaped the escape-sequences to match literal values. One may want to prefix x2e (a dot character) with \ (\x2e) when a literal dot is to be matched, for example.



From the bash manual:




Words of the form $'string' are treated specially. The word expands to
string, with backslash-escaped characters replaced as specified by the
ANSI C standard. Backslash escape sequences, if present, are decoded
as follows:



[...]



xHH



the eight-bit character whose value is the hexadecimal
value HH (one or two hex digits)




Note that using $'...' would make the shell also replace any other escape sequences that it recognises.







share|improve this answer














share|improve this answer



share|improve this answer








edited Dec 18 at 12:12

























answered Dec 17 at 16:16









Kusalananda

121k16229372




121k16229372












  • Hello, simple like that :) Now it works : root@test# regnew=$'(x23[^x2c]+)x2csstart' root@test# if [[ $pattern =~ $regnew ]]; then echo yes; fi yes root@test# echo ${BASH_REMATCH[1]} #1243669 Thank you so much!
    – CLB
    Dec 17 at 16:24












  • Might be worth noting that since the escapes are expanded before passing to the regexp engine, a $'x2e' (. in ASCII) would still be the . operator and $'[xx5d] would be [x]]. But [[ x = $'.' ]] would not match as that . is quoted to bash (since 3.2) replaces it with . before calling the regex engine.
    – Stéphane Chazelas
    Dec 18 at 9:49












  • @StéphaneChazelas Thanks, I overlooked that.
    – Kusalananda
    Dec 18 at 9:50










  • x2c expands to , not . so is OK here, I was thinking of characters that are regexp operators or special within [...] to watch out for.
    – Stéphane Chazelas
    Dec 18 at 10:18










  • Note that xHH only works for single-byte characters. For multi-byte characters, you can use xHHxHH... to encode each byte of the character, or use uXXXX or UXXXXXXXX to use the unicode code point of the character.
    – Stéphane Chazelas
    Dec 18 at 10:35


















  • Hello, simple like that :) Now it works : root@test# regnew=$'(x23[^x2c]+)x2csstart' root@test# if [[ $pattern =~ $regnew ]]; then echo yes; fi yes root@test# echo ${BASH_REMATCH[1]} #1243669 Thank you so much!
    – CLB
    Dec 17 at 16:24












  • Might be worth noting that since the escapes are expanded before passing to the regexp engine, a $'x2e' (. in ASCII) would still be the . operator and $'[xx5d] would be [x]]. But [[ x = $'.' ]] would not match as that . is quoted to bash (since 3.2) replaces it with . before calling the regex engine.
    – Stéphane Chazelas
    Dec 18 at 9:49












  • @StéphaneChazelas Thanks, I overlooked that.
    – Kusalananda
    Dec 18 at 9:50










  • x2c expands to , not . so is OK here, I was thinking of characters that are regexp operators or special within [...] to watch out for.
    – Stéphane Chazelas
    Dec 18 at 10:18










  • Note that xHH only works for single-byte characters. For multi-byte characters, you can use xHHxHH... to encode each byte of the character, or use uXXXX or UXXXXXXXX to use the unicode code point of the character.
    – Stéphane Chazelas
    Dec 18 at 10:35
















Hello, simple like that :) Now it works : root@test# regnew=$'(x23[^x2c]+)x2csstart' root@test# if [[ $pattern =~ $regnew ]]; then echo yes; fi yes root@test# echo ${BASH_REMATCH[1]} #1243669 Thank you so much!
– CLB
Dec 17 at 16:24






Hello, simple like that :) Now it works : root@test# regnew=$'(x23[^x2c]+)x2csstart' root@test# if [[ $pattern =~ $regnew ]]; then echo yes; fi yes root@test# echo ${BASH_REMATCH[1]} #1243669 Thank you so much!
– CLB
Dec 17 at 16:24














Might be worth noting that since the escapes are expanded before passing to the regexp engine, a $'x2e' (. in ASCII) would still be the . operator and $'[xx5d] would be [x]]. But [[ x = $'.' ]] would not match as that . is quoted to bash (since 3.2) replaces it with . before calling the regex engine.
– Stéphane Chazelas
Dec 18 at 9:49






Might be worth noting that since the escapes are expanded before passing to the regexp engine, a $'x2e' (. in ASCII) would still be the . operator and $'[xx5d] would be [x]]. But [[ x = $'.' ]] would not match as that . is quoted to bash (since 3.2) replaces it with . before calling the regex engine.
– Stéphane Chazelas
Dec 18 at 9:49














@StéphaneChazelas Thanks, I overlooked that.
– Kusalananda
Dec 18 at 9:50




@StéphaneChazelas Thanks, I overlooked that.
– Kusalananda
Dec 18 at 9:50












x2c expands to , not . so is OK here, I was thinking of characters that are regexp operators or special within [...] to watch out for.
– Stéphane Chazelas
Dec 18 at 10:18




x2c expands to , not . so is OK here, I was thinking of characters that are regexp operators or special within [...] to watch out for.
– Stéphane Chazelas
Dec 18 at 10:18












Note that xHH only works for single-byte characters. For multi-byte characters, you can use xHHxHH... to encode each byte of the character, or use uXXXX or UXXXXXXXX to use the unicode code point of the character.
– Stéphane Chazelas
Dec 18 at 10:35




Note that xHH only works for single-byte characters. For multi-byte characters, you can use xHHxHH... to encode each byte of the character, or use uXXXX or UXXXXXXXX to use the unicode code point of the character.
– Stéphane Chazelas
Dec 18 at 10:35


















draft saved

draft discarded




















































Thanks for contributing an answer to Unix & Linux Stack Exchange!


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





Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


Please pay close attention to the following guidance:


  • 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%2funix.stackexchange.com%2fquestions%2f489515%2fmatch-ascii-codes-in-shell-regex%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

Morgemoulin

Scott Moir

Souastre