Something like this isn't really necessary. I do something like this (bash) all the time when I want to change a part of a filename (renames "foo-bar-baz.txt" to "foo-bar-quux.txt"):
mv foo-bar-{baz,quux}.txt
You can have an 'empty' bit to add or remove something from the name (renames "foo-bar.txt" to "foo-bar-baz.txt"):
mv foo-bar{,-baz}.txt
That will work with pathname parts as well (as in the linked demo video) if you include them in the command.
I guess the linked script is useful if you need to do some complex edits to the filename, since you can't usefully have more than one curly-brace-group for this use case. But in that case honestly I'm fine just double-clicking the first argument to select, and then middle-clicking to paste, and then using the arrow keys to edit.
You have technical knowledge applicable to the problem, and you share it. I love that.
You miss an important feature of the solution shown in (I presume) your rush to demonstrate your bash knowledge: the ability to edit a filename shown, in place. Brace expansion doesn't do that, doesn't show you the new filename before you commit the name change and isn't even close to interactive. This part is less great.
Not at all, you're just not thinking the solution all the way through. If you want to see the results, an echo gets you there.
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.
Personally, I just use a tiny magnet to flip bits on a metal disk. If you want to see the results, you can use an AFM.
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.
Sigh. Nearly every Linux/macOS/UNIX box you run into will have bash or something that will do brace expansion. Same goes for having standard tools like sed, awk, echo, etc.
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.
I'm all for standardizing tools but when it comes to interactive commands I don't really see the problem to customize for your particular use case. The only drawback is that it makes it a bit more frustrating to use a 3rd party computer but I spend 90% of my time on my own computers where I can easily import my config files.
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 |
And then at this point I have to backtrack to add the braces at the right location. In this situation I find TFA's solution more straightforward and more elegant.
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.
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.
In my other post, I got the readline method down to one control code. You type "mv name" and hit the assigned control character, which produces a second copy of the name that you can edit in place. It works with any command: mv, cp, ln, git mv ... The editing is in the same command line, resulting in a proper argument that is in the command line. It gets saved into your history, and can be pasted into a script.
I don't see how this script prevents me from learning it. With that said, we're obviously in different ballparks when it comes to the terminal. I don't need to do anything fancy. cd, ls, mv and git are pretty much the only commands I ever use. For me, this script fits nicely into my workflow.
But it's... not? What if I want to use the same trick with 'cp'? Do I go and copy-paste my script, or maybe spend time to make it generic enough to handle both commands? That's not a good use of my time when the shell will do it for me, if only I'd spend a minute to learn.
> You miss an important feature of the solution shown in (I presume) your rush to demonstrate your bash knowledge: the ability to edit a filename shown, in place.
OK, then just use !#$ (the last word of the current command) and press CTRL + ALT + e to expand it into the actual value.
At least with the `fish` shell, you can use "Alt-E" to edit any command line. It's a visual, interactive, re-usable solution that shows the result before you commit it.
Same for me. I knew the bash has emacs bindings and I know just enough to go to beginning, end, delete a word, etc. but I never knew you can start emacs with a shortcut like this. How do you even exit emacs properly?
> in (I presume) your rush to demonstrate your bash knowledge
It's unfortunate that you reach for the uncharitable explanation first. To return the favor, I assume you rushed to post your reply because you think being contrarian and chastising the top-rated comment will get you more karma points? See, that wouldn't be cool... of course I don't actually believe that. While I don't agree with you, I assume you're arguing in good faith!
The simple fact is that I just don't see the need for it; after many years of heavy command-line use, I wouldn't use a tool like this. Either the simple case is sufficient, or I need something much more advanced, like prefix/suffix/regex replacement across multiple files (in which case shell variable expansion will often work, or I'll reach for `sed`). Beyond that, I try to avoid getting used to tools that only exist on my machine, and not on the tens of machines I ssh to weekly. (I already sometimes find myself, for example, attempting to use ripgrep on remote hosts that don't have it, and it's annoying.)
If you look downthread a bit, there are several comments that expand on doing it the "built-in" way that covers the original use case even more. For example:
Type "mv foo.txt" -> hit ctrl+w (cut word) -> hit ctrl+y (paste word) twice -> use arrow keys to edit.
Someone else mentioned fish will expand braces if you hit the <tab> key.
There are so many cool built-in things that the shell can already do for you; writing up a hacky solution that only works for one use case (the methods mentioned above work for mv, cp, ls, etc.) is limiting your learning and wasting your time.
> It may very well be necessary for someone else.
I really wish people would understand that when people make statements like I did, there's an implicit "for me" or "in my experience" tacked onto the end of that. Yes, obviously, people have different needs, and yes, obviously, I am talking about my own personal experience and needs. But I really do think that shell brace expansion covers the 90% case, and I was under the -- perhaps mistaken -- impression that the OP may not have known about it, or realize how it can be useful in this particular context. I knew about this sort of shell expansion for many years before I saw someone using it to do a file rename, and it was a big "wow, how have I never thought of that?" moment for me at the time; I expect that sort of thing happens to a lot of people.
I really like that zsh can be set to expand globs on tab, both useful for editing when a glob is “close enough” and for checking the result quickly. I think a lot of the value of a script like this is you don’t have to switch contexts or think any different before you use it.
Not just that, but the time it takes me to get the braces correct is usually more than it takes me to just select the damn thing with a mouse, paste it, and modify it...
Full agreement from me. My ergonomics and efficiency both improved immensely when I switched from my native layout to US International.
With US International, unless I want to hit the key combo to change layouts, I can still write a single or just a few umlauts (say, for a person's name).
I find it easier to keep my focus when I don't have to make the right wrist twister that is otherwise required for { if using a Swedish layout.
Also try setting caps as compose key and using the standard ANSI layout. Solves the problem of always having to double press characters such as quotes.
Minor point: or the UK layout, for a European keyboard (ISO keyboard) with the tall enter key, rather than the American ANSI layout with a wide enter.
The extra key on the UK layout brings # without shift, which is useful, and £ and ¬ which presumably aren't, but could be remapped to something more useful like € and an accent.
As a UK user I switched to an alternative layout many years ago for RSI reasons. My preference is Colemak but I don't think it matters too much which layout you opt for.
For me the advantage, other than less finger travel, is that the markings on the keys don't match the layout I use. I've been forced a long time ago to commit it all to memory and learn to touch type without looking at the keyboard.
Touch typing is a small thing but is a massive productivity boon just on it's own even if you're not a speed daemon because you don't have to think to type.
I totally agree with this. Another problem are some programs where shortcuts seem to bind to some hardware codes of keys instead of what your layout says, so that shortcuts aren't what they say they are, e.g ctrl+[ would be at ctrl-å instead of ctrl+altGr+9 on a swedish keyboard (which I guess couldn't work because altGr is the same as ctrl+alt, or is that not true?)
In my situation I write in english, swedish, danish and sometimes icelandic as well as in programming languages.
My solution has been to create my own keyboard layout that I call Nordic Programmer which is the US keyboard but by pressing altGr I have åäö letters where they are supposed to be, and øæ next to them. and then on altGr+eyuioadt i have éýúíóáðþ for icelandic. All of them are capitalized by adding shift. This was pretty easy to learn to use and makes me not have to switch keyboard all the time.
It is not truly nordic I guess, because it prioritizes swedish which is the keyboard I learned growing up.
> shortcuts seem to bind to some hardware codes of keys instead of what your layout says
You don't say what platform you use, but this can be true of Windows and Windows-derived systems (which includes a lot of web stuff on all platforms because Netscape foolishly exposed Windows internal key codes 25 years ago). The non-alpha VK (virtual key) codes migrate all over the place¹ or worse disappear (e.g. Turkish doesn't have the VK corresponding to US +/= at all).
I used to work on Chrome OS which currently does this (trying very hard to emulate the Windows rearrangements due to the Netscape web legacy) but will shortly try the “what they say they are” method behind an experimental flag; that is, for example, the shortcut Ctrl+[ would be typed by Ctrl plus whatever you type to get ‘[’.
Yes, it's on Windows I have experienced this issue.
I'm not familiar with the low level mechanics of this but you seem to be. How would it work to do what you write at the end? Isn't altGr just an easier way of typing ctrl+alt? Getting ctrl+[ would then be ctrl+ctrl+alt+9. Or is it a proper key of its own?
AltGraph is physically the key that is right-Alt on US keyboards. My understanding is that Windows has Ctrl+Alt as an alternative because some long ago PS/2 keyboards didn't distinguish the two Alt, so it wouldn't be able to take the same approach.
Couldn't agree more, was using the French layout and while learning vim I always asked myself what are those weird keybindings, switching to US layout, they suddenly started to make sense because the keys are more reachable without the usual gymnastic.
So true. In a month I will receive my new laptop with a qwerty US layout instead of the belgian azerty one I used until now. Using an external keyboard for now, I already see the benefit of qwerty for programmers. And I also switch from macOS to Linux with i3wm.
I didn't know about the Ctrl-Alt-E so that's useful to know when using a new computer or a shared user account. I have `shopt -s histverify` set in my own bashrc. It's a useful sanity check when using history expansion. After typing the command, press Enter to see what it expands to, verify that it's what I intend and hit Enter a second time to confirm the comand.
(Note: I took out the '\ ' from the original because I realized it is not necessary).
The eval is there because in bash text expansion occurs after ';' is interpreted, and we need that to be the other way around. Hence, the escaping of ';' in the input to preserve it for text expansion, and then the eval afterward to get ';' interpreted.
I jumped at it because there are other things one might like to achieve with brace expansion but turn out to be impossible because it is evaluated first - you can't use them with variables.
Don't think of it as selecting files. It's just simple string substitution/expansion. "foo-bar-{baz,quux}.txt" just expands to "foo-bar-baz.txt" and "foo-bar-quux.txt", which are then passed to "mv" as separate arguments. The corresponding files need not exist, as this is a separate bit of functionality than file globbing.
Pathname expansion (i.e. globbing) can't even be used this way as POSIX requires matched names to be lexicographically sorted. That's the first thing that came to mind, before I remembered that brace expansion is a widely-supported extension not defined by POSIX.
Brace expansion doesn't fall under pathname expansion. There is no expectation that the resulting expansion will correspond to files. From `man bash`:
> Expansion is performed on the command line after it has been split into words. There are seven kinds of expansion performed: brace expansion, tilde expansion, parameter and variable expansion, command substitution, arithmetic expansion, word splitting, and pathname expansion.
That's not to say it's POSIX-compliant--I have no idea whether it is. But it definitely isn't grouped in with pathname expansion. bash does have an option to disable brace expansion, but it's not toggled by `--posix`, which leads me to believe it might be POSIX-compliant.
> Brace expansion doesn't fall under pathname expansion.
I thought that was implied in my post, but perhaps I should have made it explicit.
> That's not to say it's POSIX-compliant--I have no idea whether it is
I didn't know one way or another, but since you brought it up, it looks like it probably is not compliant. See, e.g., this argument that `echo {1,2}` must print '{1,2}' because POSIX doesn't require '{1,2}' to be quoted: https://www.austingroupbugs.net/view.php?id=1193
Brace expansion is a nearly universally supported extension, though, so I doubt it's a real problem. And the above link proposes fixing the standard to make the extension compliant.
One of my pet peeves about expressive, terse syntaxes like this is that the features are not Google-able. Entering {} or !#:1 or !? in the search bar is more like swearing than like learning. This one happens to be called "Brace Expansion".
Importantly, realize it's a feature of Bash that deals with strings, not a feature of mv that deals with filenames. It just replaces a word containing a brace expression with a set of words that contain each pattern in the list.
In general, though, I wish that terminals and text editors that do nice things like syntax highlighting and autocomplete supported help text better. Perhaps selecting some text and hovering with your mouse or hitting F1 could bring up a minimal syntax example of the feature you're looking at...
I tend to use tmux for this. Once you are proficient it is much easier to cut/paste without taking your hands from the keyboard. Admittedly the learning curve is way steeper than some bash expansions and/or a simple rewrite function.
This doesn't work to change a file name to something completely different, while you can do that using the posted gist, so there's a necessity for it to not re-type the path to the file twice.
I guess the linked script is useful if you need to do some complex edits to the filename, since you can't usefully have more than one curly-brace-group for this use case. But in that case honestly I'm fine just double-clicking the first argument to select, and then middle-clicking to paste, and then using the arrow keys to edit.