PSHELL: How pass arguments to script?

May 20, 2008
12,171
133
Syracuse, NY, USA
Here's a little Powershell script.

Code:
# cmenu.ps1
$o = new-object -com "Shell.Application"
$folder = $o.NameSpace($args[0])
$file = $folder.ParseName($args[1])
$file.InvokeVerb("Properties")

It works (opens the Properties dialog) in Powershell if I give it a foldername and a filename; for example,

{code]PS> cmenu.psi d:\tc26 tcc.exe[/code]

If, instead of arg[0] and arg[1], I hard-code a foldername and a file name, it runs OK with TCC's PSHELL.

But I can't figure out how call it with PSHELL providing two arguments to the script.
 
If I do;
Code:
pshell /s cmenu.ps1 e:\utils cmenu.ps1
it works, but gives an error.

Not sure why it works with /s, but not without.

I also made a slight change to your script;
Code:
# cmenu.ps1
param($p1, $p2)
$o = new-object -com "Shell.Application"
$folder = $o.NameSpace($p1)
$file = $folder.ParseName($p2)
$folder
$file
$file.InvokeVerb("Properties")

Not a game changer, just the method that I use for getting arguments.

Joe
 
Hard-coding the foldername and filename, as you noted, works with PSHELL.

I've written a .BTM that creates the .PS1, thus allowing for arguments that are hard-coded into the .PS1
Code:
@setlocal
@echo off
if %# ne 2 quit
type <<- endtext > cmenu.ps1
$o = new-object -com "Shell.Application"
$folder = $o.NameSpace("%1")
$file = $folder.ParseName("%2")
$file.InvokeVerb("Properties")
endtext
type cmenu.ps1
pshell cmenu.ps1
endlocal

1595422750587.png


Not a fix, but an alternative.

Joe
 
May 20, 2008
12,171
133
Syracuse, NY, USA
Indeed, this works (i.e., opens the Properties dialog).

Code:
pshell /s v:\cmenu.ps1 d:\tc26 tcc.exe

And generates this error:

1595430234834.png
 
May 20, 2008
12,171
133
Syracuse, NY, USA
You can also pass the info in the environment. That makes an alias feasible. But passing args to the script would be better.

Code:
alias psprops `set p1=%@path[%1] & set p2=%@filename[%1] & pshell v:\cmenue.ps1 & unset p1 p2`

Code:
v:\> type cmenue.ps1
$o = new-object -com "Shell.Application"
$folder = $o.NameSpace($env:p1)
$file = $folder.ParseName($env:p2)
$file.InvokeVerb("Properties")
 
May 20, 2008
12,171
133
Syracuse, NY, USA
Throw in another variable for the verb and it gets pretty generic.

Code:
v:\> alias verbex
set p1=%@path[%1] & set p2=%@filename[%1] & set p3=%2 & pshell v:\doverb.ps1

v:\> type doverb.ps1
$o = new-object -com "Shell.Application"
$folder = $o.NameSpace($env:p1)
$file = $folder.ParseName($env:p2)
$file.InvokeVerb($env:p3)
 
May 20, 2008
12,171
133
Syracuse, NY, USA
This works and produces no error (might have gleaned it from the help).

Code:
pshell /s "v:\cmenu.ps1 d:\tc26 tcc.exe"
 
May 20, 2008
12,171
133
Syracuse, NY, USA
Here's another incarnation.

Code:
param($verb, $target)
$path = split-path -path $target -parent
$filename = split-path -path $target -leaf
$o = new-object -com "Shell.Application"
$folder = $o.NameSpace($path)
$file = $folder.ParseName($filename)
$file.InvokeVerb($verb)

Call it with the verb first and a regular drive:\path\file.ext file spec second.

Code:
pshell /s ".\cmenu.ps1 properties d:\tc26\tcc.exe"
 
  • Like
Reactions: Joe Caverly

samintz

Scott Mintz
May 20, 2008
1,555
26
Solon, OH, USA
FWIW - I have an executable extension for .ps1.
Code:
set .ps1=powershell -f
I am able to execute your last example by
Code:
cmenu Properties C:\tc26\tcc.exe
 
May 20, 2008
12,171
133
Syracuse, NY, USA
FWIW - I have an executable extension for .ps1.
Code:
set .ps1=powershell -f
I am able to execute your last example by
Code:
cmenu Properties C:\tc26\tcc.exe
That's funny. I can't. "Open" works, but "Properties" gives just nothing.
 
May 20, 2008
12,171
133
Syracuse, NY, USA
When I try to use an executable extension (as Scott suggested) and the "Properties" verb it does nothing and I get an event log entry

1595465353885.png


With the verb "Open", it's OK ... it works and no Scriptblock event log entry. Can I turn this off?
 
May 20, 2008
12,171
133
Syracuse, NY, USA
That's funny. I can't. "Open" works, but "Properties" gives just nothing.
Apparently powershell.exe was exiting too quickly for the "Properties" verb to work with the executable extension. Putting "Sleep -s 1" at the end of the PS! script solved that. I wonder if it's possible to force InvokeVerb to be (more) synchronous.
 
May 20, 2008
12,171
133
Syracuse, NY, USA
Apparently powershell.exe was exiting too quickly for the "Properties" verb to work with the executable extension. Putting "Sleep -s 1" at the end of the PS! script solved that. I wonder if it's possible to force InvokeVerb to be (more) synchronous.
That gets the "Properties" dialog to show, but it closes when the transient Powershell exits. Doesn't that happen to you, Scott?
 

Similar threads