I don't know if cu3edweb ever found a solution to this problem, but I encountered the same thing today after moving the contents of the pronto-0.6.tar.gz file to my hosting server.
I know with the 0.5 tar there was a problem with the DS definition on MS/WIN platforms that made one of the scripts fail to recognize a relative path versus a fully qualified path (starting at root with a "\") -- unfortunately, I can't remember which script it was that I "fixed" to resolve that. I'm wondering if the '~' in a Linux path was having a similar adverse effect (or if dirname() supports that), but I didn't have time to really investigate the issue.
So, after monkeying around a while, I realized I just didn't have time to keep troubleshooting; instead, I edited two files to hard-code fully-qualified paths into them.
In .../app/profiles/cmdline.php, I replaced each dirname() call with fully-qualified (constant) paths for both config.php and access.php.
In .../pronto/bin/load_schemas.php, I added full paths to the first file_exists() call (to get to my .../app/profiles/cmdline.php) and to the require_once() call which follows it. These are the lines which specifically generate the error message that kicked off this topic.
I realize this is a major hack (my apologies to JV), and maybe someday I'll go back and figure out what was happening. But, if you just need to get things up & running, this worked out for me.
Last edited by spectrum-nashville (2010-03-08 05:39:15)