Location of Cd Executable

Location of cd executable

A process can only affect its own working directory. When an executable is executed by the shell it executes as a child process, so a cd executable (if one existed) would change that child process's working directory without affecting the parent process (the shell), hence the cd command must be implemented as a shell built-in that actually executes in the shell's own process.

How do you run an executable file whose name and location could vary with the Windows command prompt?

I figured out how to run an executable that is in a folder with an unknown name and that has a file name that will be different depending on the version of the program. I was trying to find and run a test file that I called "program1.3.0.exe". Note, I ran this in a batch file so if you are running this directly in the command prompt you will need to type %i instead of %%i.

for /r C:/ProgramData %%i in (program*.exe) do start %%i

• The for command searches through the directory
• /r tells it to search within the subdirectories
• C:/ProgramData is the directory that it will search within
• %%i is a variable that holds each file that it finds
• in (program*.exe) tells it to only use results that start with program and end with .exe
• do start %%i will run each executable that it finds

bash: how to combine cd and ./?

The leading dot in your command ./runthis means "relative to the current directory". But when you want to call it from outside the directory, remove the dot and provide the absolute path of your executable file xfile/runthis. The same is true when you want to call it from your run.sh

tcl can't find wsl.exe when executing cmd /c wsl.exe --cd some/path/to/destination

You need to use the native name of files that you pass through cmd like that. Try this:

set wsl [file nativename c:/Windows/System32/wsl.exe]
set netlist [file nativename $drive_letter/Projects/$project/gs/$unit/netlist]
exec c:/Windows/System32/cmd.exe /c $wsl --cd $netlist >>TestWSL.txt

You probably don't need to pass through cmd as you are calling an executable, but if you do you must use native names (which just flips the / to \ on Windows; other platforms may do other things).

haskell: cd command does not work in shake/command library

Shake's Haddock page describes cmd_, and links to its source. There we can see that cmd_ eventually calls commandExplicitIO, which constructs a ProcessOpts with RawCommand and passes it to process. process then takes that ProcessOpts, pattern-matches it as a RawCommand (via cmdSpec), and calls proc. We have now entered the well-documented zone: you must give proc an executable, and cd is not an executable. (Why? Since processes cannot change the working directory of their parent, cd must be a shell builtin.)

Execute the 'cd' command for CMD in Go

The cd command is a builtin of your shell, whether bash, cmd.exe, PowerShell, or otherwise. You would not exec a cd command and then exec the program you want to run. Instead, you want to set the Dir of the Cmd you're going to run to the directory containing the program:

package main

import (
    "fmt"
    "log"
    "os/exec"
)

func main() {
    cmd := exec.Command("program") // or whatever the program is
    cmd.Dir = "C:/usr/bin"         // or whatever directory it's in
    out, err := cmd.Output()
    if err != nil {
        log.Fatal(err)
    } else {
        fmt.Printf("%s", out);
    }
}

See the Cmd documentation for more information. Alternatively, you could use os/Chdir to change the working directory before running the program.

Running Batch File To Execute PowerShell and Additional Batch file

powershell.exe, the Windows PowerShell CLI, doesn't directly support -Verb RunAs in order to launch a process with elevation (as admin).

Instead, you must use use the -Command (-c) parameter to pass a command that calls Start-Process -Verb RunAs, which in turn requires a nested powershell.exe call in order to execute the .ps1 file with elevation:

powershell.exe -noprofile -c Start-Process -Verb RunAs powershell.exe '-ep bypass -file \"%CD%\InstallApp.ps1\"'

Note:

• Since -Verb RunAs in Windows PowerShell makes the elevated process default to the SYSTEM32 directory instead of the caller's, the .ps1 file path was explicitly prefixed with the caller's working directory, %CD%.

  • Note: Since your .ps1 script explicitly sets its own working directory (CD $PSScriptRoot), there is no need to preset the working directory for the elevated process.
  • Doing so would complicate the call, because you cannot simply use the -WorkingDirectory parameter of Start-Process in combination with -Verb RunAs. Instead, you'd have to switch the nested powershell.exe call to a -Command (-c) invocation that executes Set-Location (cd) in the elevated process, before calling the target script, which complicates quoting and escaping - see this answer for an example.

• I've omitted -ep bypass from the outer powershell.exe call, as it isn't necessary there (only a cmdlet - Start-Process - is executed in its session, which isn't subject to the effective execution policy).

  • However, I've substituted -noprofile to suppress execution of any profile scripts - which are subject to the execution policy.
  • Routine use of -noprofile is advisable for automated execution, both for a more predictable execution environment and to eliminate unnecessary processing.

• Add -Wait to the Start-Process call if you want to wait for the elevated script to exit.

• Since your .ps1 script is then elevated via the batch file, you don't need Start-Process -Verb RunAs inside the script anymore, and you can simply place a
  #Requires -RunAsAdministrator line at the start to prevent direct, non-elevated execution.

Finally, as an alternative to using a helper batch file, consider making your .ps1 script self-elevating, as shown in this answer (the linked answer is complex, because it tries to provide a generic, robust solution that supports arbitrary arguments; for argument-less invocations it can be greatly simplified).

---

Related Topics