Hi Reuben, Reuben Thomas wrote: > Hi, I’m the (new) upstream maintainer of mmv,
Now that's cool! Rhonda: Reuben is upstream of another package of mine and at least from my point of view it's a very healthy and enjoyable upstream/packager relationship. :-) Reuben: I assume that the upstream webpage and repo is now https://github.com/rrthomas/mmv, right? > and I would like to fix this problem. Yay! > Clearly, it is not possible to fix in a backwards-compatible way, so > I see a few options: > > 1. Fix it in a backwards-incompatible way. For an interactive option, this > is not as bad as for a non-interactive option. > > 2. Deprecate the functionality. > > 3. Remove the functionality. JFTR: I'm fine with mostly 1. and 3. — 2. seems to only postpone 3. while not really solving anything. > 3. I don’t think it’s a good idea to keep broken functionality if it’s > possible to remove it: it is a foot-gun, with which users will shoot > themselves in the foot. Ack. > Fortunately, there is a replacement: > > https://github.com/itchyny/mmv Never heard of that one. > This works in a different way: it is *always* interactive, and what it does > is dump the user into an editor, allow the user to do some editing > (typically search and replace), and then renames all the files whose names > have changed when the file is saved (matching them line by line). Unnamed > files are untouched. > > The obvious problems are that i) this program is not (yet?) packaged in > Debian, […] There are two similar tools in the Debian package renameutils: * qmv: The qmv program allows files to be renamed by editing their names in any text editor. * imv (for "interactive move") does the same, just with a readline commandline editor instead of a real editor. > 2. This is basically the current situation: the functionality comes with a > nice pair of warnings in the man page. It would be possible to add a similar > warning in the code, so that for example when you use it it prints a > warning. Or one could add an annoying “danger” flag > --i-really-want-interactive-operation, and refuse to work without it. I > don’t find this satisfactory, though. Ack. > 1. Fix the behaviour. The usual tactic in this situation is to use NUL > delimiters, but this won’t work here, because the output of mmv is designed > to be edited. I suggest the following record format: > > \\OLD// => \\NEW//\n > > The idea is that “//” never occurs in a valid fully canonicalized path, so > is an unambiguous delimiter. Good point, though. > “\\” is used at the start for two reasons: i) > to form a visual bracket with “//”, and ii) to avoid visual confusion at the > start of an absolute path. > > The record is still terminated with a newline (though in general it may > contain newlines). This allows other lines, in particular those starting > with spaces, to be ignored. Sounds like a quite good solution, but IMHO still a rather ugly design. But I do see why a non-ugly design seems impossible. :-) One more thought: Would it make sense to do the following or would this just add to confusion: * Use the current output of "mmv -n" if it goes to a terminal. * Use your newly proposed syntax only if it goes into a pipe. This would at least mitigate the ugliness. But it might add confusion. Regards, Axel -- ,''`. | Axel Beckert <a...@debian.org>, https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `- | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
