I want to open a text file located on a network drive with notepad++ in Windows PowerShell.
I create the following PS1 file
Set-Location -Path "C:\Program Files\Notepad++\"
$Targetfile="\\server\path\myfile.txt"
.\Notepad++.exe $Targetfile
Error message : cannot find file
Can I run the following command in Windows PowerShell(Run exe file with path in PowerShell)
.\"C:\Program Files\Notepad++\notepad++.exe" "\\server\path\myfile.txt"
Note:
The answer below contains general information about invoking executables from PowerShell.
Your specific problem may be one of the following:
Executable Notepad++.exe may be missing from directory C:\Program Files\Notepad++
The target file may not exist or the server may not be reachable.
Note that prefixing an executable path with .\ (which refers to a file in the current directory) if that path is a full (absolute) path (as in your 2nd attempt.,
.\"C:\Program Files\Notepad++\notepad++.exe" ) is both logically pointless and fails in practice.
If Notepad++.exe is in one of the directories listed in the $env:PATH environment variable:
# Note: NO ".\" prefix, which is only needed to invoke an executable
# located in the *current directory*.
Notepad++.exe $TargetFile
If you need to reference it by its full path, there is no need to use Set-Location followed by a .\-prefixed invocation (unless you truly need the working directory to be Notepad++'s installation directory).
To call it by its full path directly, use &, the call operator:
& "C:\Program Files\Notepad++\notepad++.exe" $TargetFile
Note that & is required in this case, because your executable path is quoted, of necessity, due to containing embedded spaces. As the first command above shows, & is optional if the executable name or path is unquoted (and contains no variable references) - see this answer for more information.
Related
H:\>"H:\Program Files\R\R-3.4.0beta\bin\R.exe"
'H:\Program' is not recognized as an internal or external command,
operable program or batch file.
H:\>"H:\Progra~1\R\R-3.4.0beta\bin\R.exe"
The system cannot find the path specified.
H:\>H:\Progra~1\R\R-3.4.0beta\bin\R.exe
The system cannot find the path specified.
I tried using "..." and Progra~1 and both are not working on Windows 10.
What I'm doing wrong?
Short answer: Use & 'C:\path with spaces\app.exe'
Explanation: Just type your path into powershell and use TAB for auto completion when you choose any directory containing spaces. Powershell will automatically insert single quotes 'bla bla' and it will also put an & in front which is needed to treat the string as something that should be executed. Continue completing your path like usual.
The way to do this - and I can't believe I'm just now figuring this out - is to use Windows short names generated for files with non-8dot3 names. To get the path or program name in question, type dir /x <path to program>. It will spit out something like PROGRA~1 for Program Files folder. Of course you have to do that directory by directory, and if you have multiple files/folders with spaces in the name, it's cumbersome. If you want the full path formatted with short names, you can do:
for %I in (*) do echo %~sI
For example, if the file I want to access is C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\170\License Terms\License_msodbcsql_ENU.txt, I could type:
for %I in ("C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\170\License Terms\License_msodbcsql_ENU.txt") do echo %~sI
And what I get back is the much easier C:\PROGRA~1\MICROS~2\CLIENT~1\ODBC\170\LICENS~1\LICENS~1.TXT.
Annoying that you can't query the whole directory path without using a loop, but it is what it is. Good for aliases.
There may be an easier way with powershell, but I'm pretty sure there isn't from the cmd prompt.
you must be doing something wrong as the double quotes encapsulates the path to the executable including spaces.
To ensure you are doing it correctly, start typing the path to the command and use TAB after F:\Program until you see the correct path, in your case it will automatically do this
"F:\Program Files"
Use your arrow key to go back behind the end quotation and continue the path and use tab until you have reached.
"H:\Program Files\R\R-3.4.0beta\bin\R.exe"
You can also try and issue it with Start
start "H:\Program Files\R\R-3.4.0beta\bin\R.exe"
If Your cmd windows is open on the actual System drive where "Program Files" are located, you can run this instead of adding the drive letter as well:
".\Program Files\R\R-3.4.0beta\bin\R.exe"
Or add it to your environment variables with the path, then it should execute with just:
R.exe
I have a MS Word document whose path is set in the Environment variable.
How to open that document from Command line Utility?
"C:\Program Files\Microsoft Office\Office\Winword.exe" E:\hello.docx
I have the above command to open a document. But in the above command I have hardcoded the document's name and path.
All I want to do is to use an Environment variable to supply the document's name and path.
If you're open to using Powershell instead of the command prompt, you can complete with just a couple of setup steps.
First, create the environment variable for your word document. If you've already done this elsewhere, skip this step. Note that strings that are enclosed by double quotations will resolve variables, so in this example $env:username will resolve to your current Windows user. You could hard-code that too if you like, but this is helpful to generalize the example.
$env:WordDoc = "C:\Users\$env:username\Documents\myDocument.docx"
Next, you will need to add Office's directory to your path variable. You can search for winword.exe to find the location, but it will probably be one of the two below:
C:\Program Files\Microsoft Office\Office14
C:\Program Files (x86)\Microsoft Office\Office14
You can simply append that path to the environment variable, like so:
$env:Path += ";C:\Program Files\Microsoft Office\Office14"
Anyway, once that is set you can use winword from powershell to open word documents. Here's a simple example:
winword $env:WordDoc
A quick note about changing environment variables in this manner -- they are on the process level. That means that these changes will go away when you close your powershell session. Instead of typing them out each new session, you could save them to a powershell script and run that in the console. Here's a quick script that works on my machine:
param
(
[string]$FilePath
[string]$wordDir = "C:\Program Files (x86)\Microsoft Office\Office14"
)
$env:WordDoc = $FilePath
If(!($env:Path | Select-String -SimpleMatch $wordDir))
{
$env:Path += ";$wordDir"
}
winword $env:WordDoc
Doing this in the command prompt would involve a similar procedure -- you still need to set your PATH environment variable to recognize Microsoft Office. This answer offers some insight on how to do that.
If you mean from a batch file, and MS Word is properly associated with the .doc and .docx file extensions on your system, it's very simple.
Put the following in a batch file (for instance, C:\Temp\StartHello.bat). I've used DocVar to be the path and filename of the document; replace it with whatever your environmental variable is named.
set DocVar="E:\Hello.docx"
%DocVar%
Run it
C:\Temp>StartHello
If the environmental variable is already set, just remove the first line from the batch file that assigns it. This leaves you with a single line:
%DocVar%
If you mean "directly from the command line", you can just skip the batch file part:
C:\Temp>%DocVar%
after downloaded scala 2.10.2 for windows, and run scala I met such error:
"错误: 找不到或无法加载主类 scala.tools.nsc.MainGenericRunner"
which means "error: can't find or load main class scala.tools.nsc.MainGenericRunner". So I check the scala.bat for reasons, and I found such function:
:set_home
set _BIN_DIR=
for %%i in (%~sf0) do set _BIN_DIR=%_BIN_DIR%%%~dpsi
echo in set_home: %_BIN_DIR%
set _SCALA_HOME=%_BIN_DIR%..
goto :eof
After this function the _SCALA_HOME become D:\program files\scala\files\scala\bin\.., which is obviously wrong. Anyway, after setting _SCALA_HOME to be right path the error fixed. However, do any one knows what %~sf0 and %%~dpsi mean and what this function is really trying to do ?
Thank you!
thank you #gourlaysama
I finally found the real reason：execute the following code and you can see the result is :
for %%i in (%~sf0) do (
echo "%%"i is: %%i
echo sf0 is : %%~dpsi
set _BIN_DIR=%_BIN_DIR%%%~dpsi
)
output:
"%"i is: D:\program
sf0 is : D:\
"%"i is: files\scala\bin\scala.bat
sf0 is : D:\program files\scala\bin\files\scala\bin\
so the malfunction is result from the extra space between program files !
Those weird variables are called parameter extensions. they allow you to interpret a variable as a path to a file/directory and directly resolve things from that path.
For example, if %1 is a path to a file dir123456\file.txt,
%~f1 is the fully qualified path to file.txt,
%~p1 is the path to the containing directory dir123456,
%~s1 is the path in short name format dir123~1\file.txt,
and many others...
Also, %0 is always set to the path of the currently running script. So:
%~fs0 is the fully qualified path, in short name format, to the current script,
%%~dpsi is the manual expansion of the FOR variable %%i to a drive letter (d option) followed by the path the containing folder (p option), in short format (s option).
Now, this weird looking block of code is a workaround for KB833431 in which the %~dps0 command does not give you the path to the folder of the current script (in short format) although it should. This was fixed in XP SP2.
It seems to be reconstructing manually the fully qualified path to the scala bin directory from the fully qualified path to scala.bat, and then just getting that directory's parent, which should be a valid _SCALA_HOME.
If you are trying to create an environmental variable that doesn’t let you include spaces in the directory, you need to use Window’s shortened pathname.
Instead of “C:\Program Files\scala…”, use “C:\Progra~1\scala…”.
Instead of “C:\Program Files (x86)\scala…”, use “C:\Progra~2\scala…”.
OTHERWISE,
This guy found the solution:
https://issues.scala-lang.org/browse/SI-7821
Solution:
To make the changes he talks about to the batch files, download Notepad++
Then right-click on NotePad++ and select "Run as Administrator" or "Run as PowerBroker Administrator".
Open a new file in NotePad++
Navigate to your scala/bin/scala.bat file directory and select scala.bat
Change the code to what the above link says. So the final result should be this:
Make the changes to :add_cpath and :set_home for all the .bat files inside the scala/bin folder.
Now open command prompt and type "scala -version" or just "scala"
I got the same error after I installed Scala in the new volume formatted by Windows 10.
Workaround is to install Scala to the path without spaces. e.g. D:\scala
scala.bat uses 8.3 filenames to set up _SCALA_HOME, but 8.3 filename generation on NTFS volumes can be disabled by option (and it seems default now).
To check whether 8.3 filename generation is enabled, run dir /x and see if short file/folder names are displayed beside long names.
C:\>dir /x
2016/04/19 08:26 <DIR> PROGRA~1 Program Files
D:\>dir /x
2016/04/19 14:38 <DIR> Program Files
Or use fsutil 8dot3name command in the administrator command prompt (Replace D: with your installation drive. TechNet documentation):
fsutil 8dot3name query D:
When cvs is typed in cmd.exe in windows 7 nothing is output. The path of the cvs is already in the PATH :C:\Program Files (x86)\CVSNT\; When typing "C:\Program Files (x86)\CVSNT\cvs" there are outputs there. But when other .exe e.g. calc is typed the corresponding program can be executed. Any idea?
This might sound like a strange suggestion, but try cvs.exe instead of just cvs. Without specifying an extension, your operating system will search for the first file that matches the name, cvs. If it happens to find cvs.bat in one of your paths, then it will execute the .bat file instead of the.exe.
If you have cvs.bat , cvs.com, and cvs.exe within the same directory. The order of precedence would be the following:
cvs.com
cvs.bat
cvs.exe
I have a strong suspicion that there's a blank cvs.bat file hidden somewhere in one of folders defined in your path variable, and that you are actually running this batch file when you type cvs.
HI the answer is Run the exe with full path like "C:\Program Files (x86)\CVSNT\cvs.exe" followed by CVS arguments like -q Checkout.....
A configuration file needs position of another file,
but that file is located in "C:\Program Files",
and the path with space in it is not recognized,
Is there another way to specify the location without space in it?
you should be able to use
"c:\Program Files" (note the quotes)
c:\PROGRA~1 (the short name notation)
Try c:\> dir /x (in dos shell)
This displays the short names
generated for non-8dot3 file names.
The format is that of /N with the
short name inserted before the long
name. If no short name is present,
blanks are displayed in its place.
Never hardcode this location. Use the environment variables %ProgramFiles% or %ProgramFiles(x86)%.
When specifying these, always quote because Microsoft may have put spaces or other special characters in them.
"%ProgramFiles%\theapp\app.exe"
"%ProgramFiles(x86)%\theapp\app.exe"
In addition, the directory might be expressed in a language you do not know. http://www.samlogic.net/articles/program-files-folder-different-languages.htm
>set|findstr /i /r ".*program.*="
CommonProgramFiles=C:\Program Files\Common Files
CommonProgramFiles(x86)=C:\Program Files (x86)\Common Files
CommonProgramW6432=C:\Program Files\Common Files
ProgramData=C:\ProgramData
ProgramFiles=C:\Program Files
ProgramFiles(x86)=C:\Program Files (x86)
ProgramW6432=C:\Program Files
Use these commands to find the values on a machine. DO NOT hardcode them into a program or .bat or .cmd file script. Use the variable.
set | findstr /R "^Program"
set | findstr /R "^Common"
Use the following notations:
For "C:\Program Files", use "C:\PROGRA~1"
For "C:\Program Files (x86)", use "C:\PROGRA~2"
Thanks #lit for your ideal answer in below comment:
Use the environment variables %ProgramFiles% and %ProgramFiles(x86)%
:
I think the reason those suggesting using the C:\PROGRA~1 name have received downvotes is because those names are seen as a legacy feature of Windows best forgotten, which may also be unstable, at least between different installations, although probably not on the same machine.
Also, as someone pointed out in a comment to another answer, Windows can be configured not to have the 8.3 legacy names in the filesystem at all.
There should be a way to use the full c:\program files path directly. Often, it involves encapulating the string in quotes. For instance, on the windows command line;
c:\program files\Internet Explorer\iexplore.exe
will not start Internet Explorer, but
"c:\program files\Internet Explorer\iexplore.exe"
will.
The Windows shell (assuming you're using CMD.exe) uses %ProgramFiles% to point to the Program Files folder, no matter where it is. Since the default Windows file opener accounts for environment variables like this, if the program was well-written, it should support this.
Also, it could be worth using relative addresses. If the program you're using is installed correctly, it should already be in the Program Files folder, so you could just refer to the configuration file as .\config_file.txt if its in the same directory as the program, or ..\other_program\config_file.txt if its in a directory different than the other program. This would apply not only on Windows but on almost every modern operating system, and will work properly if you have the "Start In" box properly set, or you run it directly from its folder.
No.
Sometimes you can quote the filename.
"C:\Program Files\Something"
Some programs will tolerate the quotes. Since you didn't provide any specific program, it's impossible to tell if quotes will work for you.
I think that the other posts have answered the question, but just some interesting for your information (from the command prompt):
dir c:\ /ad /x
This will provide a listing of only directories and also provide their "Short names".
You could try to use:
C:\PROGRA~1
As an alternative to the other answers, you can try symbolic links.
Create the symbolic link first and install the application based on the link. (Depending on the case, this may be way easier to do, for instance when the application has n mentions of the target folder throughout its code)
A symbolic link will create something similar to a shortcut to a folder, but seen as an actual folder by other applications.
This is how you do it:
Run cmd as administrator
User this command: mklink /D "C:\LinkToProgramFiles" "C:\Program Files"
And then, you start using "C:\LinkToProgramFiles" in the applications that can't handle spaces. (This link can be seen in Windows Explorer as a folder with the symbol of a shortcut)
Be very careful not to create circular links if you start playing too much with this.
Try surrounding the path in quotes. i.e "C:\Program Files\Appname\config.file"
You can use the following methods to specify C:\Program Files without a space in it for programs that can't handle spaces in file paths:
'Path to Continuum Reports Subdirectory - Note use DOS equivalent (no spaces)
RepPath = "c:\progra~1\continuum_reports\" or
RepPath = C:\Program Files\Continuum_Reports 'si es para 64 bits.
' Path to Continuum Reports Subdirectory - Note use DOS equivalent (no spaces)
RepPath = "c:\progra~2\continuum_reports\" 'or
RepPath = C:\Program Files (x86)\Continuum_Reports 'si es para 32 bits.
Either use the generated short name (C:\Progra~1) or surround the path with quotation marks.
You can just create a folder ProgramFiles at local D or local C to install those apps that can be install to a folder name which has a SPACES / Characters on it.