Prev: Coloring stdin, stdout, stderr differently
Next: replace strings based on a dictionary
From: Seebs on 14 May 2010 02:46
On 2010-05-14, Stachu 'Dozzie' K. <dozzie(a)go.eat.some.screws.spammer.invalid> wrote:
> It's always true. You don't know who will use your scripts and what for.
> All scripts, where it's not too much work (like here, or even more, here
> you add much work just to break the script), should be
> stupid-input-proof.

This standard strikes me as unattainably high. :)

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam(a)seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
From: pk on 14 May 2010 04:41
Stachu 'Dozzie' K. wrote:

>> For 90% of the scripts I write, I perfectly know where and when they will
>> be used;
>
> ...except that you still don't know where they will be used and what
> for, and still you leave hidden problems. Great. "No, `make' tool will
> be used just for compiling programs. I know that and I can assure you."
> And I've seen

Unless you have some sort of crystal ball, you certainly can't speak for
anything else beyond your personal experience.

>> for the remaining 10%, I try to make them as robust as possible (and
>> this is an old debate I certainly don't want to reopen, so I won't reply
>> further on that). So your statement is not always true.
>
> It's always true. You don't know who will use your scripts and what for.
> All scripts, where it's not too much work (like here, or even more, here
> you add much work just to break the script), should be
> stupid-input-proof.

Your "solutions" certainly are not that. Mine came with a description of
expected usage and limitations, with no claims of perfection or "betterness"
with respect to something else.
If you take code designed to work in a certain way, and use it to do a
different job ignoring the original specifications, and it fails horribly,
it's certainly not the fault of whoever published the original code. Even
more so if the code was published by someone on a public newgroup.

(And anyway, I'd be curious to see which, between yours and mine, is the
code with a much greater chance of disastrously failing if just pasted and
run unchanged).

>> And since you claim that there are "plenty" of better solutions, I
>> suppose you won't mind showing at least two or three of them,
>
> I did in <hsi0f0$lec$2(a)solani.org> (my previous post), if you haven't
> noticed.

No you didn't.

>> so people can really
>> see if they are really robust, and if they don't have problems under
>> certain circumstances.
>
> Except for common xargs problem (whitespace splitting), they're better
> and much shorter than your multi-script solution.

"better" means absolutely nothing in programming, as you should probably
know, because the meaning of that word depends on dozens of factors and
circumstances. But I have the feeling I'm wasting my time.

>> I wouldn't call any of the solutions you posted so far robust, nor short,
>> nor elegant.
>
> And yours:
> * Is it robust? Nope.

More than yours, and a lot more so (with the stated limitations).

> * Is it short? Hell no! Two scripts to maintain?

This is true, but if it's for a one-off job, it may be adequate. Or even if
it's for permanent use, depending on the user's environment. Mine can be
easily extended to do other things, whereas yours works (maybe) only for the
specific problem. I'm not saying that either quality is good or bad; only
that we probably wrote the code looking at the problem from different
perspectives.

And anyway, if you disagree, just post your solution without criticising
other people's (especially if you post code that lends itself to even more
harsh criticism), and the OP will then be able to decide for himself.

> * Is it elegant? In no way.

Look who's talking. Relying on command failure, redirecting stderr and
filtering out "expected" errors is really elegant, instead. Indeed, it's
regarded as "best practice" in all scripting books. Like calling unnecessary
external processes, and using xargs. All highly recommended practices,
especially when using modern shells.

An elegant solution for example is the one that uses find's -empty and -
delete predicates, which was posted later, although it requires GNU find and
needs to use -depth to do what the OP wanted, and still suffers the race
condition. But it's just a matter of making these requirements explicit, as
I did for mine, and the OP will be able to judge if it fits his needs.

