When I create and open a file with vim, i.e. "vim new.txt" it works fine in a folder like my desktop. However, when I am in "C:\Program Files (x86)\Vim\vimfiles\ftplugin\" and I try to create a file with "vim python.vim" or "vim new.txt", vim opens and appears to work fine, but after I save the file and exit vim, it does not exist in the folder. HOWEVER, if I type "vim python.vim" again to re-open the (apparently non-existent) file, vim comes up happily right where I left off in the file that doesn't exist. Can someone tell me what is going on and how to fix it?
Edit: A search of my filesystem for the nonexistent files shows them to in "C:\Users\Daniel\AppData\Local\VirtualStore\Program Files (x86)\Vim\vimfiles\ftplugin" instead of the "C:\Program Files (x86)\Vim\vimfiles\ftplugin\" from which they were created. Any ideas why, though, and how to make this not happen?
What you're experiencing is the file system redirection of the %ProgramFiles% location (the same is done for the Windows system files under %WINDIR%), because you're not running under an elevated account. Starting with Windows Vista, when User Account Control (UAC) is enabled, you cannot directly access system files and installed applications any more (for security reasons). Windows detects software installers and prompts you to elevate the account, but it doesn't detect Vim's accesses, and (for backward compatibility) redirects those accesses to the VirtualStore.
There are several ways around this:
Turn off UAC (bad idea, lower security)
Start an elevated instance of GVIM (search for gvim in the Start Menu, and select with Ctrl + Shift + Enter), and edit with that.
Avoid the problem by creating a vimfiles directory at %HOME% (C:\Users\Daniel for you) instead of $VIM/vimfiles and put your config there (see :help vimrc).
Related
I really like coding in bash, but there used to be many limitations of bash functionality in Windows. Though now there are many benefits to the bash windows users now rather than how it was pre windows 10. However, with all of the improvements, there is one thing that I feel leaves to be desired for me. The default behavior of the double-click of .sh files never really was able to do anything in windows, the .sh file extension isn't even available in the "choose default apps by file type" section of the settings. I had a desire to be able to change the default action for .sh files but neglected it and shook it off for a while, but this link finally gave me hope.
Before Ubuntu terminal and the addition of Windows subsystem for Linux, there was really no way to access bash terminal on Windows without a VM. Now with the addition of Windows Terminal which combines Microsoft Azure Terminal, Command Prompt, Powershell, and Ubuntu, it is really awesome for people like me, but despite the new awesome additions to windows allowing further integration of Linux terminal into Windows, even being able to edit the C: drive with Ubuntu.
I am sure there is a way to allow double-click of .sh files to open in windows terminal Ubuntu, but I don't know how. This question helped me on my journey to figure out how to do it and helped me make the default .bat file behavior change to Windows terminal, but I still have come to an enpass where I truly believe that it is not possible. So here is where I go when I have given up, the magical land of Stack Overflow :)
Attempts
So far I have looked into the "Choose default apps by file extension" section of settings and could not find .sh in there nor could I find it in any of the default apps sections of normal settings.
After I couldn't find anything about .sh in settings, I looked into the registry and looked for HKEY_CLASSES_ROOT and looked for sh or anything bash file related in HCR alone, HCR\*\shell, HCR\*\shellx, and HCR\*\Openwithlist and could not find anything.
I then tried to do ftype, but I could not find how to use ftype with .sh. I tried doing ftype .sh="C:\Users\asian\AppData\Local\Microsoft\WindowsApps\wt.exe" -p "Ubuntu" "%1" %* but i got the error "File type '.sh' not found or no open command associated with it."
I Also tried just clicking the .sh file so it brings up the "How do you want to open this file" menu and went to Windows Terminal but it opened the bash file in powershell with the error [error 0x800700c1 when launching `C:\Users\asian\Desktop\test.sh']
These where everything I could think of and none of it was working. Help and pointers are appreciated. Thank you!
I suggest you install the Git for Windows package, as it comes with a light-weight bash environment. This is likely to be able to be in the list of available apps when right-click -> Properties on a .sh or .bash file and say Open With and click the Change button next to Open With.
Other options are Cygwin or WSL for a 95% pure Linux environment on Windows.
This works (Notepad++):
C:\Anywhere> start notepad++ hello.txt
And this works (SoX for removing silence in sounds):
C:\Anywhere> sox in.wav out1.wav silence 1 0.1 1%
Yet, my PATH variable includes neither (would send on request).
How can I do this with my program?
To run from everywhere.
Also, why doesn't Notepad++ work without the start command?
(I did this workaround by putting the .exe in C:\ and then simply calling C:\Anywhere> /myprogram but I'm still curious about the above.)
To get the indicated scenario where
you can start applications from anywhere using the start command (or the windows Run dialog) without including its parent folder in path variable,
but you can not start the application without the start command from any directory whithout including the full path to reach it (it is not in the path) or being located in the adecuated directory
the applications are included in the registry under the key
HKEY_CLASSES_ROOT\Applications
note: It is a "merged" view showing the combined contents of
HKEY_LOCAL_MACHINE\Software\Classes\Applications
HKEY_CURRENT_USER\Software\Classes\Applications
If you are not administrator to change the local machine configuration, you can always modify your user registry information to include the applications you need.
edited There is a second place in registry that will allow to include an application in the registry to be executed using start command, Run dialog or from anything that uses the ShellExecute or ShellExecuteEx API calls.
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\
My goal is to add a few executables to my PATH (for example, chrome), so that I can call
> chrome
from the command prompt and it will launch Chrome.
I know I could add Chrome's containing directory to my path (set PATH=%PATH%<chrome_path_here>;), but since I have a few executables I want to add, I'd rather make a new bin directory that contains symbolic links to the actual executables and just add that single directory to my PATH.
The Chrome executable is located at
C:\Program Files (x86)\Google\Chrome\Application\chrome.exe
So I tried
> mklink chrome.exe "C:\Program Files (x86)\Google\Chrome\Application\chrome.exe"
That successfully creates a symbolic link for the files (says so in output, and upon examining with > dir). I know my PATH is set up correctly, b/c when I run > where chrome it finds my new symbolic link.
However, when I try to execute chrome with my new link, nothing happens. A new empty window should appear, but nothing happens. No error message in the command prompt or anything.
What am I doing wrong? Am I misunderstanding symlinks in Windows? This is the approach I use in Linux all the time, but I'm new to Windows Cmd.
Thanks!
Most programs will not run from places other than they install location - which is exactly what happens when you try to run it from symlink.
It would be much easier to create CMD/BAT files in that folder with matching names which will launch programs from locations you want:
REM chrome.cmd
start /b cmd /c "C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" %*
With Windows 7 I confirm that symlinks do not work, are simply ignored as reported in the original question.
As Harry states in his comment, shortcuts do work, and to me are simpler and easier than writing a separate script for each new command I want to enable under CMD.
He states that you need to add .lnk to your PATHEXT variable in order to do this. I affirm that this does work, and with .lnk added to PATHEXT I can simply enter the name portion of the shortcut to run the command. For example if my shortcut is named "sublime.lnk" and PATHEXT includes .lnk, I can execute the link with the simple command "sublime". Nice!
As an alternative I found that PATHEXT need not be modified if I simply type in the full name of the shortcut, including the .lnk, at my CMD prompt. E.g., I created a shortcut named "sublime.lnk" under %HOMEPATH%/bin, pointing to "C:\Program Files\Sublime Text 2\sublime_text.exe".
Now by placing %HOMEPATH%\bin in my %PATH% I can run sublime via the command "sublime.lnk".
Either of the above are the best way I know of giving access to various commands from around Windows' filesystem from a CMD prompt. I'm not a Windows expert though, and welcome a better or more standardized solution to this problem.
P.S.: I just found out the hard way that you need to ensure the "Start in:" property of any shortcut you use in this fashion is blanked out, or your program will not start in the directory you invoke the shortcut from.
P.P.S.: On a related note, I discovered how to run Windows Explorer (or its replacement) on the directory your CMD session is logged in to: start ..
some bat files need to be launched at the start of the session, but they don't.
Actually, when trying to launch one from the explorer, it opens the Open with window instead of just runnig.
However, the bat files still run correctly from the command prompt.
I bet it has been caused by a virus, but the antivirus did not detect anything unfortunately.
Any idea?
Use the Open With command, select cmd.exe, then before you hit OK, check the box that says "always use this program to open this type of file" or something similar.
If cmd.exe is not in the choices, browse to c:\windows\system32, and cmd.exe should be in there.
You can re associate the extension by downloading the reg file for batch from the link below which should solve your problem.
http://www.dougknox.com/xp/file_assoc.htm
I need suggestions about a setup CD layout for non technical users.
My software is deployed on a CD with a setup.exe bootstrapper and a MSI file. There are also several dependency files used by the installer. The CD root looks something like this:
myapp.msi
setup.exe
sqlexpr32.exe
dotnetfx.exe
myapp.ico
...
It is not rocket science for a developer guessing that the file you need to run in order to begin the installation is setup.exe.
But my users are definitely not as tech-savvy.
I have included an autorun.inf file, but I have found after testing in several machines that most of them do not automatically launch the setup. For whatever reason. In some machines somebody has disabled autorun, or some antivirus software, or whatever. The thing is that I cannot rely on autorun being available at all times.
So I'm thinking making changes to the CD layout in order to make more obvious which file has to be run.
One option is to make a new Install.exe program that just launches the original bootstrapper, and moving everything to a folder in the root of the CD:
autorun.inf <-- launches Install.exe, if autorun is enabled for the drive.
Install.exe <-- launches contents/setup.exe
contents/myapp.msi
contents/setup.exe
contents/sqlexpr32.exe
contents/dotnetfx.exe
contents/myapp.ico
contents/...
As I cannot yet rely on the .net framework being present, I cannot use .net to make my Install.exe and that is kind of annoying.
Other option is making a Install.bat but most users are not familiar with the .bat extension and might not think about double-clicking it. And the user would see a command prompt window.
Other option is making a self-extracting exe and compressing everything inside, so the only files in the CD would be the autorun.inf and the self-extracting file.
What would you do?
Other option is making a Install.bat but most users are not familiar with the .bat extension and might not think about double-clicking it. And the user would see a command prompt window.
You could create a shortcut to the Install.bat and give it a pretty icon and a nicer name. You can also make it start minimised, so they probably wouldn't notice the command prompt appearing briefly.
EDIT: (By Sergio Acosta)
I found out how to solve the relative path issue:
This is how the shortcut should be configured:
Target: %windir%\system32\cmd.exe "/C start contents\setup.exe"
Start in: %cd%
Run: Minimized
Icon: %SystemRoot%\system32\SHELL32.dll (and manually select the one that looks like a setup package.
I have tested it and it works.
Keep it simple, instead of thinking to much of the layout, go by conventions and leave the setup.exe or install.exe and provide a README.txt file where they can find installation instructions. Most users will choose install.exe or setup.exe and other will probably read the txt.
Put a big sticker on the CD that reads "Run Setup.exe".
I think that the simplest option you have mentioned, to make a new Install.exe program that just launches the original bootstrapper, and having nothing else except the Autorun at the root of the CD, is the best choice.
One icon = no options. Can't really do better than this.
Though I like the solution with the shortcuts, it may be an alternative also to use the free "Bat To Exe Converter".
This way your users will see a standard-looking EXE with any custom icon you want. Plus you can configure it to be run invisible so there won't even be a minimized CMD box.