<abcdw>Morning guile! What is the easiest way to expand a path with environment variables? "$HOME/tmp" -> "/home/user/tmp" <nly>abcdw: try ,apropos getenv <nly>abcdw: yup, (getenv "HOME") <abcdw>nly, thank you for the tip, but I would prefer something less manual, like (with-stdout-to-string (system (string-append "echo " path))), where path is a string, possibly with environment varibles. <RhodiumToad>that sort of thing requires that you trust the path not to do anything strange <nly>it's not strange if i have alias echo="rm" haha <nly>sorry don't have a better answer <RhodiumToad>the posix spec defines a wordexp() function, which guile seems not to provide a binding for <RhodiumToad>that's intended to allow all the kinds of expansions done by shells, but the downside is that it generally works by spawning a shell, and many implementations have or had security bugs as a result <RhodiumToad>the question with these things is what kinds of expansions do you want to allow? $HOME is easy, but what about ${HOME:-foo} or ${HOME+${HOME}/$(blah)} <abcdw>RhodiumToad: wordexp is what I was looking for, but I took a look at the source code and it's a nightmare) <abcdw>For my case I would probably go with very primitive approach using getenv, it's enough to expand only $HOME variable. <abcdw>Thank you everyone for the help. <nly>it works but i realize it's not satisfactory <leoprikler>abcdw: a better approach would be to detect $symbol as regexp and then use getenv <abcdw>leoprikler: Yep, I thought about it, but I think for xdg-user-dirs it's enough to substitute only $HOME variable. <leoprikler>I think the correct way to code xdg user dirs doesn't even include "$HOME" as a string <leoprikler>fwiw if you're using this in guix home, you can just #:use-module (guix utils) to get it, noß <abcdw>leoprikler: xdg-directory is cool, but it always add /guix at the end. The idea to use the XDG_DESKTOP_DIR variable instead of expanding the value myself is good, but won't work in many cases because those variables rarely declared in the environment, they mostly accessed via `xdg-user-dir DESKTOP`, which expands the value as I want, but it requires the invocation of external tool. <abcdw>Seems that manual expansion of $HOME is optimal solution here. <abcdw>leoprikler: I rely on `man user-dirs.dirs`, it says: VALUE must be of the form "$HOME/Path" or "/Path". <abcdw>Nope, I generate it for the `xdg-user-dir` utility and also ensures that all those dirs are created on `guix home reconfigure`. <leoprikler>the easiest thing would be to silently add $HOME/ in the expanding code, no? <abcdw>leoprikler: Not sure what you mean <leoprikler>e.g. have desktop be "Desktop" and then expand that to $HOME/Desktop only when writing the user-dirs file <leoprikler>and otherwise use (string-append (getenv "HOME") desktop) <leoprikler>then you only need to detect some edge cases like leading slash or leading $HOME <abcdw>I think that already implemented approach is good enough. The service configuration sticks to the original value format of xdg-dirs.dirs and expansion code is pretty simple. <leoprikler>tbh I don't understand what "sticks to the original value" means in this context <abcdw>leoprikler: I use the same value format for home-xdg-user-directories-configuration as it in ~/.config/user-dirs.dirs ***lle-bout` is now known as lle-bout
<mwette>wordexp.ffi can be just this: (define-ffi-module (wordexp) #:include '("wordexp.h")) <wingo>that module is auto-generated??? <mwette>Yes. You can control from which includes the definitions are generated, otherwise types are expanded. <mwette>you can also #:use-ffi-module (other module) to work dependencies. Check examples/ffi/gtk2.ffi in the nyacc distribution