Linked by Eugenia Loli on Mon 20th Mar 2006 07:13 UTC
General Unix After receiving several comments to his November 2005 article on hating UNIX, David Chisnall offers his responses and further insight on his continuing disdain.
Thread beginning with comment 105955
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: Shell Globing
by Vanders on Mon 20th Mar 2006 14:37 UTC in reply to "RE[2]: Shell Globing"
Vanders
Member since:
2005-07-06

It was mearly a simple example. What's wrong with your equivilent loop is that it is far more verbose and less obvious. Why write a for loop when the shell could do it for me? What if I wanted to do "mv qux*_foo_*_.[cpp|h] qux_bar_*_.[cpp|h]"? Write, test and debug an even bigger shell script?

Just because the UNIX shell doesn't allow me to write "mv *.foo *.bar" doesn't mean it's a bad idea. Why should there be an artificial barrier to writing applications to do more useful things?

Reply Parent Score: 1

RE[4]: Shell Globing
by Ookaze on Mon 20th Mar 2006 15:03 in reply to "RE[3]: Shell Globing"
Ookaze Member since:
2005-11-14

It was mearly a simple example

And someone competent came with the solution right away. You should start to understand where the problem is.
No, the guy is no genius, he jus knows his tools.

What's wrong with your equivilent loop is that it is far more verbose and less obvious

BS, it was pretty obvious to me. 'far more verbose' and 'less obvious'. Wow man, you don't even know what you want.
The guy did your job but obviously, what you want is not your job done, what you want is disparage the shell as it is, to find an issue where there is none.
Good luck on that. FYI, I have production code in shell far more complicated than that, that do things you could apparently not understand (if you find this not obvious).
I learnt the shell in one week, the rest is experience, so I fail to see where you people find an issue.

Why write a for loop when the shell could do it for me?

Because the shell does not read your mind ? Some people are amazing, searching issues where there are none. Look at the rename command.

What if I wanted to do "mv qux*_foo_*_.[cpp|h] qux_bar_*_.[cpp|h]"? Write, test and debug an even bigger shell script?

Why not ? With sed for example. Or use rename.

Just because the UNIX shell doesn't allow me to write "mv *.foo *.bar" doesn't mean it's a bad idea

Wrong, it allows you to do it as long as the last name is a directory. The only problem here, is that YOU do not understand what this command means.
You think the authors of mv should have designed it like you think, you don't even understand the problem is that you don't understand what mv does.

Why should there be an artificial barrier to writing applications to do more useful things?

There is none. But that's not what you want. What you want is redefine existing well entrenched Unix commands, because of a whim.
And you use stupid articles (and guys) like this one to justify your wrong view.
When I hear people saying such nonsense, it reminds me of my CS courses, when I realised how much design was important, and how much design had been put in common Unix commands.

Reply Parent Score: 5

RE[5]: Shell Globing
by Sphinx on Mon 20th Mar 2006 16:48 in reply to "RE[4]: Shell Globing"
Sphinx Member since:
2005-07-09

Thanks for spelling that out, some people never get it. Too bad I don't have any mod points because you certainly deserve them.

Reply Parent Score: 1

RE[4]: Shell Globing
by Sheld on Mon 20th Mar 2006 15:08 in reply to "RE[3]: Shell Globing"
Sheld Member since:
2005-12-21

Because "mv *.foo *.bar" would introduce a discrepancy with the way file globing usualy works. '*.bar' doesn't stand for anything in your example, you might as well drop the *.

I think introducing this kind of odd behaviour makes the shell less user friendly, not more user friendly. The for loop might be more verbose but at least it's clear, comprehensible and coherent with the rest of the system. As I said 'remame *.foo .foo .bat' for example is not much longer than 'mv *.foo *.bat' and compliant with the Unix semantic, it's a much better solution.

As for your new command, I suppose you meant "mv qux_foo_*_.{cpp,h} qux_bar_*_.{cpp,h}", it looks more and more as if your mv command is going to have to read in the user's mind, using regular expressions would be much more natural and less error prone (what if the two file globings don't match?). "rename qux_foo_*_.{cpp,h} s/qux_foo/qux_bar/", or today:

for f in qux_foo_*_.{cpp,h}; do mv $f $(sed 's/qux_foo/qux_bar/' <<< $f); done

You're trying to fix a problem which doesn't exist.

Reply Parent Score: 1

RE[5]: Shell Globing
by Vanders on Mon 20th Mar 2006 16:07 in reply to "RE[4]: Shell Globing"
Vanders Member since:
2005-07-06

To be fair, I'm not trying to fix anything. If I personally really felt that file globing was a big problem, Syllable wouldn't be using bash and I'd have written a different shell that doesn't do automatic globing. There are generally workarounds to most problems; you've provided plenty of examples of scripts that can do mv operations on complex filesets.

What bothers me is the argument "That's the way UNIX has always done it so it can't ever be wrong". Globing is mearly a simple example of this.

P.S: O.K, so "mv *.foo *.bar" isn't syntactically correct if you're running a Bourne-like shell. Nor does "mv *.foo .bar" make much sense and .bar could be a directory anyway. Your suggestion of having a special purpose "rename" command isn't right either; now you have two commands "mv" to move files and "rename" to rename them and the user needs to know what the difference is.

Perhaps my real beef is that the Bourne shell syntax is not expressive enough. Or perhaps it's the fact that traditionally, UNIX commands are non-interactive so can not gracefully handle ambigious cases. Perhaps the problem only exists in my head and everything is just peachy. Although I'd rather be talking about these sorts of things than taking the absolute position that UNIX is the evolutionary be-all and end-all of Operating System design.

Reply Parent Score: 3