Re: Using -prune option of find to ignore hidden directories
On Wed, May 03, 2017 at 12:23:26PM -0400, rhkramer@gmail.com wrote:
> On Wednesday, May 03, 2017 12:09:59 PM Greg Wooledge wrote:
> > Unfortunately, "remove random parts of the syntax and see what happens"
> > tends to be a poor approach, especially with find(1). There may be
> > some other kinds of problems where that works well, but it wouldn't be
> > my recommendation in general practice.
>
> Ok. It does seem to work for me fairly often. I wouldn't call it random
> (although some might, and it might seem / be fairly random)--my goal is to find
> even a tiny subset of a command that works and then try building from there.
>
> (And, as you noted, the methodoloy is not aimed only at find, and may be
> particularly bad for find (I've had a hate / hate relationship with find ever
> since I started using Linux ;-)
>
>
> Do you have a better approach?
Starting with a small, known-to-work example and building on it is great.
Starting with a non-working example and removing pieces... not so great.
It can be extremely difficult to diagnose a non-working program,
especially if someone else wrote it. This is why debugging takes a
really long time. There are no simple platitudes that can guide you
toward finding the mistakes, let alone fixing them. There are
heuristics and tricks that you can pick up with experience.
In the case of a longer program (e.g. a shell script with multiple
commands), commenting out chunks of code (whole commands) that you
suspect are not related to the problem, in order to whittle the
script down to the smallest subset of itself that still demonstrates
the problem, is a valid technique. This helps you isolate where the
problem is occurring.
The same technique doesn't typically work with single commands, though.
The pieces have to fit together coherently, and you can't just remove
some of them without changing the meaning of all the other pieces.
Stupid example:
ls -l .* | grep foobar
That's a horrible command, broken in multiple ways, but maybe you think
you can fix it. So you try removing the pipeline. Now the grep isn't
even a command any more; it's a filename argument to ls. You've just
made it worse.
The only way to fix that is to rewind back to the beginning, get a
statement of the intended GOAL from whoever wrote the command (it may
not be what you guessed initially!), and then rewrite a whole new
command that will achieve the goal.
Reply to: