cowsay-org / cowsay

apjanke's fork of the classic cowsay project
http://cowsay.diamonds
GNU General Public License v3.0
83 stars 15 forks source link

Install cowthink as a symlink, not a copy #18

Closed nckx closed 2 years ago

nckx commented 2 years ago

Hi,

The LN=… might be overkill, I dunno.

My hope is that this becomes the canonical modern fork of cowsay.

Is this still the case? I hope so. I mean: this one has llamas.

🦙

apjanke commented 2 years ago

Is this still the case? I hope so. I mean: this one has llamas.

I have no idea. I've heard no interest in this project one way or the other. So for now it's just a little thing I'm fiddling with for the sake of a) "seeing what I can do while bearing rigorous software engineering and distribution practices to a project which is, fundamentally and inherently, a silly little joke", and also b) getting cowsay to conveniently deploy in some specialized contexts I care about.

apjanke commented 2 years ago

Anyway! Since the whole point of this little joke project is to Do This Silly Little Thing The Right Way, let's discuss this PR!

Can you lay out the rationale for making cowthink a symlink instead of a copy for me here? I think I intuitively understand it: cowthink should be an alias for cowsay, with specialized behavior that happens because of the aliased name it was invoked by; and they shouldn't be two distinct executables. Is that right?

Can you tell me a bit about the portability of ln? I'm not enough of a Unix-head to know offhand.

nckx commented 2 years ago

Hi, and sorry for the delay. Certified Unix weenie here.

Unix has two universally supported ways to point to the same file data from different names: hard links and sym(bolic )links. Even for a little toy script, storing the same data twice is wasteful and never necessary. It hints at sloppiness at best.

If you really want to know…Perhaps this is a Unixy cultural thing, but seeing completely identical regular files next to each other elicits much the same reaction as seeing multiple identical code blocks in a project instead of functions.

Sure, it works fine, but it strongly implies questionable automation (as here), or an incompetent human (not here! :).

Either way, it puts you on edge: what other bugs might lurk beneath that smell?

I think I intuitively understand it: cowthink should be an alias for cowsay

Exactly. A symlink communicates that very well:

λ ls -l
-r-xr-xr-x 4 root root 9082 Jan  1  1970 cowsay
lrwxrwxrwx 1 root root    6 Jan  1  1970 cowthink -> cowsay

versus

λ ls -l
-r-xr-xr-x 4 root root 9082 Jan  1  1970 cowsay
-r-xr-xr-x 4 root root 9082 Jan  1  1970 cowthink

A hard link is just as good as a symlink here but doesn't show a pretty -> in ls. That's my only reason to choose the latter.

I can confidently say that ln is universally portable on Unices. Not only is it in POSIX, it got there by being already omnipresent at the time it was standardised.

In this case it's a simple regression from the original: cowthink used to be a symlink. That was lost, probably by accident, when the installation was ported to make. A welcome improvement by the way ♥ This just ports it back.

apjanke commented 2 years ago

Oh, yeah, that totally makes sense. Especially if cowthink used to be a symlink in the first place. That was indeed an accidental change when porting to make; I didn't intend to make changes to the resulting destination files like that.

I'll test this over the weekend and merge it. Thanks!

apjanke commented 2 years ago

Tested and looks good. And I think this is a better design, too. Merged.

Thanks for the contribution!