No. It’s stranger than that.
cd is echoing, so SCRIPTPATH gets two directory names.
SCRIPTPATH=$(cd "$(dirname "$0")" > /dev/null; pwd -P)
fixed that. Not sure why that machine (laptop, ubuntu 17.10) was echoing the cd. It doesn’t on my desktop (Ubuntu 16.04).
But that wasn’t my problem “in the past”.
fails with a database error (as in the examples below).
bin/docker/rails s and doing a backup from the web interface also fails with:
[2017-12-14 20:53:31] pg_dump: [archiver (db)] connection to database "discourse_development" failed: FATAL: Peer authentication failed for user "postgres"
bin/docker/bundle exec script/discourse backup also fails with the same error.
I’ve solved this by
bin/docker/shell_root and editing
/etc/postgresql/9.5/main/pg_hba.conf, changing “peer” to “trust” and restarting the container (one day I’ll figure out how to restart postgres from within the container).
If only I Would read my own notes. (this draft post on my site) describes how to fix the database problem with
sed. (Oh! but it would be easier to fix it in
data and not fool with entering the container.)
My guess is that most folks who use the docker development aren’t running importers, but it seems like a potentially fairly painless way to get a Normal Person to be able to run an import.
It looks like the problem I’ve had with
reset_db was the same strange problem with
SCRIPTPATH not getting set.
I had great intentions of submitting a PR with the two trivial bash changes, but got in another fight with git that I childishly let it win.