Sorry to break this news right as you're entertaining the idea of an alpha release, but Issue #66 is bigger than just a Bash script failing to quote things.
This article has a chance of being relevant, but only a chance. My next step is to learn what version of GHC Stack uses to build Yesod. If it's less than 7.4, we may have an answer (see article). If not, we may have an adventure. So, could someone please instruct me on how to obtain that version number? I went through build.sh and applied quoting where there should be. I also added comments to explain what's going on. The trickiest part about quoting build.sh was the "change directory" part, which I explain in the script as a comment. *Quick aside: What does the dbenv subroutine do? I wanted to put in a comment explaining its function, but it was not readily apparent to me. Anyhow, my copy of that build script is now thoroughly quoted, I mean 100%. There is only one other Bash script in the project, keter.sh. To be safe, on line 51 of keter.sh, I inserted escaped quotes around $install_path. This is so the stack executable receives its --local-bin-path argument in quotes, so that stack interprets the path as one argument. So, what we're down to now is: a Stack bug, a Yesod bug, a GHC bug, or some combo thereof. I'm talking about what build.sh launches just after the "cd" part. In debugging, it may be useful to know that both halves of the incorrectly-parsed filepath string are used. Some other shell that got spawned to /dev/fb/63 (at least on my machine) complains: /dev/fd/63: line 1: export: `One/snowdrift/.postgres-work/sockets': not a valid identifier/dev/fd/63: line 2: export: `One/snowdrift/.postgres-work/data': not a valid identifier Later down, devel.hs complains: devel.hs: libpq: failed (could not connect to server: No such file or directory Is the server running locally and accepting connections on Unix domain socket "/run/media/jthomas/Backup/.s.PGSQL.5432"? ) Recall that my path is "/run/media/jthomas/Backup One/snowdrift", with emphasis on the "Backup One" part. The first complaint above picks up from the "One" part, whereas the second complaint goes all the way through the "Backup" part, skips the space and the "One", then appends a filename. I haven't done any git stuff for this project yet, so if you're dying to see all this right now, I've attached my modified build.sh. Also, in case it interests anybody, I attached some explanatory Bash scripts. They go over $@ and argument quoting. They show how to make sure your apparent arguments really are the arguments. If anyone joins this project and is new to Bash, these scripts may come in handy. -Jake ---- On Mon, 11 Sep 2017 04:40:23 -0700 Bryan Richter <br...@snowdrift.coop> wrote ---- > On 09/11/2017 08:00 AM, Peter Harpending wrote: >> On Sep 10, 2017 11:27 PM, "jake" wrote: >> >> Hello, I'm Jake. I'm brand new here. In summary, I want "real >> world" Haskell experience. (Long version sent to >> commun...@snowdrift.coop <mailto:commun...@snowdrift.coop>.) >> >> I tried to build the test platform, but encountered a classic >> bug: the space bug. >> >> Easy to replicate: make a directory with a space in its name, >> such as "foo bar". In my case, it was "Backup One". Navigate >> (cd) your terminal to this place. Follow the build instructions >> in BUILD.md, starting with the "git clone..." line. >> >> Well, something in the build script does not handle that space. >> >> Using my example with "Backup One", it expects a Unix socket to >> be at: >> >> /run/media/jthomas/Backup/.s.PGSQL.5432 >> >> Notice the "/Backup/" part should be "/Backup One/". >> >> Furthermore, navigating to jthomas reveals that there is no >> "Backup" directory. So that file really does not exist. >> (Sometimes these things make the directories that they think >> should exist. Not in this case.) >> >> >> Cheers, Jake > Welcome. I'm Peter. > > If you want to get involved, this would be a good bug for you to > fix. It's relatively simple, and you already understand the issue. > > This would be a low priority issue for us as most developers don't > put spaces in file names, so this is unlikely to cause serious > issues > Hi Jake, welcome! Congrats, you ran into a "real world" bug. :) I created an issue to track it: https://git.snowdrift.coop/sd/snowdrift/issues/66 . Like Peter says, it's probably a good place to make a fix. Unfortunately it's likely a Bash bug, not a Haskell bug. Probably some variable in build.sh needs quoting. Build bugs are actually always important, so if you don't have a chance to get to this, I'll do it this week some time. Thanks! -Bryan _______________________________________________ Dev mailing list Dev@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/dev
Description: Binary data
Bash Arg Quoting.sh
Description: Binary data
At Sign Test.sh
Description: Binary data
_______________________________________________ Dev mailing list Dev@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/dev