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
build.sh
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
