[Solved] Problems passing "arrays" to Powershell

[Filehero]

Hi,

I got some headaches trying to pass an array of values from XY to Powershell.

When I run the PS-script "test.ps1" (attached, just remove the fake zip-extension) from the console everything works as expected and I got output 2 values passed.

Code: Select all

PS $> .\test.ps1 -dirs "Folder 1", "Folder 2"
The number of dirs passed in dirs is: 2
1: Folder 1
2: Folder 2

When I try to run the same script from XY something gets scrambled though the command string seems to be ok.

CommandString.png

Note the double quotes around the passed dirs don't differ from the ones given when running the script straight from the console.

But now the console output has changed, something not obvious must be different.

Code: Select all

The number of dirs passed in dirs is: 1
1: Folder_1,

Here is the script code (just put testRunPS.xys into the same folder as the PS-script):

Code: Select all

  $scriptPath = self("path");
  $cmd = "Powershell -NoExit -File ""$scriptPath\test.ps1"" -dirs ""Folder_1"", ""Folder_2""";
  msg($cmd);
  run($cmd);

Where am I wrong?


Thanks & cheers,
Filehero

[Marco]

Strangely, the ps script doesn't run on my W7, something about permissions for running scripts :/ ... and I don't want to fiddle with the registry atm.
Anyway, this is the typical case heredoc saves my sanity

Code: Select all

  $scriptPath = self("path");
  $cmd =<<<NOMOREQUOTES
Powershell -NoExit -File "$scriptPath\test.ps1" -dirs "Folder_1", "Folder_2"
NOMOREQUOTES;
  msg($cmd);
  run($cmd);

Does it work?

[Filehero]

Hi Marco,

thanks for helping me.

Strangely, the ps script doesn't run on my W7, something about permissions for running scripts :/ ...

Since I came across this very same problem after I'd installed Windows 8, a little off-topic. I guess

Code: Select all

PS> Get-ExecutionPolicy

will return "Restricted". This means, you can't run any scripts, only commands. I think that's a bit too restricted for a default policy.
You can cure it once and for all by (you may need to run the console as admin)

Code: Select all

PS> Set-ExecutionPolicy RemoteSigned

See here for more info.


But back to topic.

Anyway, this is the typical case heredoc saves my sanity...Does it work?

Nope. But even if, all paths are meant to become variables in the end. We may have to wait until Don chimes in?


Cheers,
Filehero

[admin]

Should work (cannot really test since have no powershell).
The only thing: SC run will default to the current dir as second parameter. If you don't want that you should specify the parameter yourself.

[Marco]

Thanks bro, now PS is running fine
I just tried issuing the command via the good'ol Win+R dialog

Code: Select all

Powershell -NoExit -File "C:\Nuova cartella\test.ps1" -dirs "Folder_1", "Folder_2"

and the result is the same

Code: Select all

The number of dirs passed in dirs is: 1
1: Folder_1,

Looks to me like the command line parsing is troublesome, not XY.

(OT: PS seems like command prompt on steroids. Does it work well as an evolution of old batch files? From your example I even notice "real" for loops...)

[Filehero]

(OT: PS seems like command prompt on steroids. Does it work well as an evolution of old batch files? From your example I even notice "real" for loops...)

Well, from the functional point of view it's a revolution. Technically, they don't share anything, I guess.
To me PS is like a bash on windows, you can do anything. I'm a minor user only, but I can list some stuff I like the most.


Object-based
Piping only seems to work like unix/linux shells where commands are connected by reading/sending text streams via stdout/in. But in fact, .NET-objects are passed! Once you have an object you can simply use the .NET-api on it. Though you sometimes need some small debug statements to get the nature of the invidual types returned by commandlets, this is so funny and powerful.

Just some Examples

Code: Select all

[string] $fileHome = $(Get-Item $filePathStr).DirectoryName;

Get-Item returns a FileInfoObject for the given path from which you can simply fetch the parent folder

Code: Select all

 if ($aStr.EndsWith($anotherSring)) {...}

A string is a real .NET-string!

Arrays, lists, hashmaps - initializiation by short notation or via constructor. Variables can be made type safe.

Code: Select all

$script:aMap = @{};
[System.Collections.ArrayList] $script:aList = New-Object System.Collections.ArrayList(0);

Simple xml-processing

Code: Select all

[xml] $xmlData = (Get-Content $xmlFilePathStr);

Yep, that's the entire code for reading and returning an xml-document on which you can do anything with XPath.

You can even create your own .NET-types form PS, you have modern error-handling (try...catch) and so forth.

It's really worth a look at.


Cheers,
Filehero

[Filehero]

Should work (cannot really test since have no powershell).
The only thing: SC run will default to the current dir as second parameter. If you don't want that you should specify the parameter yourself.

Seems I have to try some more things...thanks.


Cheers,
Filehero

[Filehero]

Hi,

I've got it solved by simply replacing "-File" with "-command".

Code: Select all

$scriptPath = self("path");
$cmd = "Powershell -NoExit -command ""$scriptPath\test.ps1"" -dirs ""Folder_1"",""Folder_2""";
msg($cmd);
run($cmd);

From reading in here it makes sense since passing "-command" means Executes the specified commands (and any parameters) as though they were typed at the Windows PowerShell command prompt ...

However, I still don't get why "-File" also seems to change the way the stdin is processed. Might be a bug.

Anyway.


Cheers,
Filehero