In efforts to help those online with questions and problems, sometimes the answers are more dire than the question or problem the original poster (or “OP”) had to start with, if the OP acts on them without recognizing a problem with the example. It’s always best to double check and re-read your suggestion or example and not post it at all if you lack the time to double check what you are offering in a response, and to mention the potential of problems it could cause if your untested example was used without verifying it’s actually what the OP needs… and to make it clear that it is untested so the OP doesn’t attempt to use your example. Moreover, your tested code or example instructions might not work flawlessly for their specific issue anyway, even if you think you fully understand their question or problem.

A good example that sticks out, is a recent web hosting forum thread had someone explain they wanted to replace any opening PHP tags in any .php and .tpl file that were currently “<?”, and to replace it with “<?php” instead. There are valid reasons for this, such as <? can be confused as a PHP opening tag, if it’s an XML tag, so while “short tags” in PHP are usually fine, it is a valid reason to want to always ensure you use <?php instead of <?, as it’ll be correct across more systems and reduce the chances of problems and conflicts later (and it’s more portable this way).

People offered various examples, where one person used a regular expression with a Perl command in shell, which is a common and powerful way to accomplish such things. It was to read in any *\.{php,tpl}$ files, find and replace the value and, before modifying the current file, create a backup of the pre-modified file as $filename.bak. This is always a good idea, as well as having a good, reliable backup of the data before modifying it (so you don’t have to rename files, perhaps selectively, on a live environment site). I was just browsing over the technical forum to see what I could help with, as I had some extra time that day, and saw the post with a suggested solution, and I saw the OP state they ran it and all was fine. I almost missed it, and perhaps I was too late in seeing this, so I posted a follow-up to that thread urging them not to run the example and explained the problem.

The person offering the suggestion was well intended and obviously knew what they were doing, but simply didn’t catch the typo in their example. We all do this at some point, and they were appreciative I caught it, as I would be if someone caught an example I gave that was confusing or could pose a problem for the viewers of a thread (more on that later). The example given would, instead of replacing any instances of “<? ” with “<?php “, actually replace any single instance of white space (” “) with <?php. The example used the regular expression of s/<?\s/<?php/g which globally s/// replaces “<?” (the left side of the operation (less than, question mark, and a space)) with “<?php ” (with the right side of the operation -> <?php (less than, question mark, php, and a space),) or that was the intention anyway.

However, this had an unintended and unexpected result; The problem was that the right side of the operation <?\s (\s = a space character) was that ? is actually a character used in regular expressions to be used to state/mark the preceding character, class or string, for example, is “optional”. Therefore it was asked to match \s (a white space) with an “optional” leading “<” character, so “<? ” OR ” ” would be replaced with “<?php “. Thus, the phrase “Hello, world, how are you?” in a file would be replaced with “Hello,<?php world,<?php how<?php are<?php you?” with no opening (short) PHP tag (<?) in sight to execute the replacement. The file would be filled with broken, irrelevant and unwanted PHP open tags, adding it everywhere it saw a space in the file. The solution was to make the ? character to be seen as ?, meaning it needed to be escaped (backwacked) to disable the “optional” meaning and actually mean just ?. This is done by adding a backslash directly before the character (\?).

Therefore, a simple oversight of the difference between<?\s and <\?\s could cause dramatic and dire results. The poster that offered the solution, again, knew what he was doing and immediately recognized the mistake, but this goes to show that one single small mistake in an example or suggestion, command line, fix or instruction can cause unexpected and awful results. You should therefore always double check your example, even if it is just an example. This is a well versed suggestion in usenet newsgroups, such as comp.lang.perl.misc, as seasoned programming instructors that participate there will remind you, even on examples, you should always check for success or failures, when applicable, such as if a file was successfully opened before trying to iterate through each line of the file handler, because the OP will perhaps not realize this, try running your example and have all sorts of unexpected results and problems. It’s best to create some simple and safe environment to test your example chunk of code, perhaps in a controlled manner, before offering a suggestion, or otherwise to clearly state it is untested and potentially dangerous (if it could be) for them to run.

This goes back to a similar experience I had in the Perl newsgroup recently, where the OP asked what the meaning of m@ was in their example of $string =~ m@@si; I had explained that this was a regex to match (m//) and that @ was just a delimiter and that “m(anything) is making (anything) the delimiter. m// is just most common to see, but m,, or m!! and so on, are perfectly acceptable. It can help save typing over using m// when you have a lot of / characters you’d otherwise have to backwack (escape). (i.e., m!<b>this</b><i>that</i>!si saved typing and makes it more readable than m@<title>\s*(.*?)\s*<\/title><b>this<\/b><i>that<\/i>@si, especially if you have a lot of characters within the regex that are also your delimiters)”.

Well, someone (Ilya) called me on it, and rightfully so, stating that, what I said would be correct, except m(anything) is using `(’ and `)’ as delimiters. This is true, I used a too literal example of “(anything)”, where “(anything)” wasn’t intended to say an entire word or a word within parenthesis would be a valid open and closing delimiter in a regular expression. Good point, even though it’s probably obvious, what if the OP didn’t know (they probably didn’t, since they had to ask originally anyway), and my response could have caused them a lot of confusion.

In fact, the OP actually replied to my example and said ” And what would be the reason for using ( and ) as delimiters in this case? “, and I had found I was explaining my example, and it clearly caused them some confusion, not to mention that certain other characters can’t just be used as a delimiter and could (or not) based on a few other variables (not literal $variables, of course), so you can’t really use anything, and especially “(anything)”.

I suppose this is obvious, but most of us are known to take it for granted; Clarification and a little time to consider the OP might not understand and take you too literally, or run a piece of code or a command, or follow some instruction you didn’t mean as a complete and perfect solution for them, could spell disaster or result in lot of confusion and follow up questions (and maybe more of your time, when it’s less of an opportune time for you to explain, except you are now responsible to, since you caused the confusion or problem). Therefore, taking a few seconds or minutes more, double checking for typos and considering that the OP might copy and paste and run whatever you tell them, dictates you make some type of effort to clarify, re-read what you wrote so it’s not taken wrong to too literally, and hopefully test it, if applicable, before you hit that submit/send button.