PowerShell only displays environment variable values

This topic contains 0 replies, has 1 voice, and was last updated by Profile photo of Forums Archives Forums Archives 5 years, 3 months ago.

  • Author
    Posts
  • #5591

    by Chromebuster at 2013-02-25 18:30:58

    This is driving me crazy. I have a variable called IISAdministration set to C:\windows\SysWow64\inetsrv. What I want to be able to do is to go to that directory using the $env:IISAdministration syntax,but what seems to be happening instead, is that the value of the variable will display quickly, and before I can blink, I'm back to the root PowerShell Prompt again. What syntax do I have to use in order for PowerShell to take me to the directory where the variable points and for it to stay there? I mean, isn't that the reason for creating environment variables? So that we don't have to type ridiculously long paths on the command line? I'm curious because with other variables, %VariableName% in the older CMD shell will take me to the directory pointed to and will then allow me to work within that directory. How do I get the same to work in PowerShell 3.0? Thanks.

    by poshoholic at 2013-02-25 19:38:49

    You mean like this?
    cd $env]

    by Chromebuster at 2013-02-26 15:36:11

    I tried that. I get the following when I do it:
    CD: cannot find drive. A drive with the name'"C" does not exist
    Odd, isn't it? Even when I first change to the Env:\ directory. I get the same message.

    by DonJ at 2013-02-26 15:48:50

    The command should work. Depends on what's in your IISAdministration variable – you might check it to make sure it has what you think it has.


    PS C:\> $env:ALLUSERSPROFILE
    C:\ProgramData
    PS C:\> cd $env:ALLUSERSPROFILE

    Works fine with ALLUSERSPROFILE which is a similar path. So the syntax, which I imagine is what you've been trying, is sound. That suggests the problem must like elsewhere, such as with the contents of the variable.

    And no, environment variables aren't about saving typing time. They're about giving programs a standardized element to refer to, when the element's underlying meaning may change. E.g., USERPROFILE always points to the current user profile, so you don't have to figure out where that is. The value itself is variable so you make a variable in which to put it. Case in point, ALLUSERSPROFILE is actually longer than the path it usually points to . In your case, $env:IISAdministration isn't actually much shorter than the path you're using.

    In PowerShell, a PSDrive can serve the purpose of providing a shorter "alias" to a fixed location. Map a drive... say, IISADMIN:, to C:\Windows\SysWow64\inetsrv. If the path isn't likely to ever change... meaning it isn't variable... then there's less argument for putting it in a variable. I'd be curious if you could map a PSDrive using your environment variable as the root.

    But in your case it feels like the data in the environment variable is wonky somehow, in that it's confusing the CD command.

    by Chromebuster at 2013-02-26 19:20:30

    I begin to wonder myself; I have seemed to always have problems modifying or creating environment variables with optimal results. Maybe I should have used a PS drive instead. But I'm pretty sure that the only value is C:\Windows\SysWow64\inetsrv. I know this because the old cd %IISAdministration% syntax in CMD.exe does what it's supposed to; brings me right to that directory and allows me to work within it. I wonder though, would a PSDrive do the same? I'll have to try and find out. Though I'm not sure, but I think I have issues navigating through all variables in the Env:\ drive hierarchy. I think that I get the same funky confused message on all of them; I'll have to check. But I have lots of command line tools, and I don't necessarily like typing long-winded paths to them. Like, one of the things I need to do is make a PS drive that points to the VS 2012 command prompt path so that I can use either PowerShell or CMD without typing in a long path name. I don't know what the heck Microsoft was thinking when they assigned the environment to CMD.exe and not PowerShell.exe. But thanks for the input.

You must be logged in to reply to this topic.