Where does Windows PowerShell set $profile? - powershell

I would like to move my default "My Documents\WindowsPowerShell" folder. However, when I try this, PowerShell of course can't find $profile. Is there a file or something that I can edit to point PowerShell to a different startup folder?

What I can suggest is that you dot source the file having the content of your profile in the file $profile.AllUsersAllHosts
$profile.AllUsersAllHosts is something like C:\Windows\System32\WindowsPowerShell\v1.0\profile.ps1
Related question: Is it possible to change the default value of $profile to a new value?

You could use junction.exe from Sysinternals to make the WindowsPowershell directory a symbolic link to another location (but not a network drive).
You could do this if you wanted to store the profile scripts at C:\POSH
junction.exe "$HOME\Documents\WindowsPowerShell" 'C:\POSH'

As far as i know you can't do that. The user profile location is always under 'My Documents\WindowsPowerShell' and your only option is to relocate your documents folder (folder redirection).

By default $Profile/$Home/$PSModulePath are all within the registry... normally under
HKEY_CURRENT_USER\Volatile Environment for User environment variables
HKEY_CURRENT_USER\Environment for System environment variables
HKEY_CURRENT_USER\Software\Microsoft\Windows\Explorer\User Shell Folders
and elsewhere!

Related

conda init powershell - no action taken - operation failed

In both cmd and powershell, when I input conda init powershell, it always failed as follows:
(ifcmapping) C:\Windows\system32>conda init powershell
no change C:\Users\haoli\anaconda3\Scripts\conda.exe
no change C:\Users\haoli\anaconda3\Scripts\conda-env.exe
no change C:\Users\haoli\anaconda3\Scripts\conda-script.py
no change C:\Users\haoli\anaconda3\Scripts\conda-env-script.py
no change C:\Users\haoli\anaconda3\condabin\conda.bat
no change C:\Users\haoli\anaconda3\Library\bin\conda.bat
no change C:\Users\haoli\anaconda3\condabin\_conda_activate.bat
no change C:\Users\haoli\anaconda3\condabin\rename_tmp.bat
no change C:\Users\haoli\anaconda3\condabin\conda_auto_activate.bat
no change C:\Users\haoli\anaconda3\condabin\conda_hook.bat
no change C:\Users\haoli\anaconda3\Scripts\activate.bat
no change C:\Users\haoli\anaconda3\condabin\activate.bat
no change C:\Users\haoli\anaconda3\condabin\deactivate.bat
no change C:\Users\haoli\anaconda3\Scripts\activate
no change C:\Users\haoli\anaconda3\Scripts\deactivate
no change C:\Users\haoli\anaconda3\etc\profile.d\conda.sh
no change C:\Users\haoli\anaconda3\etc\fish\conf.d\conda.fish
no change C:\Users\haoli\anaconda3\shell\condabin\Conda.psm1
no change C:\Users\haoli\anaconda3\shell\condabin\conda-hook.ps1
no change C:\Users\haoli\anaconda3\Lib\site-packages\xontrib\conda.xsh
no change C:\Users\haoli\anaconda3\etc\profile.d\conda.csh
needs sudo C:\Users\haoli\OneDrive\??\WindowsPowerShell\profile.ps1
No action taken.
Operation failed.
I already run as Admin. How to solve it? Thanks!
In here
needs sudo C:\Users\haoli\OneDrive??\WindowsPowerShell\profile.ps1
I assume the ??\ are not English letters, you need to change it to English.
Check onedrive online, it is English on my local PC but not in English in the cloud. I changed the folder name to 'Documents'(where my PowerShell is at) in the cloud and synced the change to local. Worked for me.
On Windows when you let OneDrive back up your Documents folder, the folder points to the Documents folder on the cloud, and the actual name of it depends on the language of your system, which I assume it is "文档" in your case.
I just disabled the Documents backup in OneDrive settings, and re-run conda init, which gave me the result
modified C:\Users\username\Documents\WindowsPowerShell\profile.ps1
If you'd prefer not disabling the OneDrive backup, you can try Zixin's answer, I am just not sure if you should mess up with the default settings of the backup folder and if it will cause problem.

