* zmv -W/-w in subdirs, possibly patch
@ 2009-09-05 23:29 Mikael Magnusson
2009-09-06 18:48 ` Peter Stephenson
0 siblings, 1 reply; 3+ messages in thread
From: Mikael Magnusson @ 2009-09-05 23:29 UTC (permalink / raw)
To: zsh-workers
Hi,
% ren */*.JPG */*.jpg
zmv:232: bad pattern: (*/)(*).JPG
--- a/Functions/Misc/zmv
+++ b/Functions/Misc/zmv
@@ -187,7 +187,7 @@ if [[ -n $opt_w || -n $opt_W ]]; then
# Well, this seems to work.
# The tricky bit is getting all forms of [...] correct, but as long
# as we require inactive bits to be backslashed its not so bad.
- find='(#m)((\*\*#/|[*?]|<[0-9]#-[0-9]#>|\[(^|)(\]|)(\[:[a-z]##:\]|\\?|[^\]])##\])\##|?\###)'
+ find='(#m)((\*\*#|[*?]|<[0-9]#-[0-9]#>|\[(^|)(\]|)(\[:[a-z]##:\]|\\?|[^\]])##\])\##|?\###)'
tmp="${pat//${~find}/$[++cnt]}"
if [[ $cnt = 0 ]]; then
print -r -- "$myname: warning: no wildcards were found in search
pattern" >&2
% ren */*.JPG */*.jpg
[the files are renamed successfully]
My question is: Why was the / there in the first place? Would the
above patch break any existing usecases?
(in case it is hard to spot, the patch removes the only / on the
line). If it does break some weird complex
pattern, maybe I would argue that you should not use -w then.
--
Mikael Magnusson
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: zmv -W/-w in subdirs, possibly patch
2009-09-05 23:29 zmv -W/-w in subdirs, possibly patch Mikael Magnusson
@ 2009-09-06 18:48 ` Peter Stephenson
2009-09-06 21:29 ` Mikael Magnusson
0 siblings, 1 reply; 3+ messages in thread
From: Peter Stephenson @ 2009-09-06 18:48 UTC (permalink / raw)
To: zsh-workers
On Sun, 6 Sep 2009 01:29:50 +0200
Mikael Magnusson <mikachu@gmail.com> wrote:
> My question is: Why was the / there in the first place? Would the
> above patch break any existing usecases?
> (in case it is hard to spot, the patch removes the only / on the
> line). If it does break some weird complex
> pattern, maybe I would argue that you should not use -w then.
I've a suspicion this was supposed to catch **/. This might even work.
Index: Functions/Misc/zmv
===================================================================
RCS file: /cvsroot/zsh/zsh/Functions/Misc/zmv,v
retrieving revision 1.14
diff -u -r1.14 zmv
--- Functions/Misc/zmv 11 May 2008 11:23:31 -0000 1.14
+++ Functions/Misc/zmv 6 Sep 2009 18:44:18 -0000
@@ -187,7 +187,7 @@
# Well, this seems to work.
# The tricky bit is getting all forms of [...] correct, but as long
# as we require inactive bits to be backslashed its not so bad.
- find='(#m)((\*\*#/|[*?]|<[0-9]#-[0-9]#>|\[(^|)(\]|)(\[:[a-z]##:\]|\\?|[^\]])##\])\##|?\###)'
+ find='(#m)((\*\*##/|[*?]|<[0-9]#-[0-9]#>|\[(^|)(\]|)(\[:[a-z]##:\]|\\?|[^\]])##\])\##|?\###)'
tmp="${pat//${~find}/$[++cnt]}"
if [[ $cnt = 0 ]]; then
print -r -- "$myname: warning: no wildcards were found in search pattern" >&2
--
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: zmv -W/-w in subdirs, possibly patch
2009-09-06 18:48 ` Peter Stephenson
@ 2009-09-06 21:29 ` Mikael Magnusson
0 siblings, 0 replies; 3+ messages in thread
From: Mikael Magnusson @ 2009-09-06 21:29 UTC (permalink / raw)
To: zsh-workers
2009/9/6 Peter Stephenson <p.w.stephenson@ntlworld.com>:
> On Sun, 6 Sep 2009 01:29:50 +0200
> Mikael Magnusson <mikachu@gmail.com> wrote:
>> My question is: Why was the / there in the first place? Would the
>> above patch break any existing usecases?
>> (in case it is hard to spot, the patch removes the only / on the
>> line). If it does break some weird complex
>> pattern, maybe I would argue that you should not use -w then.
>
> I've a suspicion this was supposed to catch **/. This might even work.
>
> Index: Functions/Misc/zmv
> ===================================================================
> RCS file: /cvsroot/zsh/zsh/Functions/Misc/zmv,v
> retrieving revision 1.14
> diff -u -r1.14 zmv
> --- Functions/Misc/zmv 11 May 2008 11:23:31 -0000 1.14
> +++ Functions/Misc/zmv 6 Sep 2009 18:44:18 -0000
> @@ -187,7 +187,7 @@
> # Well, this seems to work.
> # The tricky bit is getting all forms of [...] correct, but as long
> # as we require inactive bits to be backslashed its not so bad.
> - find='(#m)((\*\*#/|[*?]|<[0-9]#-[0-9]#>|\[(^|)(\]|)(\[:[a-z]##:\]|\\?|[^\]])##\])\##|?\###)'
> + find='(#m)((\*\*##/|[*?]|<[0-9]#-[0-9]#>|\[(^|)(\]|)(\[:[a-z]##:\]|\\?|[^\]])##\])\##|?\###)'
> tmp="${pat//${~find}/$[++cnt]}"
> if [[ $cnt = 0 ]]; then
> print -r -- "$myname: warning: no wildcards were found in search pattern" >&2
Your version works with *.foo, */*.foo and **/*.foo, I didn't try any
other variations.
--
Mikael Magnusson
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2009-09-06 21:29 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-09-05 23:29 zmv -W/-w in subdirs, possibly patch Mikael Magnusson
2009-09-06 18:48 ` Peter Stephenson
2009-09-06 21:29 ` Mikael Magnusson
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).