IRC channel logs

2024-05-01.log

back to list of logs

<KE0VVT>Does the shebang #!/usr/bin/env guile -s work?
<rlb>KE0VVT: not sure what your goal is, but
<rlb> #!/usr/bin/env guile
<rlb> !#
<rlb> ...
<rlb>should workk
<rlb>s/kk/k/
<rlb>...hmm, key is sticking.
<freakingpenguin>If you want to pass arguments to guile in the shebang (e.g. -s) you'd need #!/usr/bin/env -S guile ..., assuming coreutils.
<KE0VVT>rlb: My goal is to have a Guile script shebang that works everywhere.
<freakingpenguin>Everywhere is a lofty goal.
<KE0VVT>Not Possible?
<rlb>If you want to be more general, you'll probably need /usr/bin/env and, or /bin/sh and then to exec guile after that.
<rlb>"and/or"
<KE0VVT>Should I just give up and do #!/run/current-system/profile/bin/guile? xD
<rlb>If you don't need to pass extra arguments to guile, then what I posted should be fine, assuming you want what /usr/bin/env guile gives you.
<rlb>(I think.)
<freakingpenguin>/usr/bin/env is enough for "pretty dang close to works everywhere"
<rlb>If you don't need -S, then I think it may be POSIX.
<KE0VVT>freakingpenguin: Why is -S generally recommended?
<freakingpenguin>-S is only if you need to pass extra arguments to Guile as part of the shebang, but it's less portable.
<rlb>KE0VVT: see https://www.gnu.org/software/guile/manual/html_node/The-Meta-Switch.html too.
<rlb>Basically, posix doesn't allow more than one arg after the #! path.
<rlb>well there's only one arg, including all the spaces, formally iirc.
<rlb>-S is a non-posix "fix"
<freakingpenguin>I like https://stackoverflow.com/a/53116875 as an example of stupid it can get if you want to be 100% portable.
<KE0VVT>Why is -s passed as an arg. to Guile for scripts?
<freakingpenguin>I believe -s is implied if you omit it.
<KE0VVT>freakingpenguin: So #!/usr/bin/env guile will work on GNU/Linux, GNU Guix System, and macOS.
<rlb>-S doesn't exist on some platforms.
<rlb>i.e. it's not POSIX
<freakingpenguin>I know it'll work on the first two. I haven't touched macOS but it probably works there too.
<rlb>...but you may or may not care, of course.
<rlb>If you need more flexible arguments more portably, you can do things like this (though of course for guile, you'd probably use the #! !# arrangement rather than """ strings: https://codeberg.org/bup/bup/src/branch/main/dev/have-pylint#L1-L5
<rlb>i.e. the top lines of the script are sh, and the rest is python (or guile).
<rlb>The exec is the cutoff point.
<rlb>But if you can rely on -S, that's much easier.
<KE0VVT>I notice the first time I run a new Guile script, it prints a bunch of stuff about compilation to the screen. That seems user-unfriendly. I'd like my script to have full control over what gets printed.
<KE0VVT>But #!/usr/bin/env guile !# seems to work! :D
<rlb>I may agree, i.e. I'm tempted to think we should stop printing those messages by default, or at least have a way to suppress them.
<KE0VVT>Hm. I did (use-modules (gash-utils regexp)) and it said it could not find anything. I have gash-utils installed.
<rlb>Check your %load-path -- guessing it's not in there, but you can augment that via GUILE_LOAD_PATH, or changing %load-path directly.
<KE0VVT>rlb: I'm using Guix. I don't know what the GUILE_LOAD_PATH is, or whether modifying it directly is even advised.
<rlb>fwiw, wherever gash-utils/regexp.scm is has to be in your GUILE_LOAD_PATH for use-modules to find it.
<KE0VVT>Yeah, I have gash-utils installed; it should just have it in my path already.
<rlb>I'm not knowledgeable enough about guix yet to know what would be expected there, but if you can find the file, then you should (for now) be able to add the parent dir to the load path, e.g. "GUILE_LOAD_PATH=/some/where guile ..." or similar (see also the relevant command line options).
<wakyct>looking at my guile load path it seems there are three default paths, one each for the system, user and Guix home profiles
<wakyct>so I'm guessing Guile packages installed with Guix get put in one of those depending on which profile they were installed to?
<wakyct>or symlinked I guess
<rlb>Some systems may also rely on changes to the environment that won't show up (automatically) until you log out and back in, but offhand, I doubt guix works that way.
<KE0VVT>wakyct: I did "guix shell guile gash gash-utils -- guile" and (use-modules (gash built-ins echo)) (echo "foo") and it could not find code for module.
<wakyct>KE0VVT, where did you get the built-ins module from? I don't see it in the gash repo but I'm probably not looking in the right place
<KE0VVT>wakyct: https://git.savannah.nongnu.org/cgit/gash.git/tree/gash/built-ins
<wakyct>thanks, I wonder what the guile load path in the shell is then?
<KE0VVT>wakyct: Tab-complete in the Guile REPL shows gash stuff.
<wakyct>I'm trying it now
<wakyct>oh echo isn't a fn anyway
<wakyct>it found the module in my repl though
<wakyct>I see the shell doesn't inherit the load path also
<wakyct>I still don't quite understand guix shell environments
<KE0VVT>Basically, I'd like to rewrite post <https://codeberg.org/csh/dotfiles/src/branch/main/bash/.local/bin/post> in Guile.
<wakyct>oh I guess I --preserve and --search-paths are handy there
<wakyct>cool, I haven't browsed on Gemini in a minute
<wakyct>I was wrong about the shell not inheriting the guile load path, the env | grep GUILE just isn't working the same way for some reason
<wakyct>I noticed that when I add gash-utils to a guix shell it does a funny thing to grep
<wakyct>[env]$ grep --help => /gnu/store/3akngn25gprs33jpj1s2a80w5avdgqyd-profile/bin/grep: no such option: --color=auto
<KE0VVT>wakyct: Yeah, gash-utils replaces basic utilities like ls with a Guile script that does similar things.
<mwette>or maybe #!/bin/bash \nexport VAR=val \nexec guile $0 "$@" \n!# (...)
<mwette>jobs
<mwette>l
<mwette>ls