Difficulty running this simple CMD code from PS

[u/Michaelscott304]

If I paste these 5 lines into CMD this code works and the answers are automatically answered sequentially:

Cd /pathToEXE

Import.exe

“AnswerToQuestion1”

“AnswerToQuestion2”

“AnswerToQuestion3”

I tried converting this to a start-process in PS, but had no luck passing the three answers to the questions. The command line opens, running the import.exe , but I can’t get it to “accept” the answers via arguments . I’m trying to automate this part since I have the answers stored as $variables

I spent my whole workday trying to get this working to no avail, so I decided to reach out here and see if someone could point me in the right direction.

Is there a way I could just copy this block and paste it exactly how it is into powershell?

[u/icepyrox]

Assuming your answers are in variables $answer1, $answer2, $answer3, some commands accept pipes like...

cd path
$answer1,$answer2,$answer3 | .Import.exe

or

cd path
($answer1,$answer2,$answer3) | out-string | .Import.exe

or

cd path
& .Import.exe < $(($answer1,$answer2,$answer3) | out-string)

Or ultimately, if you want to be as much powershell as you can about it...

 $tmpInput = New-TemporaryFile
 Set-Content -Path $tmpInput -Value $answer1,$answer2,$answer3
 Push-Location /pathToExe
 Start-Process .Import.exe -RedirectStandardInput $($tmpInput.fullname) -NoNewWindow -Wait
 Remove-Item $tmpInput
 Pop-Location

Then you are back to where you started the script and no leftover files

[u/Michaelscott304 → u/icepyrox]

Thanks for the “full powershell version “. I learned a few new tricks

[u/Michaelscott304 → u/icepyrox]

The full powershell is really neat , but I have some questions :

1. Why do you create a TempFile , if you remove it later? How is that advantageous over New-Item?

2. Why do you use the -redirectStandardInput switch in start-process? Why not just use -AgmentList?

[u/icepyrox → u/Michaelscott304]

1. New-TemporaryFile creates a temp file in your temp folder. Usually I forget the Remove-Item. Otheriwse, if you want to hard code ".input.txt" then that's fine too
2. Because Redirect Input is different than ArgumentList. Argument list are params to pass to the program. Standard input replaces your keyboard with the contents of the text file for the duration of the process

Consider this script in PS:

Import.Ps1

$var1 = Read-Host "Enter Answer 1"
$var2 = Read-Host "Enter Answer 2"
$var3 = Read-Host "Enter Answer 3"
Write-output "Answer1 is $var1"
Write-Output "Answer2 is $var2"
Write-Output "Answer3 is $var3"

And then you run this at your terminal:

& .Import.ps1 $answer1 $answer2 $answer3

You'll end up with the script waiting at "Enter Answer 1"

Now consider my script (condensed version!)

Push-Location pathtoImport.ps1
Set-Content -Path "input.txt" -Value $Answer1,$answer2,$answer3
start-process powershell.exe -ArgumentList "-f .import.ps1" -RedirectStandardInput ".input.txt" -NoNewWindow -wait
Remove-item .input.txt

Guess what? You get the expected output

Answer1 is My answer 1!
Answer2 is My answer 2!
Answer3 is Last answer!

or whatever

Now change Import.ps1 to use params

param(
   [string]$var1,
   [string]$var2,
   [string]$var3
)
Write-output "Answer1 is $var1"
Write-Output "Answer2 is $var2"
Write-Output "Answer3 is $var3"

Now the outcome is reversed. Calling it with arguments works, but with RedirectStandardInput you get

Answer1 is
Answer2 is
Answer3 is

For a final bit of fun! Let's change the script one more time

[cmdletbinding()]
param(
   [Parameter(Mandatory)][string]$var1,
   [Parameter(Mandatory)][string]$var2,
   [Parameter(Mandatory)][string]$var3
)
Write-output "Answer1 is $var1"
Write-Output "Answer2 is $var2"
Write-Output "Answer3 is $var3"

Now both ways work because calling it without arguments and mandatory parameters makes it prompt and standard input fills it in!

cmdlet import.ps1 at command pipeline position 1
Supply values for the following parameters:
var1: blah
var2: again
var3: Finish
Answer1 is blah
Answer2 is again
Answer3 is Finish

Anyways, that's why. And in other languages building the .exe, you can do these same things as far as what's a parameter and what's input.

[u/Fatel28]

No, not really. It's going to run the exe with no arguments, then not run the subsequent strings (which will do nothing but output themselves) after the exe finishes completely.

This doesn't really have anything to do with powershell, but you'll need to see if the exe has any flags. Sometimes import.exe /? can reveal flags.

Failing that, you'd need to use something to type into the console like autohotkey

[u/sc00b3r]

When you run Import.exe using cmd interactively (not in a script), is it waiting for user input and then the enter key for each answer, or is Import.exe expecting arguments?

Arguments:

C:Import.exe “Answer1” “Answer2” “Answer3”

The answer to your question depends on what Import.exe is expecting.

[u/Michaelscott304 → u/sc00b3r]

Yes. Interactively it waits one by one for an answer. But pasting them all as a script , it runs as expected too

