Hey, there was a way to write a bb script but have the first part be Bash right? e.g. the bash part would download bb in case it's not there
@kevin.van.rooijen You can probably do this using the exec trick? https://gist.github.com/borkdude/2b963db1582654ec28bfd40b4dc35748#file-api_diff-clj-L1-L5
I think just writing a bash script which then invokes another bb script is easier though
Yeah that probably is
Thanks, I'll look into this
New video: How to use a library from clojars in a babashka script: https://youtu.be/naEH3arI_u0 I use @seancorfield's honeysql v2 as an example.
@borkdude, I made a very simple (probably throw-away) PR on babashka/fs. I'm working my way slowly to the equivalent of cp -al
(copy tree, with attributes, but using hard links). I also just wanted to see if I can create a PR. Feel free to ignore.
Probably the way to do that is to modify ->copy-opts
, maybe?
Nah, it's not one of the standard options. I guess I'd need to use walk-file-tree
.
Looks good to me, the PR.
TIL. On Youtube.
@eamonn.sullivan Is there anything you are missing in copy-tree
?
Copying a tree using hard links: I'm not sure if this is something that is used a lot?
In some back up systems, like Apple's TimeMachine (I think that's what it is called), they use hard-links to snapshot the contents of a directory as it appeared at a certain period of time in the past. Hard links are useful in that circumstance because they take up almost no extra space. It's just another name for a single inode. If the user deletes the file, the file will still exist (under a different name) if they want to recover it. My very simple babashka https://github.com/eamonnsullivan/backup-scripts/blob/main/src/eamonnsullivan/backup.clj#L33 does that.
yeah, you could do that using walk-file-tree and copy-link (which I will merge now, if you have no objections?)
Sounds good to me. Thank you!
Should we also add a predicate for this?
Hmm, it seems the Files class doesn't have such a thing either. Maybe that doesn't apply to hard links
I hadn't thought of that. As far as the file system is concerned, they are the exact same file, just with a different name. Like an alias, I guess. But ls
knows that a file has more than one name (there is a little number that increments when you do an ls -l
). So there must be some attribute that would could check.
oh right
yeah, I think we're good for now
There is a method for this in java (.isSameFile path1 path2), but my Java interop chops are poor and I can't seem to get it to work.
@eamonn.sullivan This is already in fs as same-file?
As yes, so it is, and it works as a predicate. Do you want me to add that to the test?
(is (fs/same-file? (fs/file tmp-dir "dudette.txt")
(fs/file tmp-dir "hard-link.txt")))
Something like that?yeah, would be good to add I think
OK, will make a separate very little PR. One sec.
It's not so clear to me if same-file? will return false for a soft link, from those docs
But it probably will
I tried to find a create-sym-link test, but I don't see it. Just to prove that same-file? would return false here.
create-sym-link is used in a bunch of places in the tests, but there is not a dedicated test for it. feel free to add it
Well, just for your info: same-file?
returns true for both sym links and hard links, so not a predicate in itself for this particular thing. But :man-shrugging: adding it to the test doesn't hurt and makes it clearer, anyway. You've made me curious now. Going to poke around this a little bit. The Posix stat() API would work, if that's possible in Java.
thank you for including hiccup in babashka ❤️ so nice.
I've updated the pull request for the expanded test, btw.
Thanks, merged