Use of environment variable for username in a shortcut (Win 10-1909)

KeithM said:

If you create a shortcut with the Create Shortcut wizard, any environmental variables in the Target path will be evaluated when the shortcut is created, leaving you with a static Target.

To create a shortcut with environmental variables that are evaluated when the shortcut is launched, you have to create the shortcut programatically.

PowerShell:

Code:

$wshell = New-Object -ComObject wscript.shell
$sc = $wshell.CreateShortcut("c:\Users\Keith\mytest.lnk")
$sc.targetPath = '%USERPROFILE%\Sandbox'
$sc.save()

Properties of MyTest.lnk after creation:
Attachment 321808

Thanks. Good to know how to do that.

Re-reading, I found this code buried as a one-liner:

Code:

method void OnButtonClick2(Object sender, EventArgs args )
 begin
   BatFile1 = FilePath+"PosnPushAlert"+".bat";
   FileDelete(BatFile1);
   Bat1Text = "Powershell.exe -executionpolicy remotesigned -File C:\Users\%UserName%\Desktop\PushOverPS.ps1 ";
   Bat1Text += doublequote+DTS()+" This is a test. "+doublequote;
   FileWrite(BatFile1,Bat1Text);
   if Elsystem.io.File.Exists(BatFile1) then environment.start(BatFileShtCut);
   Textbox1.Text = "OK";
 end;

The "trick" to psting multiline code here is to switch the edtor to "Source mode" with the ^A/_A button:



Easier to read & harder to miss!

and, IMHO, should have been in the original post. as well as the resulting bat file, and the .ps1. It's like Russian nesting dolls with missing pieces otherwise. I get lost when people "describe" code but fail to show it!

KeithM said:

If you create a shortcut with the Create Shortcut wizard, any environmental variables in the Target path will be evaluated when the shortcut is created, leaving you with a static Target.

To create a shortcut with environmental variables that are evaluated when the shortcut is launched, you have to create the shortcut programatically.

PowerShell:

Code:

$wshell        = New-Object -ComObject wscript.shell
$sc            = $wshell.CreateShortcut("c:\Users\Keith\mytest.lnk")
$sc.targetPath = '%USERPROFILE%\Sandbox'
$sc.save()

Properties of MyTest.lnk after creation:
Attachment 321808

FWIW, I already explained this in my first reply to this thread.

hdmi said:

FWIW, I already explained this in my first reply to this thread.

There were already three pages of replies & I was scanning. But even on reading your earlier reply more carefully, You only state the first half of what I said --- The UI expands variables upon shortcut creation, but nothing about how to create a shortcut with an expandable Target path. Perhaps that is clear in the link you posted, but who knows --- you didn't specify the nature of the "workaroud".

The only code you posted was a .vbs wrapper to run a PowerShell script, not a clear example of creating a shortcut with an expandable Target path. So I don't think my post is redundant; I think some will find it useful.

KeithM said:

There were already three pages of replies & I was scanning. But even on reading your earlier reply more carefully, You only state the first half of what I said --- The UI expands variables upon shortcut creation, but nothing about how to create a shortcut with an expandable Target path. Perhaps that is clear in the link you posted, but who knows --- you didn't specify the nature of the "workaroud".

The only code you posted was a .vbs wrapper to run a PowerShell script, not a clear example of creating a shortcut with an expandable Target path. So I don't think my post is redundant; I think some will find it useful.

I can't blame you for not reading through this massive train wreck of a thread, but the part about the workaround being described in the link I posted is very much evident from how I posted it:

hdmi said:

Environment variables entered in the Target field of a shortcut's properties window are automatically expanded during creation of the shortcut. You could work around this problem as described here:
windows 7 - Environment variable in .lnk shortcut - Super User

hdmi said:

I can't blame you for not reading through this massive train wreck of a thread, but the part about the workaround being described in the link I posted is very much evident from how I posted it:

"You could work around this problem as described here:.."

does not, to my mind, tell me:

• whether or not a shortcut target can contain evironmental variables that are evaluated at exxecution
  
  • If so,how to create them

which is what I mean by "...nature of the workaroud"

and I see, once I go through the extra step of opening the link, that the information is current, not out-dated, is PowerShell, etc...all good. But why not post the trhree lines of relavent code in your reply.

So many are wedded to batch & link to old examples (you can't blame me for being wary of the win7 part of tht link! ) that I often assume the worst

I've had so much fun learning PowerShell I feel compelled to advocate for it & offer alternative code whenever possible, especially if it's not apparent ( to my nearly legally blind ass! ) that equivalent code has already been offered. So sorry I missed tat. Bottom line, as any search for batch code will tell you, you can never have too many code examples out there!

KeithM said:

whether or not a shortcut target can contain evironmental variables that are evaluated at exxecution

Merely clicking on the link I posted does tell you exactly that.

If so,how to create them

Merely clicking on the link I posted does tell you exactly that as well.

which is what I mean by "...nature of the workaroud"

The nature of it is that it can very easily be found on Super User, i.e., by clicking on the link I posted, rather than not clicking.

and I see, once I go through the extra step of opening the link, that the information is current, not out-dated, is PowerShell, etc...all good.

Right.

But why not post the trhree lines of relavent code in your reply.

Why not click on the link I posted. Clicking on it would have been so much faster than waiting until you came up with a duplicate of the solution that I linked to. I mean, if people don't like to click on links, then that's their problem, not mine. Personally, I, like to click on links. In fact, clicking on links is how I found the solution, anyway in the first place. One example of things I usually don't like are called bottomless pits, but in this particular instance I am prepared to fully admit it's one of the most beautiful bottomless pits that I have seen.

So many are wedded to batch & link to old examples (you can't blame me for being wary of the win7 part of tht link! ) that I often assume the worst

I've had so much fun learning PowerShell I feel compelled to advocate for it & offer alternative code whenever possible, especially if it's not apparent ( to my nearly legally blind ass! ) that equivalent code has already been offered. So sorry I missed tat. Bottom line, as any search for batch code will tell you, you can never have too many code examples out there!

No worries. I was only joking of course.

KeithM said:

Re-reading, I found this code buried as a one-liner:

Code:

method void OnButtonClick2(Object sender, EventArgs args )
 begin
   BatFile1 = FilePath+"PosnPushAlert"+".bat";
   FileDelete(BatFile1);
   Bat1Text = "Powershell.exe -executionpolicy remotesigned -File C:\Users\%UserName%\Desktop\PushOverPS.ps1 ";
   Bat1Text += doublequote+DTS()+" This is a test. "+doublequote;
   FileWrite(BatFile1,Bat1Text);
   if Elsystem.io.File.Exists(BatFile1) then environment.start(BatFileShtCut);
   Textbox1.Text = "OK";
 end;

The "trick" to psting multiline code here is to switch the edtor to "Source mode" with the ^A/_A button:



Easier to read & harder to miss!

and, IMHO, should have been in the original post. as well as the resulting bat file, and the .ps1. It's like Russian nesting dolls with missing pieces otherwise. I get lost when people "describe" code but fail to show it!

Yup. Sorry for my bad question and posting.

I had a similar problem to this when using DFS-Namespace paths.