Could not change to the templates directory ошибка c

Here’s my code:

Sub AttachTemplate()
Dim appWord As Application, TemplateDir As String, Loc As String
Set appWord = GetObject(, «Word.Application»)
TemplateDir = appWord.Options.DefaultFilePath(wdUserTemplatesPath) & «»
Loc = TemplateDir & «poms2012.dotm»

I removed extraneous stuff so you could see the logic.  It dies at .AttachedTemplate = Loc.  I have tried removing the folllowing two lines, hardcoding the value of Loc, putting in error checking, nothing works.

Background: I have several macros kicking off upon document_open.  There is an embedded template in the document that is first placed in the templates folder.  I have a checker to see if the file is open and waits for it to close (this was removed
for simplicity).  After reassigning the new template, it fixes the styles with another macro and opens the styles window.  These work fine if I remove the macro that attaches the template. 

Please help.  I had it working for a day or so a few months ago.  I came in to work the next day and it failed.  I have no idea what happened.  I need it to work in both 2010 and 2007.  Thank you!

So far, I’ve been unable to reproduce this issue with dotnet 2.0.0.

One possibility is that your dotnet new configuration, may be in an unexpected state due to previous installs of this template. If you want to reset the template installation to the defaults dotnet new ships with, you can run dotnet new --debug:reinit (this flag is not technically supported, may change / be removed in the future). After running that command, an empty template list will be displayed, but then the next time you run dotnet new, it will go through the first-run code, and setup to be in the initial state. This might be good, to get into a known state before retrying the install / uninstall. But be aware that any other templates you’ve installed will be removed and need to be re-installed.

Another possibility is that we’re subtlely miscommunicating about the paths being used. For my tests, I have a directory structure that looks like:

C:TEMPTEMP_TEMPLATES
---some-template-folder
    |   some-file.txt
    |
    ---.template.config
            template.json

(output from c:temptemp_templates>tree . /A /F)

From the c:temptemp_templates directory, I run the command:
dotnet new --install some-template-folder
… and observe the newly installed template in the template list.

And then to uninistall, I run:
dotnet new --uninstall c:temptemp_templatessome-template-folder
… and observe the template has been removed from the list.

Postgres wants to create a $HOME/.psql_history file, where it will store all your queries and commands from the psql client. It may well want to do something else at $HOME, but I don’t see any evidence in the form of other hidden files. And it won’t actually create the history file unless you’re using psql interactively, which you’re not.

I had this exact same problem and found this question, but the accepted answer wasn’t acceptable to me — I shouldn’t have to grant postgres permission to leave a trail of my queries in whatever directory I happen to be in when I run a script!

@Corey, the solution you mentioned in your comment (cd /tmp before calling sudo...) is probably the best. psql won’t create this file in /tmp (I’m sure that’s deliberate, because it could allow unprivileged users to read the file).

There are two other solutions I can think of :

1. Run psql in a login shell by adding -i to your command

   sudo -i -u postgres psql < setup_dev_db.sql
   

   This will set $HOME to postgres‘s HOME directory, listed in /etc/passwd. For Ubuntu, that’s /var/lib/postgres. But since you’re piping in commands, it won’t create a .psql_history file. However, if you use interactive psql, anyone else with sudo privileges on the machine will have access to your command history.

   I’m not sure if there are any other negative consequences to running a login shell in this situation.

2. Run psql as a less-privileged user, e.g.

   $ psql dev_db -hlocalhost corey_dev -W < setup_dev_db.sql
   

   If this is a problem because you leave postgres user creation to your setup_dev_db.sql script, and you don’t have any users yet, just add a createuser command in your script first, something like this:

   $ sudo -u postgres createuser corey_dev -P
   

   and perhaps …

   $ sudo -u postgres createdb dev_db "Dev database"
   

NOTE: When using the psql client interactively (which you’re not, here), if you see a message like could not change directory to "/home/corey/scripts": Permission denied message ****, psql is going to write to /var/lib/postgres/.psql_history (or wherever its $HOME is)! If you’ve ever seen that warning when using interactive psql, go look—you’ll probably find a hidden history file.