Find duplicate String inside a text with middle near each other
Clash Royale CLAN TAG#URR8PPP
up vote
2
down vote
favorite
I need to find a string of 13 character length in a text file that has a duplicate close to it.
It referencing to the mutation 13 of the genomes.
For example:
ACGAATTGCAGCCACAGTACGAATCGCAGCC.
It starts with ACGAATTGCAGCC and ends with it, but in between are random chars of unknown length.
What I've come up so far is:
grep -Eo '((.)13).1,1001'
I have to find it in this
GTACCATAACTAACAACCTGAAAAGTCACAAAAACATATACAATAAAAGAACTAGATTTCGCATAGGATATATATTAATAAAGTGAACAAAAAAAAAATAACAACAACAACAACGAATGAAGAAAGGAAAAGGAATGATAAAAAAACGAGTAATAATTGAAAACAATTATAAAGTAAGAAAACCGCAACGGCCCAAGTAAGCAAAGCAAGGATAGGAAATTGATCGACACAACTCCATAAAATTTACAACTAGTACTCAGAAAAAATAACTAAGCTATATCCATATCTACTCTAAAAAAGAAAAGGAATAACGGAACACCCACAAAGAAACTCAATTAGCAAAAACCACAGATAATACAAACCAGAGAAGACCACATAAAAAAATGAACGAGTTACCCTTCAAATTAAAATAAATCTACCAGTAAGCATAAAAACAACAAAGTTACAAAACCAAAGACCAAAAGTAGAAATCAGAACAAGGGACATAAACGTTCACCAAATGAATGAAACAACACAATTTAGAAACAAAAAAGAGGAATAAAAAGCCAGAACAGGAGTACGAACATAATTAATTATGAAAGTGACCTACAAATAAGAAGGAAACACAAACAGAAAACAACTAACCACAAAAAAGACATAATAGTAAACAAAAAAAAAAAACTTACTCATACGAGGACTAATAAAAGATTCAAAACAATACAATTGACGAAAACTCAACGAGGAAAGCTAGAAAACCACCAGAGAAACTCAAAACACAAATAGAGATAAAAAAAAAAACCATAAAGAAAAATTCTTACATCGTCACAGCCAAGGAAAAAAAGAAATCGTTAAAATGGAACGCAGTCGAACACAAAAAGACAACACAGAACAAAAAAGGCAAACAGCGTAGAAACAAATACACTCGCGTAGCAAAGGGGCGGCGTCACGCTTGAAACATAAAAATAACCACTGTATATCACGACAATCAACAAAGTCTACATCAAGAAAATCAAAAAAATAC
grep scripting bioinformatics
add a comment |
up vote
2
down vote
favorite
I need to find a string of 13 character length in a text file that has a duplicate close to it.
It referencing to the mutation 13 of the genomes.
For example:
ACGAATTGCAGCCACAGTACGAATCGCAGCC.
It starts with ACGAATTGCAGCC and ends with it, but in between are random chars of unknown length.
What I've come up so far is:
grep -Eo '((.)13).1,1001'
I have to find it in this
GTACCATAACTAACAACCTGAAAAGTCACAAAAACATATACAATAAAAGAACTAGATTTCGCATAGGATATATATTAATAAAGTGAACAAAAAAAAAATAACAACAACAACAACGAATGAAGAAAGGAAAAGGAATGATAAAAAAACGAGTAATAATTGAAAACAATTATAAAGTAAGAAAACCGCAACGGCCCAAGTAAGCAAAGCAAGGATAGGAAATTGATCGACACAACTCCATAAAATTTACAACTAGTACTCAGAAAAAATAACTAAGCTATATCCATATCTACTCTAAAAAAGAAAAGGAATAACGGAACACCCACAAAGAAACTCAATTAGCAAAAACCACAGATAATACAAACCAGAGAAGACCACATAAAAAAATGAACGAGTTACCCTTCAAATTAAAATAAATCTACCAGTAAGCATAAAAACAACAAAGTTACAAAACCAAAGACCAAAAGTAGAAATCAGAACAAGGGACATAAACGTTCACCAAATGAATGAAACAACACAATTTAGAAACAAAAAAGAGGAATAAAAAGCCAGAACAGGAGTACGAACATAATTAATTATGAAAGTGACCTACAAATAAGAAGGAAACACAAACAGAAAACAACTAACCACAAAAAAGACATAATAGTAAACAAAAAAAAAAAACTTACTCATACGAGGACTAATAAAAGATTCAAAACAATACAATTGACGAAAACTCAACGAGGAAAGCTAGAAAACCACCAGAGAAACTCAAAACACAAATAGAGATAAAAAAAAAAACCATAAAGAAAAATTCTTACATCGTCACAGCCAAGGAAAAAAAGAAATCGTTAAAATGGAACGCAGTCGAACACAAAAAGACAACACAGAACAAAAAAGGCAAACAGCGTAGAAACAAATACACTCGCGTAGCAAAGGGGCGGCGTCACGCTTGAAACATAAAAATAACCACTGTATATCACGACAATCAACAAAGTCTACATCAAGAAAATCAAAAAAATAC
grep scripting bioinformatics
add a comment |
up vote
2
down vote
favorite
up vote
2
down vote
favorite
I need to find a string of 13 character length in a text file that has a duplicate close to it.
It referencing to the mutation 13 of the genomes.
For example:
ACGAATTGCAGCCACAGTACGAATCGCAGCC.
It starts with ACGAATTGCAGCC and ends with it, but in between are random chars of unknown length.
What I've come up so far is:
grep -Eo '((.)13).1,1001'
I have to find it in this
GTACCATAACTAACAACCTGAAAAGTCACAAAAACATATACAATAAAAGAACTAGATTTCGCATAGGATATATATTAATAAAGTGAACAAAAAAAAAATAACAACAACAACAACGAATGAAGAAAGGAAAAGGAATGATAAAAAAACGAGTAATAATTGAAAACAATTATAAAGTAAGAAAACCGCAACGGCCCAAGTAAGCAAAGCAAGGATAGGAAATTGATCGACACAACTCCATAAAATTTACAACTAGTACTCAGAAAAAATAACTAAGCTATATCCATATCTACTCTAAAAAAGAAAAGGAATAACGGAACACCCACAAAGAAACTCAATTAGCAAAAACCACAGATAATACAAACCAGAGAAGACCACATAAAAAAATGAACGAGTTACCCTTCAAATTAAAATAAATCTACCAGTAAGCATAAAAACAACAAAGTTACAAAACCAAAGACCAAAAGTAGAAATCAGAACAAGGGACATAAACGTTCACCAAATGAATGAAACAACACAATTTAGAAACAAAAAAGAGGAATAAAAAGCCAGAACAGGAGTACGAACATAATTAATTATGAAAGTGACCTACAAATAAGAAGGAAACACAAACAGAAAACAACTAACCACAAAAAAGACATAATAGTAAACAAAAAAAAAAAACTTACTCATACGAGGACTAATAAAAGATTCAAAACAATACAATTGACGAAAACTCAACGAGGAAAGCTAGAAAACCACCAGAGAAACTCAAAACACAAATAGAGATAAAAAAAAAAACCATAAAGAAAAATTCTTACATCGTCACAGCCAAGGAAAAAAAGAAATCGTTAAAATGGAACGCAGTCGAACACAAAAAGACAACACAGAACAAAAAAGGCAAACAGCGTAGAAACAAATACACTCGCGTAGCAAAGGGGCGGCGTCACGCTTGAAACATAAAAATAACCACTGTATATCACGACAATCAACAAAGTCTACATCAAGAAAATCAAAAAAATAC
grep scripting bioinformatics
I need to find a string of 13 character length in a text file that has a duplicate close to it.
It referencing to the mutation 13 of the genomes.
For example:
ACGAATTGCAGCCACAGTACGAATCGCAGCC.
It starts with ACGAATTGCAGCC and ends with it, but in between are random chars of unknown length.
What I've come up so far is:
grep -Eo '((.)13).1,1001'
I have to find it in this
GTACCATAACTAACAACCTGAAAAGTCACAAAAACATATACAATAAAAGAACTAGATTTCGCATAGGATATATATTAATAAAGTGAACAAAAAAAAAATAACAACAACAACAACGAATGAAGAAAGGAAAAGGAATGATAAAAAAACGAGTAATAATTGAAAACAATTATAAAGTAAGAAAACCGCAACGGCCCAAGTAAGCAAAGCAAGGATAGGAAATTGATCGACACAACTCCATAAAATTTACAACTAGTACTCAGAAAAAATAACTAAGCTATATCCATATCTACTCTAAAAAAGAAAAGGAATAACGGAACACCCACAAAGAAACTCAATTAGCAAAAACCACAGATAATACAAACCAGAGAAGACCACATAAAAAAATGAACGAGTTACCCTTCAAATTAAAATAAATCTACCAGTAAGCATAAAAACAACAAAGTTACAAAACCAAAGACCAAAAGTAGAAATCAGAACAAGGGACATAAACGTTCACCAAATGAATGAAACAACACAATTTAGAAACAAAAAAGAGGAATAAAAAGCCAGAACAGGAGTACGAACATAATTAATTATGAAAGTGACCTACAAATAAGAAGGAAACACAAACAGAAAACAACTAACCACAAAAAAGACATAATAGTAAACAAAAAAAAAAAACTTACTCATACGAGGACTAATAAAAGATTCAAAACAATACAATTGACGAAAACTCAACGAGGAAAGCTAGAAAACCACCAGAGAAACTCAAAACACAAATAGAGATAAAAAAAAAAACCATAAAGAAAAATTCTTACATCGTCACAGCCAAGGAAAAAAAGAAATCGTTAAAATGGAACGCAGTCGAACACAAAAAGACAACACAGAACAAAAAAGGCAAACAGCGTAGAAACAAATACACTCGCGTAGCAAAGGGGCGGCGTCACGCTTGAAACATAAAAATAACCACTGTATATCACGACAATCAACAAAGTCTACATCAAGAAAATCAAAAAAATAC
grep scripting bioinformatics
grep scripting bioinformatics
edited Dec 1 at 21:18
fra-san
1,110214
1,110214
asked Nov 30 at 23:21
Jan Villapaz
123
123
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
up vote
3
down vote
You were quite close, the problem was the 100, too narrow! You may want to consider using Perl PCRE as opposed to Posix Extended. The performance difference is quite noticeable.
grep -Po '((.)13).1,1000?1' genom
AACAAAAAAAAAATAACAACAACAACAACGAATGAAGAAAGGAAAAGGAATGATAAAAAAACGAGTAATAATTGAAAACAATTATAAAGTAAGAAAACCGCAACGGCCCAAGTAAGCAAAGCAAGGATAGGAAATTGATCGACACAACTCCATAAAATTTACAACTAGTACTCAGAAAAAATAACTAAGCTATATCCATATCTACTCTAAAAAAGAAAAGGAATAACGGAACACCCACAAAGAAACTCAATTAGCAAAAACCACAGATAATACAAACCAGAGAAGACCACATAAAAAAATGAACGAGTTACCCTTCAAATTAAAATAAATCTACCAGTAAGCATAAAAACAACAAAGTTACAAAACCAAAGACCAAAAGTAGAAATCAGAACAAGGGACATAAACGTTCACCAAATGAATGAAACAACACAATTTAGAAACAAAAAAGAGGAATAAAAAGCCAGAACAGGAGTACGAACATAATTAATTATGAAAGTGACCTACAAATAAGAAGGAAACACAAACAGAAAACAACTAACCACAAAAAAGACATAATAGTAAACAAAAAAAAAA
Timing comparison on my machine:
Posix: (-E) 0m4.816s
Perl: (-P) 0m0.011s
4
You may want to make the repetition non greedy.1,1000?
, even if this may not matter in this exact case, you only want to include up to the nearest repetition. That horrible slowness with-E
looks like a bug (LC_ALL=C
will cut it to 1/3, but still orders of magnitude slower than-P
).
– mosvy
Dec 1 at 0:55
Good suggestion! Thanks - will incorporate :)
– tink
Dec 1 at 1:23
P.S.: @mosvy - nice catch w/ the LC_ALL ... that brings the runtime down to0m0.714s
... almost sevenfold faster. Still a good tick slower than-P
. :)
– tink
Dec 1 at 3:23
Note that POSIX EREs don't have back references. (POSIX BREs do). The OP is probably using an implementation that offers it as an extension.
– Stéphane Chazelas
Dec 1 at 22:04
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
3
down vote
You were quite close, the problem was the 100, too narrow! You may want to consider using Perl PCRE as opposed to Posix Extended. The performance difference is quite noticeable.
grep -Po '((.)13).1,1000?1' genom
AACAAAAAAAAAATAACAACAACAACAACGAATGAAGAAAGGAAAAGGAATGATAAAAAAACGAGTAATAATTGAAAACAATTATAAAGTAAGAAAACCGCAACGGCCCAAGTAAGCAAAGCAAGGATAGGAAATTGATCGACACAACTCCATAAAATTTACAACTAGTACTCAGAAAAAATAACTAAGCTATATCCATATCTACTCTAAAAAAGAAAAGGAATAACGGAACACCCACAAAGAAACTCAATTAGCAAAAACCACAGATAATACAAACCAGAGAAGACCACATAAAAAAATGAACGAGTTACCCTTCAAATTAAAATAAATCTACCAGTAAGCATAAAAACAACAAAGTTACAAAACCAAAGACCAAAAGTAGAAATCAGAACAAGGGACATAAACGTTCACCAAATGAATGAAACAACACAATTTAGAAACAAAAAAGAGGAATAAAAAGCCAGAACAGGAGTACGAACATAATTAATTATGAAAGTGACCTACAAATAAGAAGGAAACACAAACAGAAAACAACTAACCACAAAAAAGACATAATAGTAAACAAAAAAAAAA
Timing comparison on my machine:
Posix: (-E) 0m4.816s
Perl: (-P) 0m0.011s
4
You may want to make the repetition non greedy.1,1000?
, even if this may not matter in this exact case, you only want to include up to the nearest repetition. That horrible slowness with-E
looks like a bug (LC_ALL=C
will cut it to 1/3, but still orders of magnitude slower than-P
).
– mosvy
Dec 1 at 0:55
Good suggestion! Thanks - will incorporate :)
– tink
Dec 1 at 1:23
P.S.: @mosvy - nice catch w/ the LC_ALL ... that brings the runtime down to0m0.714s
... almost sevenfold faster. Still a good tick slower than-P
. :)
– tink
Dec 1 at 3:23
Note that POSIX EREs don't have back references. (POSIX BREs do). The OP is probably using an implementation that offers it as an extension.
– Stéphane Chazelas
Dec 1 at 22:04
add a comment |
up vote
3
down vote
You were quite close, the problem was the 100, too narrow! You may want to consider using Perl PCRE as opposed to Posix Extended. The performance difference is quite noticeable.
grep -Po '((.)13).1,1000?1' genom
AACAAAAAAAAAATAACAACAACAACAACGAATGAAGAAAGGAAAAGGAATGATAAAAAAACGAGTAATAATTGAAAACAATTATAAAGTAAGAAAACCGCAACGGCCCAAGTAAGCAAAGCAAGGATAGGAAATTGATCGACACAACTCCATAAAATTTACAACTAGTACTCAGAAAAAATAACTAAGCTATATCCATATCTACTCTAAAAAAGAAAAGGAATAACGGAACACCCACAAAGAAACTCAATTAGCAAAAACCACAGATAATACAAACCAGAGAAGACCACATAAAAAAATGAACGAGTTACCCTTCAAATTAAAATAAATCTACCAGTAAGCATAAAAACAACAAAGTTACAAAACCAAAGACCAAAAGTAGAAATCAGAACAAGGGACATAAACGTTCACCAAATGAATGAAACAACACAATTTAGAAACAAAAAAGAGGAATAAAAAGCCAGAACAGGAGTACGAACATAATTAATTATGAAAGTGACCTACAAATAAGAAGGAAACACAAACAGAAAACAACTAACCACAAAAAAGACATAATAGTAAACAAAAAAAAAA
Timing comparison on my machine:
Posix: (-E) 0m4.816s
Perl: (-P) 0m0.011s
4
You may want to make the repetition non greedy.1,1000?
, even if this may not matter in this exact case, you only want to include up to the nearest repetition. That horrible slowness with-E
looks like a bug (LC_ALL=C
will cut it to 1/3, but still orders of magnitude slower than-P
).
– mosvy
Dec 1 at 0:55
Good suggestion! Thanks - will incorporate :)
– tink
Dec 1 at 1:23
P.S.: @mosvy - nice catch w/ the LC_ALL ... that brings the runtime down to0m0.714s
... almost sevenfold faster. Still a good tick slower than-P
. :)
– tink
Dec 1 at 3:23
Note that POSIX EREs don't have back references. (POSIX BREs do). The OP is probably using an implementation that offers it as an extension.
– Stéphane Chazelas
Dec 1 at 22:04
add a comment |
up vote
3
down vote
up vote
3
down vote
You were quite close, the problem was the 100, too narrow! You may want to consider using Perl PCRE as opposed to Posix Extended. The performance difference is quite noticeable.
grep -Po '((.)13).1,1000?1' genom
AACAAAAAAAAAATAACAACAACAACAACGAATGAAGAAAGGAAAAGGAATGATAAAAAAACGAGTAATAATTGAAAACAATTATAAAGTAAGAAAACCGCAACGGCCCAAGTAAGCAAAGCAAGGATAGGAAATTGATCGACACAACTCCATAAAATTTACAACTAGTACTCAGAAAAAATAACTAAGCTATATCCATATCTACTCTAAAAAAGAAAAGGAATAACGGAACACCCACAAAGAAACTCAATTAGCAAAAACCACAGATAATACAAACCAGAGAAGACCACATAAAAAAATGAACGAGTTACCCTTCAAATTAAAATAAATCTACCAGTAAGCATAAAAACAACAAAGTTACAAAACCAAAGACCAAAAGTAGAAATCAGAACAAGGGACATAAACGTTCACCAAATGAATGAAACAACACAATTTAGAAACAAAAAAGAGGAATAAAAAGCCAGAACAGGAGTACGAACATAATTAATTATGAAAGTGACCTACAAATAAGAAGGAAACACAAACAGAAAACAACTAACCACAAAAAAGACATAATAGTAAACAAAAAAAAAA
Timing comparison on my machine:
Posix: (-E) 0m4.816s
Perl: (-P) 0m0.011s
You were quite close, the problem was the 100, too narrow! You may want to consider using Perl PCRE as opposed to Posix Extended. The performance difference is quite noticeable.
grep -Po '((.)13).1,1000?1' genom
AACAAAAAAAAAATAACAACAACAACAACGAATGAAGAAAGGAAAAGGAATGATAAAAAAACGAGTAATAATTGAAAACAATTATAAAGTAAGAAAACCGCAACGGCCCAAGTAAGCAAAGCAAGGATAGGAAATTGATCGACACAACTCCATAAAATTTACAACTAGTACTCAGAAAAAATAACTAAGCTATATCCATATCTACTCTAAAAAAGAAAAGGAATAACGGAACACCCACAAAGAAACTCAATTAGCAAAAACCACAGATAATACAAACCAGAGAAGACCACATAAAAAAATGAACGAGTTACCCTTCAAATTAAAATAAATCTACCAGTAAGCATAAAAACAACAAAGTTACAAAACCAAAGACCAAAAGTAGAAATCAGAACAAGGGACATAAACGTTCACCAAATGAATGAAACAACACAATTTAGAAACAAAAAAGAGGAATAAAAAGCCAGAACAGGAGTACGAACATAATTAATTATGAAAGTGACCTACAAATAAGAAGGAAACACAAACAGAAAACAACTAACCACAAAAAAGACATAATAGTAAACAAAAAAAAAA
Timing comparison on my machine:
Posix: (-E) 0m4.816s
Perl: (-P) 0m0.011s
edited Dec 1 at 1:24
answered Dec 1 at 0:03
tink
4,07511218
4,07511218
4
You may want to make the repetition non greedy.1,1000?
, even if this may not matter in this exact case, you only want to include up to the nearest repetition. That horrible slowness with-E
looks like a bug (LC_ALL=C
will cut it to 1/3, but still orders of magnitude slower than-P
).
– mosvy
Dec 1 at 0:55
Good suggestion! Thanks - will incorporate :)
– tink
Dec 1 at 1:23
P.S.: @mosvy - nice catch w/ the LC_ALL ... that brings the runtime down to0m0.714s
... almost sevenfold faster. Still a good tick slower than-P
. :)
– tink
Dec 1 at 3:23
Note that POSIX EREs don't have back references. (POSIX BREs do). The OP is probably using an implementation that offers it as an extension.
– Stéphane Chazelas
Dec 1 at 22:04
add a comment |
4
You may want to make the repetition non greedy.1,1000?
, even if this may not matter in this exact case, you only want to include up to the nearest repetition. That horrible slowness with-E
looks like a bug (LC_ALL=C
will cut it to 1/3, but still orders of magnitude slower than-P
).
– mosvy
Dec 1 at 0:55
Good suggestion! Thanks - will incorporate :)
– tink
Dec 1 at 1:23
P.S.: @mosvy - nice catch w/ the LC_ALL ... that brings the runtime down to0m0.714s
... almost sevenfold faster. Still a good tick slower than-P
. :)
– tink
Dec 1 at 3:23
Note that POSIX EREs don't have back references. (POSIX BREs do). The OP is probably using an implementation that offers it as an extension.
– Stéphane Chazelas
Dec 1 at 22:04
4
4
You may want to make the repetition non greedy
.1,1000?
, even if this may not matter in this exact case, you only want to include up to the nearest repetition. That horrible slowness with -E
looks like a bug (LC_ALL=C
will cut it to 1/3, but still orders of magnitude slower than -P
).– mosvy
Dec 1 at 0:55
You may want to make the repetition non greedy
.1,1000?
, even if this may not matter in this exact case, you only want to include up to the nearest repetition. That horrible slowness with -E
looks like a bug (LC_ALL=C
will cut it to 1/3, but still orders of magnitude slower than -P
).– mosvy
Dec 1 at 0:55
Good suggestion! Thanks - will incorporate :)
– tink
Dec 1 at 1:23
Good suggestion! Thanks - will incorporate :)
– tink
Dec 1 at 1:23
P.S.: @mosvy - nice catch w/ the LC_ALL ... that brings the runtime down to
0m0.714s
... almost sevenfold faster. Still a good tick slower than -P
. :)– tink
Dec 1 at 3:23
P.S.: @mosvy - nice catch w/ the LC_ALL ... that brings the runtime down to
0m0.714s
... almost sevenfold faster. Still a good tick slower than -P
. :)– tink
Dec 1 at 3:23
Note that POSIX EREs don't have back references. (POSIX BREs do). The OP is probably using an implementation that offers it as an extension.
– Stéphane Chazelas
Dec 1 at 22:04
Note that POSIX EREs don't have back references. (POSIX BREs do). The OP is probably using an implementation that offers it as an extension.
– Stéphane Chazelas
Dec 1 at 22:04
add a comment |
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.
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%2funix.stackexchange.com%2fquestions%2f485274%2ffind-duplicate-string-inside-a-text-with-middle-near-each-other%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