The important point though, is that one of the solutions moves you closer to a common language with other posix users, and one moves you farther away. If you use the tools the way they're intended to be used (brace expansion, for example), you'll recognize it when other people use it. You'll understand similar brace expansions in other commands you see others craft. You won't need to remember if that shell you sudo'd into uses your override or not. The reasons go on forever.
It really isn't necessary. That's not to say someone can't think of a reason for it, but rather that there are better ways to do what it does.
Customize your environment to what makes you the most efficient. Yeah, sure. Learn to use all the things that are there and understand what others do. But customize your environment to what makes you the most efficient. This is an interactive command. It's not like they are going to foist it onto everyone else (which is the true sin, IMHO).
The people who are saying it's not necessary because they prefer alternative ways of interacting with their machine are not arguing that though. The bit the parent replied to was actually claiming that there is no valid reason to do things this way (with a minor bash script) because there are other ways (slightly mysterious curly braces hacks) that do something similar in some cases... which is just, bizarre?
Maybe. It's worthwhile pointing out that "mv x" with no second argument is an error:
mv: missing destination file operand after 'x'
Try 'mv --help' for more information.
TBH I really don't understand the level of pedantry (and frankly, sheer outrage) in this thread at all. It sucks to be on the receiving end of such disapproval over something so trivial. Let this person do what they want! It's a neat little hack. It also inspired me to see what more I could do with 'read'--something I have ignored for 20 years.
This is a valid advice, but on a fundamental level, how is it better or worse than "Learn to be the most efficient for your environment" ?
IMO it comes down to which is harder/expensive, changing yourself or your environment, and on this site in particular, I don't think there is a clear consensus on one or another.
After more than 25 years of using software, IMHO it's a losing battle to try to change the environment around you. It's also a losing battle to try to change yourself. You'll never keep up in the long run. After a while the pace of change becomes so rapid, and change comes from every corner at every level. Eventually what you once knew becomes useless and outdated. You can keep up to some extent, but be prepared for a lifetime of unpleasant surprises.
What works, IMO, is instead to build an environment around yourself that works for you, that protects you from the things changing that you can't control. An internal abstraction layer, a bubble. Then when the bubble breaks in little pinpricks and starts crumbling, you can repair the internal environment to be pretty much what it was before. So by all means, make your own little commands and scripts and stuff. Get cozy, but try to pick your battles wisely on what you will depend.
You see, a shell really isn't necessary to interact with a computer. The big advantage is that, as you are working on the physical laws they will be the same at any computer you will use! It's the only solution that is universal. No need to remember whether the machine you're working on has Windows or Linux installed!
Sure you can come up with "reasons" to do things differently, but, not by argument, but by fiat, I tell you that they are irrelevant and my way is strictly the better way to do things.
But if one needs to see the name before committing a change, there is https://superuser.com/questions/215950/how-to-expand-on-bash...
You can't say the same thing about a bespoke shell function that gives you editable renames.
> Sure you can come up with "reasons" to do things differently, but, not by argument, but by fiat, I tell you that they are irrelevant and my way is strictly the better way to do things.
That's not what anyone is doing and you're attacking a straw man.
In this particular instance I also don't find braces much more ergonomic at all. I typically navigate the filesystem using tab completion, that means that I'm going to end up with a full path like:
mv /foo/bar/some_complicated_file_name.txt |
I think a more productive advice would be "don't customize something until you've given existing solution a fair chance". It's easy to go overboard with customization and make it counter productive. It's important to understand the mindset of the people who wrote the tools and whether you're truly facing a limitation or the system or if you're "doing it wrong".
For instance I personally love zsh's global aliases and have "G" aliased to "| grep" for instance. So I can write for instance "some_command G something" to grep through the output. I also have "M" bound to "| less". Probably saved me tens of thousands of keystrokes through the years.