Fork me on GitHub
#babashka
<
2024-06-12
>
paul.​legato19:06:32

Is there an easy way to get the directory the script is located in? *file* returns the script filename. If you invoke a script as ./foo, *file* will contain /path/to/./foo (which is arguably a bug.) Is there some simple way to get just the /path/to/ part?

borkdude19:06:51

yes, with (babashka.fs/parent *file*)

paul.​legato19:06:00

parent returns /path/to/./ in this case (with trailing dot and slash)

borkdude19:06:38

you can call (fs/canonicalize ...) on that

borkdude19:06:44

or fs/normalize , not sure which

borkdude19:06:03

FWIW, when I have a script like dude.clj which prints *file* in normal Clojure I get this:

$ clj -M ./dude.clj
"/private/tmp/./dude.clj"
so it seems to behave the same as JVM Clojure which is the goal

paul.​legato19:06:22

Both canonicalize and normalize seem to work properly

paul.​legato19:06:03

Normal Clojure *file* is arguably broken, too, then 🙂

paul.​legato19:06:07

The case of “needing to get the path of the current file” comes up a lot more often writing shell scripts than writing regular Clojure code. Would it be worth adding a Babashka-specific variable here like *script-directory* or the like?

borkdude19:06:07

I don't think we're going to add this, but to be honest, I've also never needed this personally. Why do you need it often?

paul.​legato19:06:53

I’m translating Bash and Zsh scripts, which frequently use dirname to find their own location and thus do things to other resources in the same directory (or a subdirectory)

SCRIPT_DIR=$(dirname "$(realpath "$0")")

borkdude19:06:47

I personally think this is an anti-pattern to support scripts to be invoked from any directory. I think it's better to just get used to invoking them from the root of a project. It's given me nothing but headaches in bash ;)

borkdude19:06:47

given that it might come up though, the *file* approach is good enough imo

paul.​legato19:06:14

I will have to respectfully disagree.. We’ve used this pattern for decades to write portable scripts that can be deployed to a number of different Unix-like environments which we do not directly control, in many cases. They can be invoked using a variety of external invocation mechanisms, and they just work without modification.

borkdude19:06:04

with bb/clj you might not need this pattern as often though. I guess the idea is to load other scripts co-located with your script or so?

paul.​legato19:06:49

This particular case is (essentially): 1. Download remote resource using wget into $SCRIPT_DIR/raw/ 2. Use psql to load it into a Postgres database

paul.​legato19:06:55

The script does not necessarily run from any particular directory, and it is not necessarily invoked from within its own directory (by externally managed orchestration tools that are not directly controlled by us)

borkdude19:06:13

ok makes sense in that case, yes

paul.​legato19:06:34

True, we could go argue with the people who control the orchestration and try to convince them that our “proper” way is better.. but so far, it’s been a lot easier to just use dirname and have the script find its own location

borkdude19:06:50

yeah it makes sense when you don't control who calls the script :)

paul.​legato19:06:17

Right, I would rather focus the considerable energy required to induce them to change on the script itself getting stuff done 🙂

borkdude19:06:41

so I'd go with *file* then. please do not that *file* only works on the top level, so I'd so something like this:

(def current-dir (fs/normalize (fs/parent *file*)))
and not:
(defn current-dir  [] (fs/normalize (fs/parent *file*)))

paul.​legato19:06:10

Got it. That seems to work, thanks!

jjttjj19:06:27

There's also

(System/getProperty "user.dir")
which also works in a repl, and seems to be "pre-absolutized"

jjttjj19:06:43

although, that's the current directory where you started your script, not the script file location itself

👍 1