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 

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 

So, could someone please instruct me on how to obtain that version number?

I went through and applied quoting where there should be. I also added 
comments to explain what's going on.

The trickiest part about quoting 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,

To be safe, on line 51 of, 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 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) 

/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 


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

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 


---- On Mon, 11 Sep 2017 04:40:23 -0700 Bryan Richter 
<> 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 

>> <>.) 


>> 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, 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: . 

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




Dev mailing list

Description: Binary data

Attachment: Bash Arg
Description: Binary data

Attachment: At Sign
Description: Binary data

Dev mailing list

Reply via email to