Good question. I've seen this pattern quite a lot here: sometimes to constructive ends, sometimes not. The worst are when the resulting answers are just code one-liners. Double ouch!
I would suggest a nuanced approach rather different from Software Recommendations: This can be done but it needs to be justified. The justification does not have to be elaborate, but it should instruct the OP and future readers on the comparative merits of different solutions or tools.
By way of example let me pick on sed for a minute. Lets suppose we have a sample question:
Question: How do I get result X out of dataset Y using sed?
First and foremost a good answer to such a question will start off with a sed solution. Besides a working command, and explanation of the flags or routines used and any special data considerations are in order.
At this point the answerer may wish to provide a better solution as well. Their experience may tell them there is a better way go about solving the problem. Maybe sed is a cumbersome tool for the job at hand. Adding onto the answer with "This would be much simpler in awk. {explanation}." should be perfectly acceptable. In fact this is quite useful. They might even provide several methods and comment on their merits in various circumstances.
It's also possible that sed is not capable of the task and that another solution must be provided. It should be up to the answerer to explain why this is the case and not just leave them hanging by dumping an alternate solution.
Now another answerer comes along. Of course they have the perl solution. Suppose the sed case is already well covered by another answer. I would suggest that in order to drop an answer using a different program than was specifically requested it is incumbent on them to also explain under what circumstances the alternate solution would be more appropriate. If you are going to propose and alternate method, take a second to say something about the strengths or weaknesses of the method as compared to the requested one so that people can make informed decisions about what tool to use. The presumption is that even if the OP does not want to switch tools, some future readers might have a slightly different scenario or different preferences. Addressing these other scenarios is fine as long as they are put in context rather than just lobbed in there.
Bad¹:
Answer: Use perl instead: perl -pne '])[{!}+*=!]+*{=]*]'
Good:
Answer: Bob's answer shows how this can be done in sed, but as you can see it gets tricky trying to escape all the possible input strings. If you want to sidestep t he whole problem, there is a more specialized tool des that can make this less brittle. Use it like this...
In the mean time don't:
- …just drop command one-liners with other tools.
- …ignore the specific scenario and tool questioned.
I don't think failure to follow these suggestions should automatically qualify posts as NAA material, but failure to do it should be a fair point of criticism and OP's should be encouraged to make their posts useful. Failure to put their alternative solutions in context is also a failure to be useful and should be dealt with just like other answers an the site that fail to be useful.
¹ Note this is not bad on account of being perl. I like perl, that's why I feel like I can pick on it. It's bad on account of not explaining when or why to use it, how it works, or how it relates to the requested tool.