Netbeans.conf: what is the variable for the user home?

When starting Netbeans, I need to add a system property named mEnvironment and set it as a sub-directory of the user's home. Example: In the netbeans.conf, I would like to add:
netbeans_default_options="-J-XX:+UseStringDeduplication -J-Xss2m -J-DmEnvironment=${USER_HOME}/mySubDirectory ......
USER_HOME is given as example of course.
Does someone know how Netbeans get the user home directory in the netbeans.conf file?
Thank you
Paul
Does someone know how Netbeans get the user home directory in the
netbeans.conf file?
The process is convoluted, and varies by operating system, but is described in great detail within netbeans.conf itself. This is the relevant content for my Apache NetBeans 11.1 installation:
# On Windows ${DEFAULT_USERDIR_ROOT} will be replaced by the launcher
# with "<AppData>\NetBeans" where <AppData> is user's
# value of "AppData" key in Windows Registry under
# "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders"
# and ${DEFAULT_CACHEDIR_ROOT} will be replaced by the launcher
# with "<Local AppData>\NetBeans\Cache" where <Local AppData> is user's
# value of "Local AppData" key in Windows Registry under
# "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders"
#
# On Mac ${DEFAULT_USERDIR_ROOT} will be replaced by the launcher
# with "~/Library/Application Support/NetBeans" and
# ${DEFAULT_CACHEDIR_ROOT} with "~/Library/Caches/NetBeans"
#
# On other systems ${DEFAULT_USERDIR_ROOT} will be replaced by the launcher
# with "~/.netbeans" and ${DEFAULT_CACHEDIR_ROOT} with "~/.cache/netbeans"
....
netbeans_default_userdir="${DEFAULT_USERDIR_ROOT}/11.1"
However, none of that really helps you, because you cannot access the values of netbeans_default_userdir or DEFAULT_USERDIR_ROOT; they are used internally by NetBeans itself, and are not System properties. You can verify this by displaying the values returned by System.getProperties(); none of the entries in netbeans.conf are shown.
Also, you can't meaningfully add new name/value pairs in netbeans.conf; you can only modify the values of the names used by NetBeans. That file is for NetBeans configuration, not user configuration. So if you add a line containing (say) MyConfSetting="ABC" then NetBeans will simply ignore that, and it won't be accessible to you either.
However, you can use an alternative approach to set a System Property for your directory in your application:
The read-only environment variable APPDATA points to your (operating system's) user directory. On my Windows 10 machine it has the value C:\Users\johndoe\AppData\Roaming.
The default user directory for NetBeans is the value of APPDATA + a sub-directory named NetBeans + a sub-directory named the NetBeans version. On my machine it is C:\Users\johndoe\AppData\Roaming\NetBeans\11.1. See the value of User directory in the Help > About screen for confirmation.
I don't know how to dynamically determine the version of NetBeans, but if that isn't important you can programmatically create a system property specifying your directory path:
String dir = System.getenv("APPDATA") + "\\NetBeans\\mySubDirectory";
System.setProperty("myDir", dir);
System.out.println("myDir=" + System.getProperty("myDir"));
On my machine that println() call displays myDir=C:\Users\johndoe\AppData\Roaming\NetBeans\mySubDirectory. I don't know if that approach meets your requirements, but I don't know of any other simple way to dynamically set your directory name.
Notes:
I checked this on Windows 10. Details may vary on other operating systems, but the overall approach should still work.
You can also specify parameters at run time using {project} > Properties > Run > Arguments (e.g. arg1=%APPDATA%\NetBeans\MyDir) and {project} > Properties > Run > VM Options (e.g. -Dvmopt1=%APPDATA%\NetBeans\MyDir), but that approach won't work because the %APPDATA% is simply treated as the literal "%APPDATA%" rather than evaluated as an environment variable.

Creating files at PSModulePath in batch

I am currently trying to write a batch program that installs a module named SetConsolePath.psm1 at the correct location. I am a beginner with Batch and I have absolutely no powershell experience.
Through the internet, I have learned how to display PSModulePath with powershell -command "echo $env:PSModulePath.
How can I, via .bat file, move SetConsolePath.psm1 from the desktop to the location displayed by powershell -command "echo $env:PSModulePath?
Thank you in advance, and I apologize for my lack of experience.
Before I answer, I must out that you do not want to copy PowerShell module files directly to the path pointed by PsModulePath. You really want to create a folder inside PSModulePath and copy the files there instead.
The prefix env in a Powershell variable indicates an environment variable. $env:PSModulePath is actually referring to the PSMODULEPATH environment variable. On the command line, and in batch files, environment variables can be displayed by placing the name between percent symbols. (In fact, you could have displayed this value by typing echo %PSMODULEPATH% instead.)
To reference the desktop folder, have a look at this answer, which shows you how to use another environment variable, USERPROFILE.
Therefore, to copy the file from the desktop directory to the path specified in PSModulePath, you would do this:
COPY "%USERPROFILE%\Desktop\SetConsolePath.psm1" "%PSMODULEPATH%"
And, as I warned earlier, you really should copy the file to a folder underneath PsModulePath. So what you really want is:
IF NOT EXIST "%PSMODULEPATH%\MyNewFolder" MKDIR "%PSMODULEPATH%\MyNewFolder"
COPY "%USERPROFILE%\Desktop\SetConsolePath.psm1" "%PSMODULEPATH%\MyNewFolder"

'findstr' is not recognized as an internal or external command,

I got the following error while starting JBoss from a command line prompt today:
'findstr' is not recognized as an internal or external command
Please google it, you can find a lot of answers. But do as below to fix it. Add the following value to Right Click My Compuer -> Advanced -> Environment Variables -> System Variables -> Select Path variable -> append the below value.
C:\WINDOWS\system32
It should work with that change.
As others pointed, issue is in wrong settings of PATH variable in Windows.
According to article this is most probably because some stupid installer wrongly modified PATH variable in Windows registry. Registry has 2 different string value types - REG_SZ and REG_EXPAND_SZ. Only the second one allows for expansion of %SystemRoot%.
So check your path by typing set path in command prompt. If you see unexpanded %SystemRoot% and other variables in Path, you are affected (PATH should show only plain directory names, not variables).
You need to edit Path variable in registry: HKEY_CURRENT_USER\Environment and HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment. As it is not possible to change the type of key, save the path value somewhere, delete the key and re-create it with type REG_EXPAND_SZ. You need to logout for changes to take effect.
for me it works when I've coped findstr(from windows/system32) to wildfly/bin
Please go throught the simplest steps:-
go to C:\Windows\system32\ and copy findstr.exe file.
paste this file into the location C:\Program Files\Java\jdk1.6.0_24\bin
Run your jboss again you will get out of this.....
Check to see if you %SystemRoot% is evaluating (type set path into a command prompt, you should not see %SystemRoot%, but instead that actual path). If your path variable's (user, or systems) first entry begins with an %(an environment variable) this can cause an issue.
To resolve this, simply swap this first entry with anything else in your path that does not lead with an environment variable.
You can also hard code the directory by replacing 'findstr' with 'C:\Windows\system32\findstr'. This is useful when using systems with restricted user permissions.
I have try to work with play framework but stuck with to run activator.bat file but solution is the same just copy file from windows/system32/findsr and past it to under stuck folder then run the respective file again.
thanks to andrewsiand Suryaprakash
Please beware that current Windows systems use a Capital "S" for the System directory, so:
C:\WINDOWS\System32
%SystemRoot%\System32
Omitting the capital S will result in a neglect of the line in the %PATH%
In my case (not JBoss related) the following helped to fixed this error.
Instead of:
SET path="%path%;C:\some\additional\path"
I used:
SET "path=%path%;C:\some\additional\path"
For IBM ACE solution for
'findstr' is not recognized as an internal or external command,
Go to the path C:\Windows\System32
Find the findstr.exe, copy it and then find the path where you bin file of your application is found. eg C:\Program Files\IBM\ACE\11.0.0.12\server\bin then past it inside the bin file
cancel the console of ace and re-open it.
Then run ACE toolkit command on ace console.
Then press enter, now it can open.

Where does CGI.pm normally create temporary files?

On all my Windows servers, except for one machine, when I execute the following code to allocate a temporary files folder:
use CGI;
my $tmpfile = new CGITempFile(1);
print "tmpfile='", $tmpfile->as_string(), "'\n";
The variable $tmpfile is assigned the value '.\CGItemp1' and this is what I want. But on one of my servers it's incorrectly set to C:\temp\CGItemp1.
All the servers are running Windows 2003 Standard Edition, IIS6 and ActivePerl 5.8.8.822 (upgrading to later version of Perl not an option). The result is always the same when running a script from the command line or in IIS as a CGI script (where scriptmap .pl = c:\perl\bin\perl.exe "%s" %s).
How I can fix this Perl installation and force it to return '.\CGItemp1' by default?
I've even copied the whole Perl folder from one of the working servers to this machine but no joy.
#Hometoast:
I checked the 'TMP' and 'TEMP' environment variables and also $ENV{TMP} and $ENV{TEMP} and they're identical.
From command line they point to the user profile directory, for example:
C:\DOCUME~1\[USERNAME]\LOCALS~1\Temp\1
When run under IIS as a CGI script they both point to:
c:\windows\temp
In registry key HKEY_USERS/.DEFAULT/Environment, both servers have:
%USERPROFILE%\Local Settings\Temp
The ActiveState implementation of CGITempFile() is clearly using an alternative mechanism to determine how it should generate the temporary folder.
#Ranguard:
The real problem is with the CGI.pm module and attachment handling. Whenever a file is uploaded to the site CGI.pm needs to store it somewhere temporary. To do this CGITempFile() is called within CGI.pm to allocate a temporary folder. So unfortunately I can't use File::Temp. Thanks anyway.
#Chris:
That helped a bunch. I did have a quick scan through the CGI.pm source earlier but your suggestion made me go back and look at it more studiously to understand the underlying algorithm. I got things working, but the oddest thing is that there was originally no c:\temp folder on the server.
To obtain a temporary fix I created a c:\temp folder and set the relevant permissions for the website's anonymous user account. But because this is a shared box I couldn't leave things that way, even though the temp files were being deleted. To cut a long story short, I renamed the c:\temp folder to something different and magically the correct '.\' folder path was being returned. I also noticed that the customer had enabled FrontPage extensions on the site, which removes write access for the anonymous user account on the website folders, so this permission needed re-applying. I'm still at a loss as to why at the start of this issue CGITempFile() was returning c:\temp, even though that folder didn't exist, and why it magically started working again.
The name of the temporary directory is held in $CGITempFile::TMPDIRECTORY and initialised in the find_tempdir function in CGI.pm.
The algorithm for choosing the temporary directory is described in the CGI.pm documentation (search for -private_tempfiles).
IIUC, if a C:\Temp folder exists on the server, CGI.pm will use it. If none of the directories checked in find_tempdir exist, then the current directory "." is used.
I hope this helps.
Not the direct answer to your question, but have you tried using File::Temp?
It is specifically designed to work on any OS.
If you're running this script as you, check the %TEMP% environment variable to see if if it differs.
If IIS is executing, check the values in registry for TMP and TEMP under
HKEY_USERS/.DEFAULT/Environment