For the OP's sake, I hope they completely ignore your advice.
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?
'Godel_unicode > 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.
'Certhas > The bit the parent replied to was actually claiming that there is no valid reason to do things this way … because there are other ways … that do something similar
It appears to me that you're reading more into 'Godel_unicode's comment than was written. Something not being necessary does not preclude it being useful, and I haven't seen anyone imply otherwise except for you¹. Working through the double-negative, 'Godel_unicode even explicitly acknowledges that some people may have a reason to do things this way, despite their opinion that it's inferior to their method.
¹ I haven't studied the entire thread, so it's likely I've missed someone's comments.
I read it as: You can think for a reason to do X but doing Y is strictly better, so your reason is invalid.
I'm pretty sure what the comment doesn't say, also in tone, is something like: Here are two options, X and Y, sometimes you might prefer one, sometimes the other. Specifically look at the comment that Godel_unicode is disagreeing with. That comment points out that some people might prefer the other solution X for their own reason.
The way I read it, Godel_unicode replies that the person who is not using Y is "not thinking things through", and is ignoring infinitely many reasons ("The reasons go on forever.") to do Y. Even though you can come up with "a reason" for X the infinitely many reasons for Y clearly beat it, and thus Y is just objectively better.
Maybe the comment was intended more charitably than I read it.
> I read it as: You can think for a reason to do X but doing Y is strictly better, so your reason is invalid.
I think that's a much more strongly-negative interpretation than the text as written calls for. My original post was nothing of the sort, and the reply I think you're referring to was -- to me -- a nudge toward just simply realizing that the standard tools that already exist are often much more powerful than we think, and we can usually get 90+% of the way there without doing something custom. And the 10% remaining isn't usually worth doing something non-standard unless you have a very niche use.
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.
I also don't have the habit of letting people type in my shell, so there's that.
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.
You could just filter out anything that begins with a dash and pass it to mv. It seems like mv always interprets that as an option anyway, even if you have a file named --help or whatever.
I like this kind of thing! Minimal code but very elegant from a UX perspective. The oh but you could just mv foo-{bar,baz}.txt crowd is completely missing the point.
> The oh but you could just mv foo-{bar,baz}.txt crowd is completely missing the point.
I disagree. I think a better way to think about things is, "can I accomplish my goal most of the time using the standard tools without writing something custom?" I'll be the first to admit that there are a ton of things in the shell and in coreutils that I don't know about. I bet I've written several scripts over the years with custom functionality that could be replaced with standard tools I didn't know about. That's the thing that I want to avoid.
I think you're reading way too much into what I and others are saying. Honestly I'm finding being misunderstood and mis-characterized as angry to be the only thing that's bothering me.
> Customize your environment to what makes you the most efficient.
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.
Some of us are doing crazy stack switches mid-carrier, so maintaining a bubble around us can be a difficult option. I remember being day-in-day-out in Eclipse doing Java, and switching to a different stack meant throwing it all through the window and finding out what were the most optimized tools for the new set of tasks that will be done hundreds of time a day.
I see the same thing happening with people switching away from iOS dev for instance.
But I also agree we are in a privileged positions where on most tools we can build ourselves the layers to make it look/behave like familiar things. Especially for tools like bash or vim that purposefully change at a glacier pace compared to the rest of the stack.
I guess we usually take both approaches of learning new things to be more efficient and also building/customizing things as we see the parts where we don't want/can't change our behavior.
> Get cozy, but try to pick your battles wisely on what you will depend.
That's feasible only in some scenarios. Nowadays you often need to interact with new environments and be instantly productive in them. Also, it makes little sense trying to receate the same cozy environment between, say, EC2, WSL and FreeBSD hosts when you need to interact with them for a very short time. Welcome to the era of disposable computing.
This only works when you are strictly working with one machine that is your own, instead of many machines, that are not your own. Customizing every machine I touch is more hassle than to just master the tools that are already in place.
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).