Hello, everyone. I hope I'm not disrupting anything by reviving a discussion
this old. Different forums have varying attitudes towards "necroposting".
While reading this discussion, I found many interesting ideas, but I also
have
some questions about things I think were left unanswered.
I won't try to go chronologically, but if I jump from place to place, I hope
I leave adequate references as to what I'm commenting on.
TL;DR:
- either add mv -p or get rid of cp --parents.
- replace mv with a rename+cp+rm script.
-----------------------------
I'll be referring to the Unix Philosophy as per how Bob Proulx said it:
Message #8
>
Unix Philosophy. Small is
> beautiful. Make each program do one thing well. Choose portability
> over efficiency. Use shell scripts to increase leverage and
> portability.
-----------------------------
I feel like f0rhum's Message #56 wasn't properly answered, if at all.
I'm going to change the phrasing of his question a little bit. You are free
to interpret that question as my own if you want.
f0rhum <at> free.fr wrote:
> I am just trying to understand why this very request is refused with
> the argument "small is beautiful", when the "-p" was accepted for cp:
> I mean why wasn't refused "cp -p" request, saying "just use mkdir first".
> This seems unfair for mv to be refused the ease of use cp was offered.
I can see f0rhum's confusion here.
`mkdir` has a `-p` flag, which is also the same as `--parents` flag.
But for `cp` the `-p` flag was already taken by different
functionality on top of that.
So currently it's confusing.
Message #62
> "cp -p" has nothing to do with "mkdir -p".
But "cp --parents" has _everything_ to do with "mkdir --parents"!
My version of the f0rhum's question is Why was `--parents` flag
accepted for cp?
This brings me to ask several other questions. When we talk about the
Unix Philosophy:
- What do we think about QoL features?
- What does portability mean?
Clearly, `cp` having a `--parents` flag is just a QoL feature. In true
minimalist
fashion that coreutils want, you should "use mkdir -p first".
Thusly, it's truly not fair that cp got the flag and mv didn't.
Portability is even more vague. According to the aforementioned Unix
Philosophy, we
"choose portability" but we also "use scripts to increase portability"???
Huh? What does that mean? My interpretation is that we "choose
portability over efficiency"
in the sense that the program should be as small as possible at the
expense of _user_ efficiency
so that even the weakest of the machines may run them, that's why
these are called "coreutils".
And we "use scripts to increase portability and leverage" in the sense
that we add
extra functionality (leverage) and make them portable in the sense of
working everywhere (all distros?)
and not breaking legacy code and legacy scripts. Again, we do that
with _scripts_.
I can back up these assumptions. Bob clearly wants to avoid bloating
out `mv` when
the same can be done with a script:
Message #8:
> I don't think this is a good idea. It could be added. But does it
> really gain you anything over calling mkdir -p? I don't think so. It
> would simply add code bloat to the program.
Message #16:
> Very good! I see that you have a solution to your problem. [a script]
It doesn't gain you it terms of performance I don't think. But it would gain
in term of user experience. But for that we would need to implement a
"frequency of use" metric.
if I'm correct in my assumptions, then mv should get that flag.
-----------------------------
Now let's step back. Now will be a different topic, though
it had started from the same line of thinking.
Why do we need `mv` as a separate binary utility in the first place?
f0rhum <f0rhum <at> free.fr> writes:
Message #50:
> Would mv be discarded to the benefit of cp + rm?
Hear me out.
The Unix Philosophy claims we "use shell scripts to increase leverage
and portability".
Bob Proulx defends having mv. He says it's required. Let's see how he does
that.
Bob Proulx <bob <at> proulx.com> writes:
Message #53:
> The mv command causes an atomic rename(2) to occur if on the same file
> system. ...
> If mv'ing a file from one file system to another it is impossible to
> have an atomic rename(). In that case mv falls back to effectively cp
> plus rm. That is mentioned in the mv documentation.
If this right here doesn't sound like pseudocode, I don't know what does.
Perfect pseudocode to be made into a "shell script to increase leverage".
it's basically: attempt -> rename
otherwise -> cp + rm
If we hadn't had a mv command today and somebody proposed it. It would
have been deflected the same way you deflect adding mv -p.
in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=8749
in Message #8
Bob Proulx <bob <at> proulx.com> writes:
> I generally dislike combining the functionality of several different
> commands into one command. In this case combining mkdir and chmod and
> I don't see any reason they can't be used individually.
When he says generally, does that mean there are exceptions? Is that
exception
there being branching behaviour? Otherwise `mv` shouldn't exist.
Now I know `rename` isn't part of coreutils. (At least that's what
internet tells me).
But if we look at it, on my system the `rename` binary only takes 23KB
compared to mv taking 119KB. If you all are so hesitant to add mv -p
because of
"bloat" then you must be scrambling to purge mv from coreutils in
place of rename.
`mv` and `rename` might need to swap their residencies of coreutils
and util-linux respectively.
If you need `mv` command to still exist for legacy support purposes, then
you
can implement it as a shell(/perl?) script. That's what Unix
Philosophy tells us, and we have
the Perl implementation of `rename` as an example that people do these
things.
Saying that "it's counterintuitive to use rename" is a null argument.
It's just as
counterintuitive to use mv to rename files, we just got used to it.
Saying that "mv came from Unix" is also a null argument. If you obstruct
improvement (or at least discussion) because of "history", I feel there's
more
than one hole in that logic. It's still possible to make a POSIX compliant
script that does the same thing as the original mv, right?
These are the things that stand in my way of convincing everyone:
- My lack of knowledge in some areas that will completely debunk all
this writing.
- The rigidness of this system because of how much depends on it.
Legacy if you will.
- If we did have a "frequency of use" metric, mv would be pretty high up
there.
- Big Data. I don't have any physical proof that this will improve
anything. Or at least
improve anything in the long run. Although I do think replacing 119KB
executable with
23KB + script should work. Something to do with processor cache sizes
and stuff, but again
I would need actual load tests and stuff.
-----------------------------
P.S. I really apologize for making such a long rant. I hope I don't
come across as aggressive.
I do actually like using `mv`. It's short to type, and easy to use.
I'm poking at
inconsistencies of Unix Philosophy. To me and other _users_ it won't
matter if mv is
a builtin script or a binary. But it might be micro optimization.
P.P.S. funnily enough, this all started because I genuinely want
`mkdir` to have
a flag to `cd` into the newly made directory without typing extra cd.
And as much as I can achieve this with a 3 line script or an alias,
stuff I do has me use
virtual machines, docker containers and remote servers, and I'd want this
QoL workflow improvement to be universal. After all, VERY often you create
a directory and need to go into it. Even fricking git has TWO whole ways to
create a new branch and check into it in the same one command. And you
create
git branches much less often than you do directories.
I may petition this separately. We'll see.
