You have a problem, so you decide to use a regex. Now you have two problems.
D
It’s not just me being tempted … right?
you should still give each command a try and let us know which one works
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.
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
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
Yo ill be 100 with you.
Regex is where something like an LLM excells.
Don’t rely on an llm for coding, but… This is exactly where it should be in your toolbox.
this is funny i have totally opposite experience
I don’t disagree with this hot take. But the major difference is the sheer resources needed to have an LLM in place of a “do one thing right” utility like sed. In that sense, they are incomparable.
I think they’re arguing for having the LLM generate the regex. And I certainly would not trust an LLM to do that right.