I am looking for the shortest command that would download a file (http) and execute it on Windows.
We assume that the user executing the command is local Administrator and that you cannot use any tools that are not available by default on Windows.
It must work with: Windows 7 and Windows 2008. Extra kudos if someone gives a solution that also works with Windows XP and Windows 2003.
Reasoning: that for deploying stuff on different Windows machines. Using WMI or other methods is not an option because these are not enabled by default and also because machines can be inside our outside a domain, which makes the problem more complex, especially.
Note: If this cannot be done in a command line, a script will do. Let's assume that the file to be downloaded is located at "http://example.com/setup.exe" and that you want to run it with "-y" parameter after it is downloaded.
You specified http, so using ftp command in command line would not be ok? Maybe cscript + VB then?
To download file:
https://serverfault.com/questions/29707/download-file-from-vbscript
To run file:
Set objShell = WScript.CreateObject("WScript.Shell")
objShell.Run (strHDLocation & "-y")
Related
I downloaded and installed the program "cppcheck" (http://cppcheck.sourceforge.net/).
This program has both a GUI (which I can access without problems) and a command line interface.
However, when I go to the windows command prompt and type "where cppcheck", nothing can be found.
Am I crazy? Or is the command line interface for cppcheck only accessible on Unix systems?
Since I usually don't work with Windows, I didn't realise that the "where" command just looks in the current folder and child folders of the current folder. That's why I didn't get any results.
You have to add it in the environment variables since the cppcheck installer does not add it automatically. This way you can use the where command from any folder as it also checks the environment variables too.
I'm having trouble deleting zone files using scripts from
c:\windows\system32\dns
If I delete using a vbscript, the zone is removed from the DNS server, but the zone file (.dns) remains with Windows saying "The system cannot find the file specified". I have tried this using powershell and ASP.net, but all with the same result.
However, if I try directly from the command line on the console, it works fine, so something appears to be 'hiding' the files in c:\windows\system32\dns to prevent script access, but I don't know what. Anyone else seen this and have ideas?
It's Windows 2012 R2.
Dim ObjExecutor : Set ObjExecutor = CreateObject("ASPExec.Execute")
ObjExecutor.Application = "dnscmd localhost /ZoneDelete domain.com /f"
ObjExecutor.ExecuteDosApp
ObjExecutor.Application = "cmd /c del c:\windows\system32\dns\domain.com.dns"
ObjExecutor.ExecuteDosApp
set ObjExecutor = nothing
Found the answer to this, it's because of 32 bit requests redirecting to the syswow64 folder, so I had to change the site to compile into 64-bit, and it worked fine.
I would suggest using Remove-DnsServerZone from Domain Name System (DNS) Server PowerShell Cmdlets here. I've used them before and they've worked wonderfully for me.
I am working on Windows 7 (logged in as session no.1), my Jenkins CI is running as windows service in session 0.
My problem is.. I want to open an Excel file through Jenkins CI in session 0, but want to display its GUI on session 1.
I know that session 0 is isolated in Windows 7, but is it possible to run a process in session 0 and then output in another session? please help.
Edit:
Took a little trial and error, but this is what finally worked for me (Windows 7 64-bit).
Download PsTools from Microsoft site
We only need psexec.exe, but you can extract everything. Extract to some location accessible by Jenkins, preferably without spaces in the path.
Open elevated command prompt: type cmd into Start's quicksearch, right click cmd.exe, select Run as Administrator.
Type C:\path\to\psexec.exe -accepteula and press enter.
Type C:\path\to\psexec.exe -i 1 cmd and press enter. (If you see a command prompt appear, all is good, close it now)
In Job configuration, configure Execute Windows Batch command step
Write the following:
C:\path\to\psexec.exe -accepteula && C:\path\to\psexec.exe -i 1 cmd /c start C:\PROGRA~2\MICROSO~1\path\to\excel.exe
Where:
C:\path\to is your full path to psexec.exe, unless it is in your %path%
-i 1 is the session ID that you want to launch in.
C:\PROGRA~2\MICROSO~1\path\to is your full path to excel.exe without spaces. Since most Office installations are going to be under paths with spaces, like "Program Files (x86), you have to figure out the short path, or place it somewhere without spaces.
Having excel.exe under %path% and working from regular command line was not enough.
A little explanation for those that care:
psexec needs to install a services first. For that, it needs to be run from elevated command prompt for the first time. This is a one-time installation step.
To make psexec work, you need to accept the EULA prompt. This is done per session/user. So even if you run psexec -accepteula in your command prompt, it doesn't help when Jenkins service (running as Local System in session 0) tries to use it. Therefore, you have to place that into the Jenkins job, along with the command. Technically, it only needs to be there once, and can be removed afterwards, but it definitely doesn't hurt to keep it there.
I've used cmd /k and running this command from my local cmd prompt to debug. This is what made me realize I couldn't find a way to escape the spaces (tried various quoting), so had to resort to short file names. Note that short file names are not required, this is just to escape spaces.
no its not-
plus any UI interactions requires you to run Jenkins as Java web start rather than a service or you can not interact with UI elements.
I have installed ActivePerl on my Windows OS. I have followed below URL
procedure to install
ActivePerl Installation
After having done that, I have tried to run "perl -v " on the command line. But it reports the following error.
The system cannot execute the
specified program
What do I need to do to solve these issues?
I was facing a similar issue... but the thing was that I could execute the file by right clicking the file and opening it with perl command line interpreter.... but still the perl-v command would give the error... all I had to do was execute this command
set PATH=C:\Perl\bin;%PATH%
This solved the issue...
You need to make sure the directory where the Perl executable lives (it might be C:\perl\bin, but basically wherever you told ActiveState Perl to be installed) is in your PATH environmental variable (you can find the variable value by typing set PATH command on command line prompt in Windows).
If you're not sure where you installed Perl to (and can't find it in the default C:\perl\bin), you can find the directory by going to Start menu, finding ActiveState Perl folder, and right-clicking on "Perl Package Manager" icon, then pick "Properties" from the right-click menu. Properties window (in the "Shortcut" tab) will have a "Target" line showing the directory.
I was getting a similar error after installing ActiveState Perl on Windows 8 x64 bit edition and trying to invoke 'perl' at the command line.
'perl' is not recognized as an internal or external command, operable
program or batch file.
I remember selecting the option during installation to add the Perl directory to the system PATH environment, and after checking the system properties, it was indeed showing in the system PATH.
I tried installing 'Microsoft Visual C++ 2008 x86 and x64 redistributable setup' files as suggested by a few places but it still did not resolve the issue, until I tried some of the suggestions in this thread.
At the command prompt I entered:
set PATH
And surprisingly it did not list the Perl directories as being included in the PATH variables.
So to remedy that I entered this into the command prompt and hit enter:
set PATH=C:\Perl64\bin;C:\Perl64\site\bin;%PATH%
(The directory paths are for the 64 bit edition of Perl, adjust according to your installation) the %PATH% portion is important and ensures your existing settings are kept and not wiped out and overwritten when you set the PATH.
That fixed it and entering 'perl -v' into command prompt successfully replies your Perl version. If you had a PowerShell window open before setting the PATH variable, you will need to close it and re-open another instance of PowerShell.
I believe the original underlying issue was something to do with different PATH variables for 32-bit and 64-bit environments and possibly some internal Windows redirection that takes place automatically.
This doesn't sound like a problem with PATH - I would expect it to give the message 'perl' is not recognized as an internal or external command, operable program or batch file.
I have not seen this error message, but http://nirlevy.blogspot.com/2008/03/system-cannot-execute-specified-program.html makes some suggestion for related programs.
Or maybe ask on an Active State forum.
I had the same error. I was able to solve it by changing the order of the Perl64 entries in the PATH variable in the Environment Variables. I moved the C:\Perl64\bin to be before C:\Perl64\site\bin and it worked.
I had a similar error which was solved by adding the .pl extension to the script name, which I had forgotten to do.
I could not get it to work otherwise even with my Perl's location (C:\Apps\Perl\bin) verified as in %PATH%.
The problem lies in the installation directory.
The Perl PATH variable will be set to C:\Program Files\perl (depends on 32 or 64 bit of course), BUT, the default installation directory is C:\perl. This is kind of sneaky actually as you would assume the installer would be more intelligent about this, but it sets the environment variable to that directory no matter WHERE you install the damned thing.
I have created a batch file to run an application automatically but it seems my CMD does not run it. I typed this (using notepad as an example):
CMD /C "C:\notepad2\notepad2.exe"
If I run this from Windows Vista it worked. But running this from Windows Server 2008 (64-bit) it just doesn't work. I even try using that line from the Run menu but no go.
What do I do? My aim is to run a scheduled task that runs the batch file every now and then.
Stupid question, but does the program you're trying to run actually exist on the Server 2k8 machine?
There are no differences in cmd between Vista and Server 2k8 whatsoever.
Besides, why do you need to execute it via cmd? Can't you just run the application directly? Using cmd /c is only necessary for shell built-ins, such as dir or start.
Also remember that there is no NTVDM on 64-bit Windows—you can't run 16-bit programs. I doubt one would still use them nowadays but it may be the only thing I can think of why it doesn't work in 64-bit.