Alex’s point is very timely in that we were just discussing this yesterday (Actually Alex tends to do that a lot, I wonder if my office is bugged. Hmmmm.). Anyway, we were talking about the possibility of adding this as an operator and then maybe having user-define operators. Of course my initial reaction was – let’s get this into V1.0 but we at a point in the project where we need to stop making changes to ensure the stability of the codebase. (I suspect that our GPM Hilal has secretly purchased a roll of duct-tape for use the next time someone suggests adding a feature to V1.0. )

So what is great is that this is EXACTLY the situation we designed Windows PowerShell to address. I’ve always HATED the conversation where a customer tells me what they need and then I have to say, “Got it, we’ll add that. Just hang in there a couple more years and we’ll get you what you need.” We designed the system to address this (As you can see from the mention of user-defined operators, we continue to think about how to do a better job of this). You can take the XML that Alex provided above and include it into your own My.Types.ps1xml (this process is describe reasonably well in http://blogs.msdn.com/powershell/archive/2006/06/24/644987.aspx ).

So – we’ll almost certainly do something similar to this in V2.0 (maybe V1.1) but you don’t have to wait for us – you can have this function today. Now just be aware of one thing – name collisions. If you think about it, when we get around to it, if we decide to add this function to the type (as opposed to creating an operator for it), we’ll almost certainly call it “BASENAME”. If you’ve already define your own property called BASENAME, there will be a collision (we use Casino rules on name collision [House wins on a tie]). So you might consider calling it something unique.

We should probably promulgate a naming convention for user-defined extensions. I’d love to get input on that topic so please post that as comments to this blog.

Enjoy!Jeffrey SnoverWindows PowerShell Architect

PSMDTAG:PHILOSOPHY: Provide mechanisms that the community can solve problems without waiting till the next release cycle.PSMDTAG:TYPEEXTENSION: BaseName on FileInfo

Regarding a naming convention, you probably already know that I’m not a fan of "My." anything. Besides the customized types.ps1xml I use is located in the PSConfiguration folder. I think this is where all customization files should go. I don’t think it is a good idea to have folks place customized files in PowerShell’s install dir. On Vista, depending on how you try to write to the Program Files dir the modification may or may not get virtualized.

12 years ago

Alex K. Angelopoulos

After some volleying with Jacques Barathon, there’s a slightly improved version of the code block which correctly handles files which have no extension or names that begin with a period:

####

if ( ($this.extension.length -gt 0)

-and ($this.extension.length -lt this.Name.length) )

{

$this.Name.Remove($this.Name.Length – $this.Extension.Length)

}

else

{

$this.Name

}

12 years ago

jvierra

I agree. If we can add it as a type that should be good for now. Perhaps the typing that may be included in future releases shouyld be mediated by the PS Team. A standard for adding types and documenting them so that when they are included in the release nothing will break.

I would much rather see an AD provider take shape. While we can use AD through NET Framework or COM it would be far better to have a full PS provider for ADSI.

How has Exchange managed to survive without an ADSI provider? Are they building all of it into the Exchange provider?