4 ms·
I don't understand how "mv", with relative and absolute pathnames, is implementation leakage.
by billsix 14y ago
I don't understand how "mv", with relative and absolute pathnames, is implementation leakage.
- fr0sty 14y agoMaybe it is a UNIX/non-UNIX thing... I have been using UNIX-type operating systems almost exclusively for the whole of my professional life so have zero appreciation for the troubles people have when approaching UNIX tools from a Windows (or whatever) mindset. Git (and the whole toolchain and OS for that matter) is much more about DWIS than DWIM and that does not click for a lot of people.
- dogweather 14y agoNo, it's not about mindset or command-line unix culture. It's about interface design. The command line interface. All of the established unix commands do a particular conceptual thing well. "sort" always sorts. Its options affect how it sorts. But git ... "git checkout" can switch the working branch. "git checkout" can rollback code ... depending on the specified options.
- lubutu 14y agoAs much as I agree with the rest of the article, I have no idea what is meant by this "implementation leakage". Relative and absolute paths are a part of the fundamental Unix interface.
- i_s 14y agoWhat he was getting at with that is the conflation of moving and renaming files. He would want "mv" to take 2 params: (1) old file path (e.g., "/users/dev/foo.clj", and (2) new directory (e.g., "/users/lib").
- dogweather 14y agoFor me personally, mv doesn't actually bother me. But yes, for this discussion, a higher level version would probably split it into two commands: rename and move. And these would only do those particular functions. With that there is no implementation leakage. For the few times that you'd want to move and rename, you'd need to use both commands.
- nemetroid 14y agoI think the implementation leakage is the fact that mv is used for renaming files. Windows has "move" and "ren", where the latter works the way the author would like. > REN [drive:][path]filename1 filename2. > Note that you cannot specify a new drive or path for your destination file.
- laughinghan 14y agoHe's saying that your intention is to use this tool to rename a file, in-place, but the implementation of this tool is `mv` which is supposed to be for "moving" files around in the filesystem, so the implementation is leaking into and clashing with the user interaction.
- freshhawk 14y agobecause he was thinking of doing a rename he expected: mv /path/to/{old_name,new_name} to happen. For people with a mental model of files and directories built from using a GUI with windows and folders this does seem to be implementation leakage since you have to know that renaming is moving because of "how the filesystem works". They think of the file name as file metadata and the file contents as the file. If you have a mental model built around unix-y file management then you probably think of the file path as the file and the fact that renaming and moving are the same thing seems obvious.
- jaylevitt 14y agoAnd even then, knowing that this won't work: mv *.jpeg *.jpg requires yet another mental model, that of a shell and globbing. I've been using UNIX/Linux for 20 years and that still trips me up - because I started in an OS with no shell.