(you still failed to post your allegedly "better" solutions, but I'm not
surprised. I won't reply to further argumentative and content-less posts)
From: Stachu 'Dozzie' K. on 14 May 2010 05:01
On 2010-05-14, pk <pk(a)pk.invalid> wrote:
>> * Is it short? Hell no! Two scripts to maintain?
>
> This is true, but if it's for a one-off job, it may be adequate.

For one-off job could be adequate just running rmdir and filtering out
expected errors. Buzzwords.

> Or even if
> it's for permanent use, depending on the user's environment. Mine can be
> easily extended to do other things, whereas yours works (maybe) only for the
> specific problem.

So maybe let's get more generalized solution?
1. run command
2. ...
3. profit!

Your "easily extended to do other things" means virtually nothing, as my
posted commands could be "easily extended to do other things", too.

>> * Is it elegant? In no way.
>
> Look who's talking. Relying on command failure, redirecting stderr and
> filtering out "expected" errors is really elegant, instead.

Look who's talking.
#v+
find /basedir -depth -type d -exec isempty.sh {} \; -exec rmdir {} \;
#v-
Relying on "." or $PWD being in yor $PATH is very, very elegant. And
maintaining unnecessary external script is elegant, too.

> Indeed, it's
> regarded as "best practice" in all scripting books. Like calling unnecessary
^^^^^^^^^^^^^^^^^^^^^^^^
> external processes, and using xargs. All highly recommended practices,
^^^^^^^^^^^^^^^^^^
> especially when using modern shells.

Look who's talking. Guy who calls external command(!) for each(!)
directory just to check if it's empty says that calling unnecessary
external commands is a Bad Thing[tm]. And while any my posted here
command uses fixed amount of processes (almost, modulo xargs running few
rmdirs), yours behaves terribly when you get more directories.

Man, think sometimes of what you write in your scripts, OK?

--
Secunia non olet.
Stanislaw Klekot
From: pk on 14 May 2010 05:24
Stachu 'Dozzie' K. wrote:

> On 2010-05-14, pk <pk(a)pk.invalid> wrote:
>>> * Is it short? Hell no! Two scripts to maintain?
>>
>> This is true, but if it's for a one-off job, it may be adequate.
>
> For one-off job could be adequate just running rmdir and filtering out
> expected errors. Buzzwords.
>
>> Or even if
>> it's for permanent use, depending on the user's environment. Mine can be
>> easily extended to do other things, whereas yours works (maybe) only for
>> the specific problem.
>
> So maybe let's get more generalized solution?
> 1. run command
> 2. ...
> 3. profit!
>
> Your "easily extended to do other things" means virtually nothing, as my
> posted commands could be "easily extended to do other things", too.
>
>>> * Is it elegant? In no way.
>>
>> Look who's talking. Relying on command failure, redirecting stderr and
>> filtering out "expected" errors is really elegant, instead.
>
> Look who's talking.
> #v+
> find /basedir -depth -type d -exec isempty.sh {} \; -exec rmdir {} \;
> #v-
> Relying on "." or $PWD being in yor $PATH is very, very elegant. And
> maintaining unnecessary external script is elegant, too.

Right, resorting to these arguments really shows you have no real argument.

>> Indeed, it's
>> regarded as "best practice" in all scripting books. Like calling
>> unnecessary
>
^^^^^^^^^^^^^^^^^^^^^^^^
>> external processes, and using xargs. All highly recommended practices,
> ^^^^^^^^^^^^^^^^^^
>> especially when using modern shells.
>
> Look who's talking. Guy who calls external command(!) for each(!)
> directory just to check if it's empty says that calling unnecessary
> external commands is a Bad Thing[tm]. And while any my posted here
> command uses fixed amount of processes (almost, modulo xargs running few
> rmdirs), yours behaves terribly when you get more directories.
>
> Man, think sometimes of what you write in your scripts, OK?

Yes, I usually do, while you seem to not do that (while you DO actively snip
unconvenient parts of other people's messages).

When I said "easily extendable" solution, I meant exactly that. You can
easily modify it to run just one instance of the isempty.sh script. Just do

find /basedir -depth -type d -exec isempty.sh {} +

and in the isempty.sh script you can use a loop over the arguments (and
looping and checking as they are implemented there do not require calling
any external program).
From: Stachu 'Dozzie' K. on 14 May 2010 05:39
On 2010-05-14, pk <pk(a)pk.invalid> wrote:
>> Look who's talking. Guy who calls external command(!) for each(!)
>> directory just to check if it's empty says that calling unnecessary
>> external commands is a Bad Thing[tm]. And while any my posted here
>> command uses fixed amount of processes (almost, modulo xargs running few
>> rmdirs), yours behaves terribly when you get more directories.
>>
>> Man, think sometimes of what you write in your scripts, OK?
>
> Yes, I usually do, while you seem to not do that (while you DO actively snip
> unconvenient parts of other people's messages).
>
> When I said "easily extendable" solution, I meant exactly that. You can
> easily modify it to run just one instance of the isempty.sh script. Just do
>
> find /basedir -depth -type d -exec isempty.sh {} +
>
> and in the isempty.sh script you can use a loop over the arguments (and
> looping and checking as they are implemented there do not require calling
> any external program).

And this is your "easy extension" now? You need to modify isempty.sh to
include `rmdir' now. It's neither elegant, convenient nor maintenable to
have half of the script in one place, and _random_ half in other place.
Just great.

It seems that...

>> Man, think sometimes of what you write in your scripts, OK?
>
> Yes, I usually do,

....you haven't think your code through this time.

That would end the topic for me.

--
Secunia non olet.
Stanislaw Klekot
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Coloring stdin, stdout, stderr differently
Next: replace strings based on a dictionary