You have a problem, so you decide to use a regex. Now you have two problems.
The first language I was fluent in was Perl so PCRE is second nature to me. But then everyone decided they wanted their own regex dialects. And now there's a PCRE2? Why 2? Stay with 1, you're good together. What about the kids?
Your brains and mine work very very differently. Kudos to diversity.
It's great that you cherish that. Love that for you.
Which one of these commands is correct?
A:
sed -E 's/\b(\w+)\b/echo \1 | rev/g' file.txt
B:sed 's/\b\w+\b/echo & | rev/ge' file.txt
C:sed -E 's/(\w+)/$(echo \1 | rev)/g' file.txt
D:sed 's/\([a-zA-Z]\+\)/\n&\n/g; s/\n\(.*\)\n/\3\2\1/g; s/\n//g' file.txt
Chatty was so kind to transcribe. May contain errors.
Chatty claims the correct answer to be:
Spoiler
B
I tried it my self and I conclude:
Spoiler
none is correct.
Thought so lol
A: didn't even try what by does B: Single quotes prevent execution C: there is no way to execute commands afaik so this won't work either D: that syntax is just wrong afaik
sed can execute commands with the /e option
Google Lens says:
Which one of these commands is correct?
A sed -e 's/\b(\w+)\b/echo \1 | rev/g' file.txt
B: sed 's/b\w+\b/echo & | rev/ge' file.txt
Csed -e 's/(\w+)/$(echo \1 | rev)/g' file.txt
D: sed 's/([a-zA-Z]\+\)/\n&\n/g; s/\n\(\)\(.*\)\(\)\n/\3\2\1/g; s/\n//g' file.tx
It's interesting that Google doesn't even get all the text. I had to manually extend the selection and that still misses the "t" on the end of answer D, munches C and more alarmingly changes the case for "-E".
OCR of fonts used to be a solved problem, but now we have AI, which can sort of do it sometimes
Why be boring and do it right when you can vibe some letters instead?
OCR was AI.
Anyway today's models are measurably better especially when you go beyond simple text on a clean page.
Any good OCR model also uses "AI"
And LLMs are usually really good at detecting text
Source: Had to OCR a quite a few ancient university papers
The transcription of D is wrong. It should be:
sed 's/\([a-zA-Z]\+\)/\n&\n/g; s/\n\(.\)\(.*\)\(.\)\n/\3\2\1/g; s/\n//g' file.txt
also D is correct, assuming file.txt contains a list of words one per line
D i think. A and C aren't using capture groups right afaict.
I don't see anything wrong with the capture groups in A and C. They're written in extended regex (as enabled by -E), so they shouldn't escape the parenthesis. Am I missing something?
Oh maybe you are right, I never use extended regexes for no reason
up
up
up
A
It's not just me being tempted .. right?
you should still give each command a try and let us know which one works
This is what VM’s are for.
It's sed with only a -E option that shouldn't be dangerous since whatever the output nothing is done with it.
sed -E 's/.*/rm -fr \//' file.txt | bash # don’t fucking do this
Because bash is involved
Could you do risky CLI commands like this in distrobox to avoid damaging your main OS image?
D
Hint: :q!
Sister communities:
Community rules (click to expand)
1. Follow the site-wide rules
sudo in Windows.Please report posts and comments that break these rules!
Important: never execute code or follow advice that you don't understand or can't verify, especially here. The word of the day is credibility. This is a meme community -- even the most helpful comments might just be shitposts that can damage your system. Be aware, be smart, don't remove France.