You can also do this:
{ zmv '(*).SNT' '$1.eml' } always { TRY_BLOCK_ERROR=0 }
Sheesh, of course I'm no expert, still I've never seen any such construction before. Always new domains of syntax to study. So when zmv quits, crashing out of the function is not immediate -- there is further parsing, thus this 'always' word is handled. Interesting.
On 2023-12-30 12:38, Bart Schaefer wrote:
Arguably zmv could use null_glob. Thoughts from -workers?
That's that option that makes everything grind to a halt if nothing if found?
> No, you're thinking of nomatch, which as I said is already in effect and causing the result that you see. The null_glob option supersedes no_match and makes globs that don't match anything disappear without an error. Yeah, for some unknown reason I said it backwards -- I know that (N) smooths continuation of flow, it doesn't break it. > This is in contrast to the no_nomatch option which leaves the glob un-expanded but does not remove it. I've run into that, and it can be ugly -- literal asterisks being fed to some command that doesn't want them. It's good to understand what's going down there. Setting null_glob globally can be dangerous because it can leave a command with no arguments at all or with its arguments in a different order than expected. Yes, another potential landmine. What might be intuitive is some way of simply making a command 'stop', but that might not be so simple -- something that holds it's place, but has no value -- it 'counts' as an argument but has no content. It's so dumb when: "ls no-such-files.*" ends up listing everything in the directory rather than nothing. Dunno who thought that was a good idea. > zmv -n '(*/)#(*).(SNT|MES)' '$1$2.eml' If that looks like it would do the right thing, remove the "-n". I'll give it a go. So much can be done with all that globbing functionality. Such power. But I can never remember that tersest of all terse syntaxes -- gotta make myself a cheat sheet including a page full of examples.