To view parent comment, click here.
To read all comments associated with this story, please click here.
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?
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.
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.





Member since:
2005-12-21
What's wrong with "for f in *.foo; do mv $f $(basename $f .foo).bar; done"?
"mv *.foo *.bar" doesn't make much sense, something like "rename *.foo .foo .bar" would seem more logical.
And of course file globing is available from the glibc, so writing a rename command which would correctly handle "rename '*.foo' .bar" is very easy. Such a command is just too specific to become part of the standard Unix toolbox.