The following function was taken from ohmyzsh, and I am rewriting it to work with PowerShell 7.2.2 for educational purposes.
function __git_prompt_git() {
GIT_OPTIONAL_LOCKS=0 command git "$#"
}
Apparently, PS does not support inline variables like ($foo='bar' func), and ($foo='bar'; func) throws an error at ;. Also, I don't know if Git for Windows reads from $GIT_OPTIONAL_LOCKS or $env:GIT_OPTIONAL_LOCKS.
Environment variables are distinct from normal variables you use in Powershell. The environment is what the env: implicit "PS Drive" lets you access, and this sits alongside several other drive-like namespaces, a few of which are the actual drives like C: and so forth.
PS C:\> get-psdrive
Name Used (GB) Free (GB) Provider Root
---- --------- --------- -------- ----
Alias Alias
C 127.73 337.38 FileSystem C:\
Cert Certificate \
D 281.46 2700.96 FileSystem D:\
Env Environment
Function Function
HKCU Registry HKEY_CURRENT_USER
HKLM Registry HKEY_LOCAL_MACHINE
Variable Variable
WSMan WSMan
And as you might suspect, you can indeed dir (Get-ChildItem) the env: "drive":
PS C:\> dir env:
Name Value
---- -----
ALLUSERSPROFILE C:\ProgramData
APPDATA C:\Users\myname\AppData\Roaming
...
So yes, $GIT_OPTIONAL_LOCKS and $env:GIT_OPTIONAL_LOCKS are indeed completely different. The first is just a variable in the running powershell scope, the second is the environment variable of the same (coincidental) name.
Since environment variables are external you will need to save and restore, for instance like:
$t = $env:GIT_OPTIONAL_LOCKS
$env:GIT_OPTIONAL_LOCKS = 0
git "$#"
$env:GIT_OPTIONAL_LOCKS = $t
This does the right thing if the environment variable does not already exist; $t will be set to $null and setting the environment variable to $null will remove it from the environment.
Related
I am new to PostgreSQL and when I tried to install PostgreSQL 13 / 14 on my Windows 10 device I encountered the following error.
"The environment variable COMSPEC does not seem to point to the cmd.exe or there is a training semicolon present. Please fix this variable and restart installation."
The screenshot of the pop up error
COMSPEC System Variable
This is the setting of my COMSPEC environment variable
The Content of the installbuilder_installer.log
Log started 05/06/2022 at 17:51:52
Preferred installation mode : qt
Trying to init installer in mode qt
Mode qt successfully initialized
Setting variable whoami from C:\WINDOWS\System32\whoami
Script exit code: 0
Script output:
atrapa\junkwong
Script stderr:
Executing C:\WINDOWS\System32\icacls "C:\Users\junkwong\AppData\Local\Temp/postgresql_installer_c7c2d91f40" /inheritance:r
Script exit code: 0
Script output:
processed file: C:\Users\junkwong\AppData\Local\Temp/postgresql_installer_c7c2d91f40
Successfully processed 1 files; Failed processing 0 files
Script stderr:
Executing C:\WINDOWS\System32\icacls "C:\Users\junkwong\AppData\Local\Temp/postgresql_installer_c7c2d91f40" /T /Q /grant "atrapa\junkwong:(OI)(CI)F"
Script exit code: 0
Script output:
Successfully processed 1 files; Failed processing 0 files
Script stderr:
Executing C:\WINDOWS\System32\cscript //NoLogo "C:\Users\junkwong\AppData\Local\Temp\postgresql_installer_c7c2d91f40\prerun_checks.vbs"
Script exit code: 0
Script output:
The scripting host appears to be functional.
Script stderr:
Could not find registry key HKEY_LOCAL_MACHINE\SOFTWARE\PostgreSQL\Installations\postgresql-x64-14 Base Directory. Setting variable iBaseDirectory to empty value
Could not find registry key HKEY_LOCAL_MACHINE\SOFTWARE\PostgreSQL\Installations\postgresql-x64-14 Branding. Setting variable iBranding to empty value
Could not find registry key HKEY_LOCAL_MACHINE\SOFTWARE\PostgreSQL\Installations\postgresql-x64-14 Version. Setting variable brandingVer to empty value
Could not find registry key HKEY_LOCAL_MACHINE\SOFTWARE\PostgreSQL\Installations\postgresql-x64-14 Shortcuts. Setting variable iShortcut to empty value
[17:52:01] Using branding: PostgreSQL 14
Could not find registry key HKEY_LOCAL_MACHINE\SOFTWARE\PostgreSQL\Installations\postgresql-x64-14 SB_Version. Setting variable sb_version to empty value
Could not find registry key HKEY_LOCAL_MACHINE\SOFTWARE\PostgreSQL\Installations\postgresql-x64-14 pgAdmin_Version. Setting variable pgadmin_version to empty value
Could not find registry key HKEY_LOCAL_MACHINE\SOFTWARE\PostgreSQL\Installations\postgresql-x64-14 CLT_Version. Setting variable clt_version to empty value
Could not find registry key HKEY_LOCAL_MACHINE\SOFTWARE\PostgreSQL\Installations\postgresql-x64-14 Data Directory. Setting variable server_data_dir to empty value
Executing C:\Users\junkwong\AppData\Local\Temp/postgresql_installer_c7c2d91f40/temp_check_comspec.bat
Script exit code: 0
Script output:
Script stderr:
Exiting with code 1
And the COMSPEC variable is indeed set as a System Variable not a User Variable like many posts proposed. Also, there is no trailing semi colon (;)
What I have tried:
I have ran the "%COMSPEC%" /C "echo test ok" on my command prompt and got "test ok" as result see here
Ran the installation on Administrator cmd.
To install different versions of PostgreSQL including 14.2.2, 14.3.1 and 13.7.1 (all produce the same error message)
Tried out the solution proposed by Prayash Koirala but no Command Processor file can be found Postgresql 9.4 installation/Windows 8.1/ COMSPEC issue
Tried this Problems Installing PostgreSQL 9.2 . but the bitrock_installer_xxxx.log is absent from the suggested path
Thank you very much, any help or suggestions are appreciated.
Have a good day.
Regards,Jun Kang
Run the following command at a command prompt:
fsutil behavior set disable8dot3 1
Restart the computer.
This is a solution from https://learn.microsoft.com/en-GB/troubleshoot/windows-server/performance/stop-error-code-0x00000019, it worked for me.
I had the same issue and search all over. Have tried a lot but finally
I found a working solution. Seems like the problem is related to handling
of 8.3 filenames. I followed the tip in: https://hub.alfresco.com/t5/alfresco-content-services-forum/solved-installation-error-on-windows-10-x64-registerservice-bat/td-p/209616
or go directly to
https://support.microsoft.com/en-gb/help/121007/how-to-disable-8.3-file-name-creation-on-ntfs-partitions
Compared to the guide my default registry key was 2 and not 0. Anyhow,
changing it to 1 (+reboot) allowed the COMSPEC-test to pass.
Seems to be a "installation script" vs "Win10" issue...
/Björn
Hi i have faced the same issue but then i changed the environment variables of CompSpec to name: ComSpec and the path: C:\Windows\system32\cmd.exe and restarted my pc and it installed successfully. Hope it helps.
I faced this problem once again, and my previous answer didn't work for me this time.
I solved the problem by instead of using classic PostgreSQL installer, I set this up with a Docker.
Install Docker Desktop
https://www.docker.com/products/docker-desktop/
Start installed Docker Desktop
In PowerShell, run:
docker pull postgres
In PowerShell, run:
docker run -d -p 5432:5432 --name postgres -e POSTGRES_PASSWORD=mypassword postgres
Now you can connect to the Postgres server for example with pgAdmin on the same machine, using:
host: localhost
port: 5432
maintenance database: postgres
username: postgres
password: mypassword
I had the same error like yesterday man and the answer above is pretty correct. I am just going to elaborate the procedure in clearor steps.
First, right-click on the Windows icon on your taskbar and select System.
In the Settings window, under Related Settings, click Advanced system settings.
On the Advanced tab, click Environment Variables.
Under System Variables click New to create a new environment variable. Name it ComSpec and set the path to point to C:\Windows\system32\cmd.exe
After creating the environment variable click Apply and then OK to have the change take effect.
Restart might be required.
Peace.
I'm trying to update the JVM Heap Size from Powershell by running this PS Script. It works on the local machine and persists as an env variable:
test.ps1
& cmd /c 'SETX _JAVA_OPTIONS "-Xms256m -Xmx256m"' | Write-Host
But when triggering this same test.ps1 script from a Remote Machine (through Nagios NRPE), the value of this env variable does not update though a success message is returned to the remote machine.
If running the Powershell command for setting the env variable (in a non-admin console), like below:
[Environment]::SetEnvironmentVariable("Test3", "test string", "Machine")
I'm getting this error:
Exception calling "SetEnvironmentVariable" with "3" argument(s): "Requested registry access is not allowed."
So how to trigger this PowerShell script remotely in an admin prompt mode?
You likely need to start the service that is running NRPE (NSClient++?) with an elevated account.
I want to log into a Windows server using a local user, then map a network drive using an Active Directory user and run an installer from it automated with Ansible.
I followed the suggestion from this question to create a PowerShell script and do the mount and the install. I used that script as follows:
Inventory:
[winserver]
windows
[winserver:vars]
ansible_user="local_user"
ansible_password="P#ssw0rd"
ansible_connection="winrm"
ansible_winrm_cert_validation=ignore
win_user="domain\aduser"
win_pass="P#55w0rd"
task yaml:
---
- name: Mount and run a script
script: 'files/maprun.ps1 -map_user {{ win_user }} -map_password {{ win_pass }} -script z:\ascript.ps1'
And the maprun.ps1 script contains the following:
param(
$map_user,
$map_password,
$script
)
$PWord="$map_password"|ConvertTo-SecureString -AsPlainText -Force
$myCreds=New-Object System.Management.Automation.PsCredential($map_user,$PWord)
New-PSDrive -Name "Z" -PSProvider "FileSystem" -Root "\\domain\share" -Credential $myCreds
echo Invoke-Command -ScriptBlock $script
And I get the error:
New-PSDrive: A specified logon session does not exist. It may already have
been terminated
Most hits talk about a double-hop problem, but I am trying to specify different credentials in the remote script, so this isn't a double hop problem. The other answer suggests this ought to be possible. The script works in interactive mode, so it is something to do with being in batch mode. Any ideas how I can get this to work?
I am using Ansible 2.3.1.0 on Red Hat Enterprise Linux. Windows is Windows Server 2012 R2. Scripts were manually typed, sorry for any typos.
I can make a few suggestions.
As you've written it, the script "maprun.ps1" must be saved in the "files" directory of your Linux controller machine. If it is, the "maprun.ps1" script will be copied by Ansible to the remote host, executed and deleted. If "maprun.ps1" is going to call "ascript.ps1" you need to copy "ascript.ps1" over to the remote host before calling "maprun.ps1" and have it's location defined in the context of "maprun.ps1".
You don't need parameter names before the args in your playbook "script:" command.
Args internal to your Ansible playbook need double curly brackets and quotes around them.
As an alternative to connecting to the network drive with the New-PSDrive command you could try the "net use" command as shown below.
So instead of
script: 'files/maprun.ps1 -map_user {{ win_user }} -map_password {{ win_pass }} -script z:\ascript.ps1'
Try
script: files/maprun.ps1 "Z:" "{{ win_user }}" "{{ win_pass }}" "z:\ascript.ps1"
Where maprun.ps1 contains the following...
# connect to a shared resource and run script
param(
[string]$map_server,
[string]$map_user,
[string]$map_password,
[string]$script
)
# connect to the network drive
net use $map_server $map_password /USER:$map_user
Invoke-Item (start powershell ((Split-Path $MyInvocation.InvocationName) + $script))
net use $uncServer /delete
I have a problem running runas /USER:testuser cmd or runas /USER:testuser powershell:
If testuser has opened RDP session, %HOMEPATH% points to \Users\testuser
If testuser is logged off, the environment looks strange to me:
PS C:\Windows\system32> echo $env:HOMEPATH
\Windows\system32
PS C:\Windows\system32> echo $env:APPDATA
C:\Users\testuser\AppData\Roaming
PS C:\Windows\system32> echo $env:USERPROFILE
C:\Users\testuser
PS C:\Windows\system32> cd ~
PS C:\Windows\system32> cd $home
PS C:\Windows\system32>
I need a correct %HOMEPATH% for my scheduled script. Is it expected behaviour? What can I do about that?
I've tested it on two Win2008, Win7, Win2012 with the same result.
UPDATE: The initial issue was a hanging scheduled task. When I had tested it with runas, I found that ssh command doesn't see a configuration placed in user directory and asks user for additional info.
Since you mentioned ssh, I'm going to take a stab at an answer, since I just worked through a similar issue. I'm using cwRsync 3.1.0, and the example script that comes packaged with it uses %HOMEPATH% to setup %HOME% for rsync execution. Like you experienced, when using 'runas' with the target user not logged into the host, the script halts to accept a hostid, because Windows\system32.ssh doesn't exist. The HOMEPATH is set to Windows\system32.
When the target user is logged into the host (but runas is run under a distinct user's login), the HOMEPATH is set to user's profile path (Users\), and the .ssh path does resolve.
My solution was to change the script o use %USERPROFILE%, rather than %HOMEPATH%. At https://serverfault.com/questions/29948/difference-between-profile-and-home-path and http://blogs.msdn.com/b/patricka/archive/2010/03/18/where-should-i-store-my-data-and-configuration-files-if-i-target-multiple-os-versions.aspx there is discussion that to my understanding, indicates %HOMEPATH% is for user content, whereas %USERPROFILE% is for settings, etc., and probably better for pointing to .ssh.
If I set the environment variable CVSROOT in Windows and give it a value like cvsserver:/home/cvs, if then
1) open Windows CMD shell and do "echo %CVSROOT%", I get "cvsserver:home/cvs"
2) open Cygwin bash shell and do "echo $CVSROOT", I get "cvsserver:home/cvs"
3) from Linux, ssh to the machine and do "echo $CVSROOT", I get nothing.
If I want the ssh session to have a value for CVSROOT, I need to insert it into the .bashrc.
Is there something that can be done so that the ssh session also inherits the environment variable from Windows?
edit:
4) from Linux, do
ssh machine "printenv CVSROOT"
with the environment variable set in .bashrc, I get nothing. At an interactive prompt, I get the variable value, but this way gives nothing.
I found a nice solution here: http://www.smithii.com/node/44
It looks for system variable in registry and sets variables in session opened via ssh.
Then, call the small piece of script from your ssh client (while connecting to your cygwin server), as this:
ssh $WINDOWSUSER#$WINDOWSBUILDSERVER "source /etc/profile ; echo $CVSROOT "
OK, I've figured it out...
For whatever reason, the bash shell is not inheriting the CVSROOT variable that is set on the system. I need to put this line
export CVSROOT=cvsserver:/home/cvs
into both the .bashrc and the .bash_profile files.
The line is needed in the .bashrc file so that non-interactive logins will get the CVSROOT variable. For example:
ssh machine "printenv CVSROOT"
needs this line in the .bashrc file so that CVSROOT exists.
The line is needed in the .bash_profile file so that interactive logins will get the CVSROOT variable. For example:
ssh machine
printenv CVSROOT
If you have your SSH Service running on a windows box (I'm assuming you do) and it's via Cygwin.
The service seems to take a snapshot of the environment variables when it starts up and doesn't refresh them.
Restarting the service should be enough.
One thing is Windows->Cygwin the other thing is ssh
have you tried forwarding your Windows variable to your linux explicitly:
ssh -t user#host "export CVSROOT=%CVSROOT%;/bin/bash --login"
Restarting your computer will solve this problem. Environment variable changes don’t just propagate to all your running programs.
I hit upon the same problem. Got this working by setting the variable like this:
ssh machine "export MYVARIABLE=1 && printenv MYVARIABLE"