Environment variables issue - commands stop working in cmd prompt - windows

After installing one of our application, none of the commands work in command prompt. It says 'command is not recognized as an internal or external command'. After opening the environment variables -> Path -> Do nothing Just say Ok, then the commands start working. This seems to be an interesting issue and came across a blog on the same http://aricsblog.blogspot.in/2007/02/command-paths-not-working-and.html . But just wondering what could be the root cause for this issue? And can someone explain on caching of environment variables?

Related

SSH server evaluate environment variables with wrong user

In Windows, we can get environment variables by $env:{VARIABLE_NAME}. If the variable contains other variables, which is commonplace in PATH, like %WINDIR%\System32, this command will print the evaluated result, like C:\Windows\System32 for the previous example. This is done during shell startup, I suppose.
But inconsistency occurs when it comes to SSH server.
I recently installed pnpm, a high-performance alternative to npm, on my Windows server. It is installed to %LocalAppData%, and it adds its program root to user-level PATH by referring to PNPM_HOME, another user-level variable it creates. When I tried to call pnpm from the remote SSH session, it failed to be resolved. Then I ran $env:PATH in the session, and received the following output:
...;$PNPM_HOME$;...
The referred environment variable failed to be evaluated, while everything goes as expected running the same command on my server through remote desktop.
I looked into corresponding documents, and propounded a plausible explanation: All Windows services are run by the user SYSTEM, and so is the SSH server. When an SSH tunnel establishes, the SSH server reads the registry and evaluated embedded environment variables under the context of itself instead of the remote user. SYSTEM has no PNPM_HOME, thus this PATH segment fails to be evaluated, then the problem ensues.
To corroborate my presumption, I added a new segment $USERNAME$ to PATH, which got evaluated as 'SYSTEM' in the SSH session.
Now, here's my question: how to resolve this problem without changing the environment variables, if my assumption is proven; If not, what's the actual cause of this problem?
By the way, should this be submitted as a bug to OpenSSH?

Powershell Closes Instantly

I've looked all of the the internet and I cannot find any information that applies to this situation.
Powershell closes immediately upon starting. When I run it in Command Prompt I get the following:
Windows PowerShell terminated with the following error:
Unable to cast object of type 'System.String' to type 'System.String[]'.
I have checked the following folders and no profiles exist:
c:\users\me\appdata\microsoft\windows\powershell
c:\windows\system32\windowspowershell\v1.0\
c:\windows\systwow64\windowspowershell\v1.0\
I have tried to run with the following commands and have no luck:
powershell -noexit
powershell -noprofile
I have run the following commands and have no luck:
sfc.exe /scannow
DISM.exe /Online /Cleanup-image /Restorehealth
I also have gone to Control Panel -> Uninstall a Program -> Turn Windows features on or off then,
Removed Powershell, rebooted, then re-installed it.
After doing all of these steps I still am not able to run Powershell. ISE does not work either.
This may be related to Powershell logging settings. I had the exact same issue after implementing Powershell Module logging using the wrong path for ModuleNames.
Check the values set in HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ModuleLogging
In my case, I made the mistake of adding a value of ModuleNames set to * - not realizing it should be a KEY named ModuleNames - which resulted in an error
Windows PowerShell terminated with the following error:
Unable to cast object of type 'System.String' to type 'System.String[]'.
By adding the right path HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ModuleLogging\ModuleNames\ with a REG_SZ value named * and with a value of * I got Powershell working again.
Note that if this setting comes from a GPO (Group Policy Object) in the domain, it will need to be fixed there, rather than in the registry. Otherwise, the GPO will just overwrite the local settings the next time it applies.
Whenever you run powershell, it loads the default modules present in the Modules directory. One of these modules (most likely a custom one you wrote) is causing errors and not allowing you to start.
Without knowing anything about the modules you have present in the directory located at: C:\windows\system32\windowspowershell\v1.0\Modules, it would be hard for anyone to tell you the solution.
Recommendation
Remove any custom modules you have in there and add each module you need one at a time to see which one breaks your powershell.exe. You will need to check each path you have defined for custom modules to be loaded as well.
Other way would be to clear out the PSModulePath from Environment variables and add one location at a time until you see which Modules directory is causing error.
NOTE: Write down the paths on a notepad somewhere before you clear it.
From the error it seems like a .net library class (dll) that is not correctly written.

Why are my bash scripts refusing to run until I type 'exit' ever since I used 'script /dev/null'?

I am working on a cluster, the 'home' machine of which runs Linux version 2.6.38.4 on Debian 4.3.2-1.1. Other machines on the cluster run more recent versions of Linux (3.x.x.x) but on differing flavours (some Redhat, some Debian etc).
As usual, I transferred to chos 8 on one of these machines and set a script running in a screen, but the server began denying that there were any sockets available when I went to reattach it. I followed advice I found online and typed ‘script /dev/null’ in order to retrieve my screens, but it keeps happening. Also, when I start a new screen now, the command prompt is preceded by ‘(base)’.
Now, if I try to run a bash script on anything other than the home machine, the scripts won't run until I follow the command with 'exit', as follows:
bash ~/DAPHNIA/Scripts/compare_BUSCO_depths.sh 2 21 3 3 2-WGS_Clone_21_CGCTATGT-GTGTCGGA_L001;
exit;
The contents of the script don't seem to matter - this irritating quirk now happens regardless of the script being run.
Does anybody have any idea a) what has caused this, and b) how I can fix it, please?

Unable to activate virtual environment in Windows Command Prompt despite it already existing

I created a virtual environment called 'titanic_datascience' and have been able to use it in the past. However, it no longer activates when I call on it with the command 'workon titanic_datascience'. It claims that it does not exist so I tried to create it again with the command 'mkvirtualenv titanic_datascience', but I get back an error saying it already exists. I called the command 'workon' to double-check if it exists and it confirms that it indeed exists. I finally try to activate it once more with the command 'workon titanic_datascience' but to no avail. I have attached an image of the error.
I am using Windows 10 Command Prompt.
Screenshot
I've been googling and looking for similar questions here on stackoverflow, but I have been unable to find anything that resolves the situation.
Any help would be appreciated. Thanks.

Error in Cygwin for Moai Android Build

I'm following this tutorial set to set up Moai for Android porting. When I run
./make-host.sh –p com.gamefromscratch.moai
in Cygwin to build the Android host it returns an error of
build.sh: line 17: ndk-build: command not found
I'm 98% certain everything has installed correctly and I've been following the instructions exactly as written. When I look in the shell script line 17 is
use_fmod="false"
I've never had to use shell scripts or set up anything like this before and my scouring of the internet has failed to yield a result.
As a side note, Moai runs perfectly and I haven't had any problems with getting that to work.
I've solved the issue! When I went to look for the environment variable in Windows (Computer -> right click -> properties -> Advanced System Settings -> Environment Variables), I found that the variable path was there but was listed as ‘%PATH;c:\android-ndk’. As an experiment I changed it to just c:\android-ndk and rebooted the computer. I then ran the line to have the host run and it ran through the process without a hitch. The only difference is that instead of untitled-host my file is called host-source and instead of settings-local.sh my file is called d.settings-local.sh. Outside of those minor file name changes everything else is the same.

Resources