So I'm aware that different operating systems require different classpath separators. I'm running a build of windows where CMD has been replaced with Powershell which is causing problems when using the semi-colon separator.
The command I'm trying to run begins with cmd /c to try and get it to run in command prompt instead but I think when PowerShell is parsing the whole command it sees the semi-colon and thinks that is the end!
My whole command is:
cmd /c javac -cp PATH1;PATH2 -d DESTINATION_PATH SOURCE_PATH
I have tried using a space, colon and period to no avail. Can anybody suggest a solution?
This is my first question on stackoverflow, hope the community can help and that it will eventually help others. :)
I suggest you start the process in the following way using Powershell
Start-Process cmd.exe -ArgumentList "/c javac -cp PATH1;PATH2 -d DESTINATION_PATH SOURCE_PATH" -NoNewWindow
Running javac in CMD shouldn't be required. Just put quotes around arguments that (may) contain whitespace or special characters. I'd also recommend using the call operator (&). It's optional in this case, but required if you put the executable in quotes (e.g. because the executable or path contains spaces or you want to put it in a variable).
& javac -cp "PATH1;PATH2" -d "DESTINATION_PATH" "SOURCE_PATH"
You could also use splatting for providing the arguments:
$javac = "$env:JAVA_HOME\bin\javac.exe"
$params = '-cp', "PATH1;PATH2",
'-d', "DESTINATION_PATH",
"SOURCE_PATH"
& $javac #params
javac -classpath "path1:path2:." main.java does the trick in powershell. the cmd doesn't need the doble quotes however while using powershell we need to put the quotes and it works smoothly.
Related
Ex:
cmd /C start C:\Users\Bob Builder\Desktop\New Folder\test.exe
I'm trying to use cmd to start a file but since there are spaces in the path, cmd is throwing an error after Bob.
Error:
"Windows cannot find C:\Users\Bob. Make sure you typed the name
correctly, then try again."
The system cannot find the file C:\Users\Bob.
Its simply failing to accept the spaces. It's driving me crazy because I'm spoiled with C# working out of the box. I don't know much about this, I have been spending way too much time trying to figure this out. Some help would be greatly appreciated.
In order for a path that contains spaces to be recognized as a single path (argument), it must be quoted.
In order for an executable to execute in the current console window, synchronously, with its streams connected to the calling shell, it must be invoked directly, not via start.
Direct invocation from cmd.exe (only "..." quoting supported):
"C:\Users\Bob Builder\Desktop\New Folder\test.exe"
From PowerShell:
& 'C:\Users\Bob Builder\Desktop\New Folder\test.exe'
Note:
PowerShell also supports '...' strings (single-quoted), which are verbatim strings that are preferable to "..." (double-quoted) ones if you do not require expansion of variables (string interpolation) - see the conceptual about_Quoting_Rules help topic.
For syntactic reasons, PowerShell requires the use of &, the call operator to invoke commands that are quoted and/or contain variable references - see this answer for details.
By contrast, use start in cmd.exe / Start-Process in PowerShell (whose built-in alias is also start) to launch an executable in a new window (on Windows), asynchronously, with no (direct) ability to capture the launched executable's output:
From cmd.exe:
start "title" "C:\Users\Bob Builder\Desktop\New Folder\test.exe"
Note:
Specifying "title" - i.e. a self-chosen (console) window title - is required for syntactic reasons in this case: without it, the double-quoted path itself would be interpreted as the window title, and the - implied - executable to launch would be another cmd.exe instance.
Note that if you launch a GUI application this way, the title argument is irrelevant, because no new console window is created.
Conversely, if you launch a console application specified by double-quoted path and therefore must use a title argument, note that "" will result in the new window having no title.
From PowerShell (parameter -FilePath is positionally implied):
Start-Process 'C:\Users\Bob Builder\Desktop\New Folder\test.exe'
Note:
Start-Process does not support specifying a window title, so you may want to call cmd.exe's internal start command for that (or other features not supported by Start-Process, such as specifying the process priority).
To work around quoting problems, invoke cmd.exe's start from PowerShell by passing the entire start command as a single string to cmd /c:
cmd /c 'start "title" "C:\Users\Bob Builder\Desktop\New Folder\test.exe"'
cmd /C start "C:\Users\Bob Builder\Desktop\New Folder\test.exe"
Quotes are your friend. Sometimes even double quotes are too!
Seems like cmd won't work for me. Powershell worked with this script:
$env:Path += ";C:\Users\Bob Builder\Desktop\New Folder\"
test.exe
I have a line that works in cmd prompt but I cant convert it to work powershell, I can run it without errors in powershell but it doesnt function how it does in cmd prompt
"C:\Program Files\Curl\curl-7.69.1-win64-mingw\bin\curl.exe" -F file=#C:\Documents\some.txt http://localhost/fileupload.php
I fixed it in case anyone comes across this one day
. ""C:\Program Files\Curl\curl-7.69.1-win64-mingw\bin\curl.exe"" -F ""file=#C:\Documents\some.txt http://localhost/fileupload.php""
I think your file=#C:\Doc... needs quotations. file=#"C:\Doc..."
Here's my working directory:
C:\GitHub\
And under this directory I have:
class\ src\ cmain
and cmain is my argument file.
All my .java source code files are undersrc\
main.java CalcHandler.java
And here's the content ofcmain
-cp .\class\
-sourcepath .\src\
-d .\class\
.\src\main.java
But when I tried compiling src\main.java in PowerShell usingcmain, it is not recognized:
PS C:\GitHub> javac #cmain
Usage: javac <options> <source files>
where possible options include:
-g Generate all debugging info
-g:none Generate no debugging info
....
I tried this in Linux and it worked fine, contents were exactly the same.
What should I do to make it work?
Edit: Apparently this is PowerShell's fault, it worked in command-prompt. But still I'd like to hear from you about how to make it correct in PowerShell.
javac '#cmain'
PowerShell parses arguments to commands, and #cmain means taking the array $cmain and expanding it to one argument per item (splatting). By passing an explicit string you can bypass that automatism.
Other options:
javac --% #cmain
This will tell PowerShell to stop parsing arguments after the --% marker and just pass them verbatim to the other program.
javac `#cmain
This will escape the # so its special behavior will not apply.
Always remember that shell features will need workarounds if you want to pass that syntax to other programs. That's no different than % expanding environment variables in cmd, or most shells tokenizing arguments at spaces and other whitespace. A small utility program that just prints its arguments can come in handy for diagnosing such cases.
I wish to run the command:
mocha -i -g 'database|network|skip'
With the pipe being part of the arguments to mocha. However powershell thinks 'network' is a program that I am trying to pipe to:
network : The term 'network' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path
was included, verify that the path is correct and try again.
Some research mentioned the --% operator to stop Powershell parsing
STOP PARSING: --%
The stop-parsing symbol (--%), introduced in Windows PowerShell 3.0,
directs Windows PowerShell to refrain from interpreting input as
Windows PowerShell commands or expressions.
however running:
mocha --% -i -g 'database|network|skip'
Still gives the same error. Which makes sense, since:
The stop-parsing symbol is effective only until the next newline or
pipeline character.
How can I run a command with a pipe symbol in powershell?
Edit: Image attached for person who refuses to believe me even after issue has been replicated, and answered by two people:
Using an example with find you will get similar results.
find /c "this|that|andtheotherthing" C:\temp\EventCombMT.txt
find : FIND: Parameter format not correct
At line:1 char:1
+ find /c "this|that|andtheotherthing" C:\temp\EventCombMT.txt
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (FIND: Parameter format not correct:String) [], RemoteException
+ FullyQualifiedErrorId : NativeCommandError
Pretty sure this is because the quotes are consumed by the PowerShell interpreter and that leave your mocha command with an unquoted string. Doubling up the quotes is another was to prevent this.
find /c '"this|that|andtheotherthing"' C:\temp\EventCombMT.txt
It seems this is not the case with mocha? In comments it was determined that we need to reverse the quote set from that seen in the find examples.
There are better ways to call external commands as you have seen in your linked post. Like using the call operator and a hashtable. You would still have to address the quotes though. You could escape a set of double quotes as well to get a similar effect.
find /c "`"this|that|andtheotherthing`"" C:\temp\EventCombMT.txt
For this to be correct though it does not really match the error you are getting. While I am correct about a solution I might be wrong about my interpretation of the issue. PowerShell should not care about the pipe character regardless of how it is quoted. That is what the quotes are for.
Thanks to PowerShell and external commands done right. You can quote the pipe character to stop powershell treating it as a pipe. In this case:
mocha -g 'network"|"database"|"skip'
Works perfectly. As #matt has since mentioned, you can also run the (much neater):
mocha -i -g '"database|network|skip"'
I am using mr on Windows and it allows running arbitrary commands before/after any repository action. As far as I can see this is done simply by invoking perl's system function. However something seems very wrong with my setup: when making mr run the following batch file, located in d:
#echo off
copy /Y foo.bat bar.bat
I get errors on the most basic windows commands:
d:/foo.bat: line 1: #echo: command not found
d:/foo.bat: line 2: copy: command not found
To make sure mr isn't the problem, I ran perl -e 'system( "d:/foo.bat" )' but the output is the same.
Using xcopy instead of copy, it seems the xcopy command is found since the output is now
d:/foo.bat: line 1: #echo: command not found
Invalid number of parameters
However I have no idea what could be wrong with the parameters. I figured maybe the problem is the batch file hasn't full access to the standard command environment so I tried running it explicitly via perl -e 'system( "cmd /c d:\foo.bat" )' but that just starts cmd and does not run the command (I have to exit the command line to get back to the one where I was).
What is wrong here? A detailed explanation would be great. Also, how do I solve this? I prefer a solution that leaves the batch file as is.
The echo directive is executed directly by the running command-prompt instance.
But perl is launching a new process with your command. You need to run your script within a cmd instance, for those commands to work.
Your cmd /c must work. Check if you have spaces in the path you are supplying to it.
You can use a parametrized way of passing arguments,
#array = qw("/c", "path/to/xyz.bat");
system("cmd.exe", #array);
The echo directive is not an executable and hence, it errors out.
The same is true of the copy command also. It is not an executable, while xcopy.exe is.