Re^3: The maybe it is better written this way tool

[ikegami]

I don't understand what you meant by far fetched?

Unless you were suggesting the tool should only look for that specific string, the tool would have to know

• That more's output is being piped.
• How more behaves when it's output is being piped.
• The directory from which ls is launched.
• That the file spec will only match the names of file (not directories).
• That ls is given a list of file names (not directories).
• How ls behaves when given a list of file names.

It would also have to make assumptions such as

• sh is used as the shell.
• ls and more aren't aliases.
• ls and more refer to the standard utilities.

All this from a program that's suppose to know Perl. And that's just to handle that one command.

That it will be difficult to pro-grammatically understand the intention? Yes I guess it will

That it requires an incredible amount of knowledge about non-Perl material to have the slightest clue as to the command's meaning.

Regarding @ARGV I would look for 2 or more occurrences of either \$ARGV\[ or shift; outside of any sub or shift @ARGV; and then recommend.

That's no good. Whether you're doing it "correctly" or not, all you have to do with @ARGV is loop over it. The number of times @ARGV is referenced (i.e. how you loop over it) does not indicate how its contents are used at all.

[szabgab]

The tool does not need to recognize all the cases, if we can find a few that might already help. It also does not need to give an exact alternative. It can just point in the general direction of a better solution and let the programmer decide if she wants to take the advice or not.

[ikegami]

The tool does not need to recognize all the cases

You seem to have misunderstood me. All that knowledge and all those assumptions is needed for that *one* case.