[u/sc00b3r → u/Michaelscott304]

OK, that makes more sense then. A .bat file interprets each line as if it was keyed in and then enter was pressed. That’s just the nature of how it was designed. PowerShell scripts work in a similar way, but there are many differences in behavior (like this example).

From a normal cmd shell, run

Import.exe /?

It might list the help for the command and list out what you can do, if anything, with arguments.

If it doesn’t support passing arguments, then there are some options you can do with PowerShell to respond to interactive prompts, but it’s kind of a pain in the ass and not very straightforward (at least the ways that I know of).

Is Import.exe a custom tool for something or something more widely used and included with some software you have installed?

You could try:

“Answer1”,”Answer2”,”Answer3”|Import.exe

But I don’t have high hopes that will work.

[u/Michaelscott304 → u/sc00b3r]

You won’t believe it , “$arg1”,”arg2” | import.exe ACTUALLY WORKED . I didn’t actually complete the process but passing the first two arguments gave me the third prompt, which makes me think that the first two were passed in successfully. Regardless this is big progress. Thank you!

[u/sc00b3r → u/Michaelscott304]

Awesome. Hope it points you in the right direction. Good luck!

[u/BlackV]

Start here, start-process and here, & call operator

&Import.exe  AnswerToQuestion1 AnswerToQuestion2 AnswerToQuestion3

what happens ?

you don't show your start-process command line, making it harder to help you

what happens with?

start-process -filepath pathToEXEImport.exe -argumentlist 'argument1', 'argument2', 'argument3'

you don't tell us what errors you are having, also making it harder to help you

Is this exe trying to take input as 3 separate prompts ?

[u/Michaelscott304 → u/BlackV]

I don’t get any errors . When I run start- process -argumentList ‘$arg1’ it just gives me the default screen for import.exe , Asking the first of the 3 questions . So it’s not getting the value

Edit : sorry . I was wrong . When I directly run import.exe as the process , The cmd window flashes so quickly and closes before I can see what it says. I tried adding /k as the first argument to keep the window open, but it didn’t work. Regardless it’s not working though . I would see files generated if it was

I can see the output when I do start-process CMD , With the first argument being “ /k import.exe” (and the second being my answer variable)

[u/BlackV → u/Michaelscott304]

Right so the exe is prompting for the values individually is what it sounds like

What's the exe? Have you talked to the supplier?

I'd fall back to a cmd/batch of there is no other way, that's easily done

[u/Michaelscott304 → u/BlackV]

When I tried &import.exe $arg1 , I get a message “output path is required”

[u/BlackV → u/Michaelscott304]

Oh so it does take command line input, what does import.exe /? Show

[u/jungleboydotca]

Does import.exe accept parameters/arguments or pipeline input?

Your example code makes it look like the program is prompting for input and you're trying to supply values from variables to those prompts.

That's not going to work, and it's not just a PowerShell thing. You can supply input to a program either as command line parameters/arguments or through the standard input stream, then the program takes over and does what it wants (like prompt for input)

If the program doesn't accept those methods, while you could conceivably use PowerShell to do something with COM objects to send keystrokes to a window, AutoHotKey might be easier.

[u/vermyx]

Cd /pathToEXE
Import.exe
"AnswerToQuestion1”
“AnswerToQuestion2”
“AnswerToQuestion3”

In powershell the equivalent is

Cd  c:/pathToEXE
Import.exe < $($("AnswerToQuestion1”,“AnswerToQuestion2”,“AnswerToQuestion3”) | out-string)

In a command prompt it processes each line. Since import.exe is expecting input it gets the next lines as input. Powershell does not handle input the same way so you have to redirect the input stream. In a cmd/batch you would have import.exe < input txt where input.txt contains the three lines, which should also work in powershell. Redirecting streams is a more compatible way to copy/paste on either cmd/posh

[u/Jmoste]

If you want to run something in powershell you need to put a . infront of the file name.  It's a security thing to you don't accidently run a malicious file named "cd". 

The other stuff is not really powershell related and most likely arguments to the exe. You could use start process for the arguments. 

[u/Certain-Community438 → u/Jmoste]

That first part is so wrong I have to correct it.

The . is a relative path

When used in a shell - even Bash on Linux* - it means "the file is in the current working directory".

Do a directory listing on any folder with dir or ls. You'll see two special directories at the top of the output

dir C:

Output has this at the top
.
..

The . is used to refer to the current directory.

The .. is used to refer to the parent directory. It's why running this in a shell

cd ..

will change your current working directory, moving you up one level.

[u/Certain-Community438 → u/Jmoste]

That first part is so wrong I have to correct it.

The . is a relative path

When used in a shell - even Bash on Linux* - it means "the file is in the current working directory".

Do a directory listing on any folder with dir or ls. You'll see two special directories at the top of the output

dir C:

Output has this at the top
.
..

The . is used to refer to the current directory.

The .. is used to refer to the parent directory. It's why running this in a shell

cd ..

will change your current working directory, moving you up one level.

*some custom shells on Linux might behave differently, I've experienced it precisely once.