none
When do you have to prefix a command with cmd /c ? RRS feed

  • Question

  • I have a task sequence that runs all sorts of commands like exes, batch files, vbscripts, net share...etc

    When do you have to use cmd /c to prefix a command and when is it not necessary please?

    Thanks

    David Z
    Monday, June 17, 2013 2:17 AM

Answers

  • You only need to do this when the command is internal to cmd.exe. If you can find the .exe file then you don't need cmd /c.

    Two examples are.
    cmd /c copy foo bar
    xcopy foo bar

    Here the copy command is internal to cmd.exe. While xcopy is actually a file named xcopy.exe.

    If it's a batch file you don't need to use cmd /c.

    A quick test to see if the command is internal to cmd is to use the Windows run box. If you type 'copy' you should see an error about file not found. But if you type 'xcopy' a dos-box window flashes by.

    Monday, June 17, 2013 7:46 AM

All replies

  • You only need to do this when the command is internal to cmd.exe. If you can find the .exe file then you don't need cmd /c.

    Two examples are.
    cmd /c copy foo bar
    xcopy foo bar

    Here the copy command is internal to cmd.exe. While xcopy is actually a file named xcopy.exe.

    If it's a batch file you don't need to use cmd /c.

    A quick test to see if the command is internal to cmd is to use the Windows run box. If you type 'copy' you should see an error about file not found. But if you type 'xcopy' a dos-box window flashes by.

    Monday, June 17, 2013 7:46 AM
  • There is another scenario where cmd /c comes in handy which I learned today.

    It is possible to use control.exe to change language settings.
    However it will always return code 1 when running in MDT environment, despite of no errors.
    As a warkaround you can use cmd /c start "NAME" PATH which should always return the desired 0.
    The log for the copy process of the imported file should be enough for debugging purposes,
    with programs returning such useless error codes.

    Monday, June 17, 2013 6:44 PM
  • There is another scenario where cmd /c comes in handy which I learned today.

    It is possible to use control.exe to change language settings.
    However it will always return code 1 when running in MDT environment, despite of no errors.
    As a warkaround you can use cmd /c start "NAME" PATH which should always return the desired 0.
    The log for the copy process of the imported file should be enough for debugging purposes,
    with programs returning such useless error codes.

    Yes, cmd return 1 if current path is an unc path.

    I always use the magic variable %~dp0 in my batch script so the batch file can be started from a network unc path.

    Example:

    You have two files
    \\servername\share\path\some file.msi
    \\servername\share\path\myinstaller.cmd

    Content of myinstaller.cmd
    msiexec /i "%~dp0some file.msi" /qn /norestart /l*v "%WinDir%\Temp\Some log.txt"

    Perhaps not the best example since you could do this use this in MDT only. Another thing you shuld know about; if MDT is about to run a batch file it mount a network drive before executing. So if the application on a later date needs the installation source, it will look for a network drive that is not there anymore.

    Tuesday, June 18, 2013 6:59 AM
  • I had no issue with cmd.exe returning the value 1, but with control.exe.

    There have to be some serious issues in the error code logic for control.exe causing this behaviour.
    I could not find anyone who has it working without embedding the command into some kind of script when running from MDT.

    The feature with the installation source should only apply for msiexec packages and nothing to do with batch files.
    I have implemented a workaround which allows me to repair all installed packages, using the local Deploymentshare as Network location. If a computer moves site this reference can be easily changed.
    This can be done by specifying Sourcelist as an installer property for all installations.

    Thanks for the information about the error 1 issue when using UNC, did not know about that yet.

    Tuesday, June 18, 2013 8:00 AM
  • I just tried if cmd.exe returned 1 from UNC path. This is not longer the case. Perhaps things have changed. I've tested the below vbscript on Windows server 2008 R2.

    Dim sScriptPath : sScriptPath = Left( Wscript.ScriptFullName, Len(WScript.ScriptFullName) - Len(WScript.ScriptName) ) ' Ends with a '\'
    Dim WshShell : Set WshShell = WScript.CreateObject("Wscript.Shell")
    Dim iRet
    WshShell.CurrentDirectory = InputBox("Enter your starting directory", "", sScriptPath)
    iRet = WshShell.Run("cmd.exe /c", 1, true)
    MsgBox"cmd.exe returned " & iRet
    WScript.Quit iRet

    Tuesday, June 18, 2013 9:01 AM