IRC channel logs

2022-07-14.log

back to list of logs

<dadinn>hi all
<xiews>Hi
<dadinn>i am looking into various ways of doing a shebang line for guile
<dadinn>can someone suggest a comprehensive review of all the posibilities? I have tried plain "#!/usr/bin/guile \", and "#!/bin/sh \n exec guile -e main -s "$0" "$0".
<dadinn>Just would like something to help me through the pros-cons of the different approaches
<dadinn>would like my scripts to maximally portable across various linux distros
<dadinn>oh also there is the "#!/bin/env sh \n exec guile ..." type
<dadinn>at the moment I am using #!/usr/bin/guile and obviously that's the least portable. I would also prefer the exec call to take over the actula process, but not sure about those "$0" thingies at the end
<dadinn>also in for Emacs there was this recommendation to add # -*- scheme -*- as the second line in the file... not sure if that's neccessary, I'm using Emacs with Geiser, and never had problems AFAIK
<dadinn>AFAIR
<sneek>Welcome back chrislck :D
<jpoiret>dadinn: what about simply "#!/usr/bin/env guile"?
<rekado_>dadinn: that comment only tells Emacs to use scheme-mode when editing the file. You don’t need it. Alternatively you can put a different type of comment at the very bottom of the file.
<lilyp>dadinn: the exec guile trick is the "most correct", but might cause emacs to mislabel your file as a shell script. IMHO adding mode: scheme to the file-local variables *at the end* is a better idea than at the top
<dsmith-work>Morning Greetings, Guilers
<unmatched-paren>could you not do #!/usr/bin/env -Sguile --flag1 --flag2?
<unmatched-paren>`env -Sguile --language=elisp` works for me
<unmatched-paren>dadinn: ^
<unmatched-paren>sorry `env -S"guile --language=elisp"`
<unmatched-paren>needs to be the same argument ofc
<unmatched-paren>works though!
<unmatched-paren>or #!/bin/sh -cexec guile
<unmatched-paren>although that one might also cause emacs mislabeling i guess
<drakonis>cwebber: where do i push fixes for typos on spritely.institute?
<cwebber>drakonis: gonna open that repo super shortly... but could you just send me an email with the typo catches for the moment?
<cwebber>drakonis: the vcs log of that is a giant mess and we're gonna clean it up before we publish it, which is on the very-near agenda :)
<cwebber>and thank you!
<drakonis>cwebber: sure!
<cwebber>ty :)
<drakonis>cwebber: "The Spritely Networked Communities Insitute is a 501(c)(3) nonprofit public benfit corporation attempting to re-decentralize community on the internet." s/insitute/institute and s/benfit/benefit
<drakonis>by the way, what's this about jonathan rees joining spritely?
<batalie>having a haunt problem and curious if anyone can help me. i'd like my posts to have the prefix "/posts/" but want the collection page to be at the root level "/blog.html". but try as i might i can't get it to build anything but "posts/blog.html"
<batalie>it seems like there should be an easy solution that doesn't step on the collection generator's toes too much
<rekado_>batalie: I use this https://elephly.net/paste/1657825158.scm.html
<rekado_>I just add an invocation of pin-blog-post to the list of builders
<batalie>oh that's a good idea
<rekado_>it’s not *quite* what you ask for because you’ll still have posts/blog.html
<dthompson>batalie: yeah that's not a supported use-case at the moment. sorry about that.
<batalie>no worries
<dthompson>I'll make a note about this
<dthompson>I want to add flexibility where I can
<dthompson>I could add an additional #:collection-prefix keyword argument that defaults to the same value as #:prefix to preserve existing behavior but allow for your use-case
<dthompson>^ for the 'blog' procedure
<batalie>that would definitely work
<dthompson>making changes to haunt has become an interesting exercise in backwards compatibility
<dthompson>if I add a new option, the default has to preserve the existing behavior or else people's site structure might change and links would break.
<batalie>i'm enjoying it either way. this is just the first hitch i've run into
<batalie>yeah
<dthompson>actually it will be slightly more involved than just adding another argument. I have a branch where I'm introducing even more flexibility into how file names are generated that deprecates the #:prefix argument to blog.
<dthompson>as well as the #:prefix arguments to rss-feed and atom-feed
<dthompson>why use a string that only allows for prefixing when you could instead allow for a function that can do anything? :)
<dthompson>someone else presented me with a use-case where prefixing was insufficient
<daviid>dthompson: couldn't you keep #:prefix, and allow a string or a procedure? this would be bw compat
<dthompson>daviid: prefix is still supported and works as expected, but it produces a deprecation warning now.
<dthompson>or rather it will produce a deprecation in the next release
<cwebber>drakonis: ?
<drakonis>which one are you asking about?
<cwebber>drakonis: Jonathan Rees does not work at the Spritely Institute at this point, but we do collaborate
<drakonis>oh i see
<cwebber>and many others also collaborate :)
<drakonis>cool.
<cwebber>but they're someone I talk to about the tech stack a lot so maybe that's how it came up
<drakonis>its on his website
<drakonis> http://mumble.net/~jar/ saw here
<cwebber>ahh
<cwebber>yeah he's in regular conversations with us and reviewing our tech stack, amongst others
<drakonis>that's great.
<cwebber>:)