Bug#149873: mmv: Options for dealing with this problem
Thanks, Axel for your kind words, and also for your analysis. I've had a look at renameutils, of which I was not aware, though I have it installed on my machine already! It seems to me that it covers interactive usage neatly, so I'd be happy to remove that from mmv, retaining the -n flag, but removing the ability to read renames from standard input. -- https://rrt.sc3d.org
Bug#149873: mmv: Options for dealing with this problem
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 , 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
Bug#149873: mmv: Options for dealing with this problem
Package: mmv Version: 1.01b-19build1 Followup-For: Bug #149873 Hi, I’m the (new) upstream maintainer of mmv, and I would like to fix this problem. 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. Looking at those options in reverse order: 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. Fortunately, there is a replacement: https://github.com/itchyny/mmv 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, and ii) its identical name (the author has previously refused to change the name, but I have filed an issue asking whether an “official” alternative name could be added). 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. 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. “\\” 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. This is a somewhat laboured design, but if it’s correct it does at least allow a solution that doesn’t involve using broken functionality, or having to install a program that wants the same name and that works in a somewhat different way. -- System Information: Debian Release: bullseye/sid APT prefers focal-updates APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'), (100, 'focal-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.8.0-44-generic (SMP w/16 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mmv depends on: ii libc6 2.31-0ubuntu9.2 mmv recommends no packages. mmv suggests no packages. -- no debconf information
