Vista - Using Parse-TextObject

Hello All:

I'm very much a newbie to Powshell -- just figuring things out as I go along
(I'm a c# developer, just working in time to learn powershell because it
looks so darn cool)

I have seen some scripts referencing Lee Holmes's Parse-TextObject.

I got the code from his blog, and I'm trying to make it work. So far, when
I try to execute "parse-textobject", I get an error:
"The term 'parse-textobject' is not recognized as a cmdlet,
function,operable program, or script file"...

I'm guessing that Lee's code is a cmdlet, as opposed to a function or a
script, becuase it contains functions, and has a Main() method. Is that
correct?

It looks as though I am missing some kind of registration step where I tell
Powershell to add Parse-TextObject to its list of cmdlets. Also, I didn't
see anything inside of the code that associated the name Parse-TextObject
with the functions defined in the code. Is this done strictly by file name,
or is that part of the registration process that I am missing.

I tried adding the following line to My
Documents\WindowsPowershell\profile.ps1 (not sure if this is the right thing
to do or not, but it looked as though this is what the community extensions
use):
.. "$ProfileDir\Parse-TextObject.ps1"

Hi Jeremy;

You were right in your first guess to save the file to something called
"Parse-TextObject.ps1". It is usually helpful to put scripts and utilities
into a tools directory, which you add to your path. If you've done that,
then "Parse-TextObject" will work throughout PowerShell, so that could be
considered the registration mechanism if any.

If you don't put the script in your path, then you will have to tell
PowerShell the location of the script, like:

"Hello There" | c:\downloads\scripts\Parse-TextObject.ps1

As for your second question, it is still just a script. Functions and
parameters make large scripts easier to manage, which is why the script
includes them. A Cmdlet is a class compiled in a .NET language that uses the
PowerShell infrastructure:
http://msdn2.microsoft.com/en-us/library/ms714598.aspx.

--
Lee Holmes [MSFT]
Windows PowerShell Development
Microsoft Corporation
This posting is provided "AS IS" with no warranties, and confers no rights.


"J.Marsch" <jmarsch@newsgroup.nospam> wrote in message
news:OlE%23wqcOHHA.3900@TK2MSFTNGP06.phx.gbl...
> Hello All:
>
> I'm very much a newbie to Powshell -- just figuring things out as I go
> along (I'm a c# developer, just working in time to learn powershell
> because it looks so darn cool)
>
> I have seen some scripts referencing Lee Holmes's Parse-TextObject.
>
> I got the code from his blog, and I'm trying to make it work. So far,
> when I try to execute "parse-textobject", I get an error:
> "The term 'parse-textobject' is not recognized as a cmdlet,
> function,operable program, or script file"...
>
> I'm guessing that Lee's code is a cmdlet, as opposed to a function or a
> script, becuase it contains functions, and has a Main() method. Is that
> correct?
>
> It looks as though I am missing some kind of registration step where I
> tell Powershell to add Parse-TextObject to its list of cmdlets. Also, I
> didn't see anything inside of the code that associated the name
> Parse-TextObject with the functions defined in the code. Is this done
> strictly by file name, or is that part of the registration process that I
> am missing.
>
> I tried adding the following line to My
> Documents\WindowsPowershell\profile.ps1 (not sure if this is the right
> thing to do or not, but it looked as though this is what the community
> extensions use):
> . "$ProfileDir\Parse-TextObject.ps1"
>
>

"J.Marsch" <jmarsch@newsgroup.nospam> wrote in message
news:OlE%23wqcOHHA.3900@TK2MSFTNGP06.phx.gbl...
> I tried adding the following line to My
> Documents\WindowsPowershell\profile.ps1 (not sure if this is the right
> thing to do or not, but it looked as though this is what the community
> extensions use):
> . "$ProfileDir\Parse-TextObject.ps1"

Almost all of the PSCX scripts contain functions and variables that are
meant to be dot sourced into your global environment in order to be used.
We dot source most of these for your in the PSCX profile.ps1 script. In the
Parse-TextObject.ps1 case, as Lee has pointed out, it is meant to run as a
stand-alone script so you wouldn't want to dot source it.

--
Keith

Thank you for the excellent information, Lee and Keith. I have it working
now!


"J.Marsch" <jmarsch@newsgroup.nospam> wrote in message
news:OlE%23wqcOHHA.3900@TK2MSFTNGP06.phx.gbl...
> Hello All:
>
> I'm very much a newbie to Powshell -- just figuring things out as I go
> along (I'm a c# developer, just working in time to learn powershell
> because it looks so darn cool)
>
> I have seen some scripts referencing Lee Holmes's Parse-TextObject.
>
> I got the code from his blog, and I'm trying to make it work. So far,
> when I try to execute "parse-textobject", I get an error:
> "The term 'parse-textobject' is not recognized as a cmdlet,
> function,operable program, or script file"...
>
> I'm guessing that Lee's code is a cmdlet, as opposed to a function or a
> script, becuase it contains functions, and has a Main() method. Is that
> correct?
>
> It looks as though I am missing some kind of registration step where I
> tell Powershell to add Parse-TextObject to its list of cmdlets. Also, I
> didn't see anything inside of the code that associated the name
> Parse-TextObject with the functions defined in the code. Is this done
> strictly by file name, or is that part of the registration process that I
> am missing.
>
> I tried adding the following line to My
> Documents\WindowsPowershell\profile.ps1 (not sure if this is the right
> thing to do or not, but it looked as though this is what the community
> extensions use):
> . "$ProfileDir\Parse-TextObject.ps1"
>
>

I have another question for you about this, Lee:

I notice that when I got this all set up, I could just run
"Parse-TextObject" (I did not have to include a path or the extension).

I know the obvious answer is that "the file is in your environment path",
but most of the scripts that I have experimented with thus far have required
special syntax to run -- even if the script is in current directory, I have
to include the path and extension:
"./MyScript.ps1". In order to run. I have read that this is a security
feature and I understand the reasoning for it.

My question then, is why is the Parse-TextObject script an exception to this
rule? Is it soley because the script is in my path, is it because the
script file followed the naming standard of verb-noun, or does it have
something to do with syntax within the script?

Sorry for the silly questions -- I have found a lot of example scripts, but
I haven't found much documentation that describes the syntax or anatomy of a
script.


"Lee Holmes [MSFT]" <lee.holmes@online.microsoft.com> wrote in message
news:%23kU%23z8cOHHA.1248@TK2MSFTNGP02.phx.gbl...
> Hi Jeremy;
>
> You were right in your first guess to save the file to something called
> "Parse-TextObject.ps1". It is usually helpful to put scripts and utilities
> into a tools directory, which you add to your path. If you've done that,
> then "Parse-TextObject" will work throughout PowerShell, so that could be
> considered the registration mechanism if any.
>
> If you don't put the script in your path, then you will have to tell
> PowerShell the location of the script, like:
>
> "Hello There" | c:\downloads\scripts\Parse-TextObject.ps1
>
> As for your second question, it is still just a script. Functions and
> parameters make large scripts easier to manage, which is why the script
> includes them. A Cmdlet is a class compiled in a .NET language that uses
> the PowerShell infrastructure:
> http://msdn2.microsoft.com/en-us/library/ms714598.aspx.
>
> --
> Lee Holmes [MSFT]
> Windows PowerShell Development
> Microsoft Corporation
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>
>
> "J.Marsch" <jmarsch@newsgroup.nospam> wrote in message
> news:OlE%23wqcOHHA.3900@TK2MSFTNGP06.phx.gbl...
>> Hello All:
>>
>> I'm very much a newbie to Powshell -- just figuring things out as I go
>> along (I'm a c# developer, just working in time to learn powershell
>> because it looks so darn cool)
>>
>> I have seen some scripts referencing Lee Holmes's Parse-TextObject.
>>
>> I got the code from his blog, and I'm trying to make it work. So far,
>> when I try to execute "parse-textobject", I get an error:
>> "The term 'parse-textobject' is not recognized as a cmdlet,
>> function,operable program, or script file"...
>>
>> I'm guessing that Lee's code is a cmdlet, as opposed to a function or a
>> script, becuase it contains functions, and has a Main() method. Is that
>> correct?
>>
>> It looks as though I am missing some kind of registration step where I
>> tell Powershell to add Parse-TextObject to its list of cmdlets. Also, I
>> didn't see anything inside of the code that associated the name
>> Parse-TextObject with the functions defined in the code. Is this done
>> strictly by file name, or is that part of the registration process that I
>> am missing.
>>
>> I tried adding the following line to My
>> Documents\WindowsPowershell\profile.ps1 (not sure if this is the right
>> thing to do or not, but it looked as though this is what the community
>> extensions use):
>> . "$ProfileDir\Parse-TextObject.ps1"
>>
>>
>
>

Hi Jeremy;

It works without any special syntax because it is in your path. The "current directory" is not in your path, so scripts in the current directory require that you tell PowerShell where they are.

Does the following help clarify any questions about running scripts and tools? It's an exerpt from the book I'm writing:

Run Programs, Scripts, and Existing Tools
Problem
You have a lot of effort invested in your current tools. You have traditional executables, Perl scripts, VBScript, and of course, a legacy build system that has organically grown into a large bundle of batch files. You want to use PowerShell, but don't want to give up everything you already have.

Solution
Run a program in the system's path

Program.exe

Run a program that contains a space in its name

& 'C:\Program Files\Program\Program.exe' args

Run a program in the current directory

..\Program.exe args

Run a PowerShell script in the current directory

..\ScriptName args or .\ScriptName.ps1 args

Run a batch file

..\MyScript.cmd args

Discussion
In this case, the solution is to use your current tools as you always have. The only difference is that you run them in the PowerShell interactive shell, rather than cmd.exe.

The second and third commands in the list above merit special attention. They are the two features of PowerShell that many new users stumble on when it comes to running programs. The first is running commands that contain spaces. In cmd.exe, the way to run a command that contains spaces is to surround it with quotes:

"C:\Program Files\Program\Program.exe"

In PowerShell, though, placing text inside of quotes is part of a feature that lets you evaluate complex expressions at the prompt:

PS >1 + 1

2

PS >26 * 1.15

29.9

PS >"Hello" + " World"

Hello World

PS >"Hello World"

Hello World

PS >"C:\Program Files\Program\Program.exe"

C:\Program Files\Program\Program.exe

PS >

So, a program name in quotes is no different than any other string in quotes. It's just an expression. As shown above, the way to run a command in a string is to precede that string with the invoke (&) operator. If the command you want to run is a batch file that modifies its environment, see the section, "Program: Invoke-CmdScript".

The second command that new users (and seasoned veterans before coffee!) sometimes stumble on is running commands from the current directory. In cmd.exe, the current directory is considered part of the path - the list of directories that Windows searches to find the program name you typed. If you are in the C:\Programs directory, Windows looks in C:\Programs (among other places) for applications to run.

PowerShell, like most Unix shells, requires that you explicitly state your desire to run a program from the current directory. To do that, you use the .\Program.exe syntax, as shown above. This prevents malicious users on your system from littering your hard drive with evil programs that have names similar to (or the same as) commands you might run while visiting that directory.

To save themselves from having to type the location of commonly-used scripts and programs, many users put these utilities in a "tools" directory, which they add to their system's path. If PowerShell can find a script or utility in your system's path, you do not need to explicitly specify its location.

--
Lee Holmes [MSFT]
Windows PowerShell Development
Microsoft Corporation
This posting is provided "AS IS" with no warranties, and confers no rights.




"J.Marsch" <jmarsch@newsgroup.nospam> wrote in message news:uSPuAmnOHHA.1248@TK2MSFTNGP03.phx.gbl...
>I have another question for you about this, Lee:
>
> I notice that when I got this all set up, I could just run
> "Parse-TextObject" (I did not have to include a path or the extension).
>
> I know the obvious answer is that "the file is in your environment path",
> but most of the scripts that I have experimented with thus far have required
> special syntax to run -- even if the script is in current directory, I have
> to include the path and extension:
> "./MyScript.ps1". In order to run. I have read that this is a security
> feature and I understand the reasoning for it.
>
> My question then, is why is the Parse-TextObject script an exception to this
> rule? Is it soley because the script is in my path, is it because the
> script file followed the naming standard of verb-noun, or does it have
> something to do with syntax within the script?
>
> Sorry for the silly questions -- I have found a lot of example scripts, but
> I haven't found much documentation that describes the syntax or anatomy of a
> script.
>
>
> "Lee Holmes [MSFT]" <lee.holmes@online.microsoft.com> wrote in message
> news:%23kU%23z8cOHHA.1248@TK2MSFTNGP02.phx.gbl...
>> Hi Jeremy;
>>
>> You were right in your first guess to save the file to something called
>> "Parse-TextObject.ps1". It is usually helpful to put scripts and utilities
>> into a tools directory, which you add to your path. If you've done that,
>> then "Parse-TextObject" will work throughout PowerShell, so that could be
>> considered the registration mechanism if any.
>>
>> If you don't put the script in your path, then you will have to tell
>> PowerShell the location of the script, like:
>>
>> "Hello There" | c:\downloads\scripts\Parse-TextObject.ps1
>>
>> As for your second question, it is still just a script. Functions and
>> parameters make large scripts easier to manage, which is why the script
>> includes them. A Cmdlet is a class compiled in a .NET language that uses
>> the PowerShell infrastructure:
>> http://msdn2.microsoft.com/en-us/library/ms714598.aspx.
>>
>> --
>> Lee Holmes [MSFT]
>> Windows PowerShell Development
>> Microsoft Corporation
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>>
>>
>> "J.Marsch" <jmarsch@newsgroup.nospam> wrote in message
>> news:OlE%23wqcOHHA.3900@TK2MSFTNGP06.phx.gbl...
>>> Hello All:
>>>
>>> I'm very much a newbie to Powshell -- just figuring things out as I go
>>> along (I'm a c# developer, just working in time to learn powershell
>>> because it looks so darn cool)
>>>
>>> I have seen some scripts referencing Lee Holmes's Parse-TextObject.
>>>
>>> I got the code from his blog, and I'm trying to make it work. So far,
>>> when I try to execute "parse-textobject", I get an error:
>>> "The term 'parse-textobject' is not recognized as a cmdlet,
>>> function,operable program, or script file"...
>>>
>>> I'm guessing that Lee's code is a cmdlet, as opposed to a function or a
>>> script, becuase it contains functions, and has a Main() method. Is that
>>> correct?
>>>
>>> It looks as though I am missing some kind of registration step where I
>>> tell Powershell to add Parse-TextObject to its list of cmdlets. Also, I
>>> didn't see anything inside of the code that associated the name
>>> Parse-TextObject with the functions defined in the code. Is this done
>>> strictly by file name, or is that part of the registration process that I
>>> am missing.
>>>
>>> I tried adding the following line to My
>>> Documents\WindowsPowershell\profile.ps1 (not sure if this is the right
>>> thing to do or not, but it looked as though this is what the community
>>> extensions use):
>>> . "$ProfileDir\Parse-TextObject.ps1"
>>>
>>>
>>
>>
>
>

Thank you, Lee. I appreciate your time and response.

-- Jeremy
"Lee Holmes [MSFT]" <lee.holmes@online.microsoft.com> wrote in message news:OEUXqr0OHHA.4940@TK2MSFTNGP03.phx.gbl...
Hi Jeremy;

It works without any special syntax because it is in your path. The "current directory" is not in your path, so scripts in the current directory require that you tell PowerShell where they are.

Does the following help clarify any questions about running scripts and tools? It's an exerpt from the book I'm writing:

Run Programs, Scripts, and Existing Tools
Problem
You have a lot of effort invested in your current tools. You have traditional executables, Perl scripts, VBScript, and of course, a legacy build system that has organically grown into a large bundle of batch files. You want to use PowerShell, but don't want to give up everything you already have.

Solution
Run a program in the system's path

Program.exe

Run a program that contains a space in its name

& 'C:\Program Files\Program\Program.exe' args

Run a program in the current directory

.\Program.exe args

Run a PowerShell script in the current directory

.\ScriptName args or .\ScriptName.ps1 args

Run a batch file

.\MyScript.cmd args

Discussion
In this case, the solution is to use your current tools as you always have. The only difference is that you run them in the PowerShell interactive shell, rather than cmd.exe.

The second and third commands in the list above merit special attention. They are the two features of PowerShell that many new users stumble on when it comes to running programs. The first is running commands that contain spaces. In cmd.exe, the way to run a command that contains spaces is to surround it with quotes:

"C:\Program Files\Program\Program.exe"

In PowerShell, though, placing text inside of quotes is part of a feature that lets you evaluate complex expressions at the prompt:

PS >1 + 1

2

PS >26 * 1.15

29.9

PS >"Hello" + " World"

Hello World

PS >"Hello World"

Hello World

PS >"C:\Program Files\Program\Program.exe"

C:\Program Files\Program\Program.exe

PS >

So, a program name in quotes is no different than any other string in quotes. It's just an expression. As shown above, the way to run a command in a string is to precede that string with the invoke (&) operator. If the command you want to run is a batch file that modifies its environment, see the section, "Program: Invoke-CmdScript".

The second command that new users (and seasoned veterans before coffee!) sometimes stumble on is running commands from the current directory. In cmd.exe, the current directory is considered part of the path - the list of directories that Windows searches to find the program name you typed. If you are in the C:\Programs directory, Windows looks in C:\Programs (among other places) for applications to run.

PowerShell, like most Unix shells, requires that you explicitly state your desire to run a program from the current directory. To do that, you use the .\Program.exe syntax, as shown above. This prevents malicious users on your system from littering your hard drive with evil programs that have names similar to (or the same as) commands you might run while visiting that directory.

To save themselves from having to type the location of commonly-used scripts and programs, many users put these utilities in a "tools" directory, which they add to their system's path. If PowerShell can find a script or utility in your system's path, you do not need to explicitly specify its location.

--
Lee Holmes [MSFT]
Windows PowerShell Development
Microsoft Corporation
This posting is provided "AS IS" with no warranties, and confers no rights.




"J.Marsch" <jmarsch@newsgroup.nospam> wrote in message news:uSPuAmnOHHA.1248@TK2MSFTNGP03.phx.gbl...
>I have another question for you about this, Lee:
>
> I notice that when I got this all set up, I could just run
> "Parse-TextObject" (I did not have to include a path or the extension).
>
> I know the obvious answer is that "the file is in your environment path",
> but most of the scripts that I have experimented with thus far have required
> special syntax to run -- even if the script is in current directory, I have
> to include the path and extension:
> "./MyScript.ps1". In order to run. I have read that this is a security
> feature and I understand the reasoning for it.
>
> My question then, is why is the Parse-TextObject script an exception to this
> rule? Is it soley because the script is in my path, is it because the
> script file followed the naming standard of verb-noun, or does it have
> something to do with syntax within the script?
>
> Sorry for the silly questions -- I have found a lot of example scripts, but
> I haven't found much documentation that describes the syntax or anatomy of a
> script.
>
>
> "Lee Holmes [MSFT]" <lee.holmes@online.microsoft.com> wrote in message
> news:%23kU%23z8cOHHA.1248@TK2MSFTNGP02.phx.gbl...
>> Hi Jeremy;
>>
>> You were right in your first guess to save the file to something called
>> "Parse-TextObject.ps1". It is usually helpful to put scripts and utilities
>> into a tools directory, which you add to your path. If you've done that,
>> then "Parse-TextObject" will work throughout PowerShell, so that could be
>> considered the registration mechanism if any.
>>
>> If you don't put the script in your path, then you will have to tell
>> PowerShell the location of the script, like:
>>
>> "Hello There" | c:\downloads\scripts\Parse-TextObject.ps1
>>
>> As for your second question, it is still just a script. Functions and
>> parameters make large scripts easier to manage, which is why the script
>> includes them. A Cmdlet is a class compiled in a .NET language that uses
>> the PowerShell infrastructure:
>> http://msdn2.microsoft.com/en-us/library/ms714598.aspx.
>>
>> --
>> Lee Holmes [MSFT]
>> Windows PowerShell Development
>> Microsoft Corporation
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>>
>>
>> "J.Marsch" <jmarsch@newsgroup.nospam> wrote in message
>> news:OlE%23wqcOHHA.3900@TK2MSFTNGP06.phx.gbl...
>>> Hello All:
>>>
>>> I'm very much a newbie to Powshell -- just figuring things out as I go
>>> along (I'm a c# developer, just working in time to learn powershell
>>> because it looks so darn cool)
>>>
>>> I have seen some scripts referencing Lee Holmes's Parse-TextObject.
>>>
>>> I got the code from his blog, and I'm trying to make it work. So far,
>>> when I try to execute "parse-textobject", I get an error:
>>> "The term 'parse-textobject' is not recognized as a cmdlet,
>>> function,operable program, or script file"...
>>>
>>> I'm guessing that Lee's code is a cmdlet, as opposed to a function or a
>>> script, becuase it contains functions, and has a Main() method. Is that
>>> correct?
>>>
>>> It looks as though I am missing some kind of registration step where I
>>> tell Powershell to add Parse-TextObject to its list of cmdlets. Also, I
>>> didn't see anything inside of the code that associated the name
>>> Parse-TextObject with the functions defined in the code. Is this done
>>> strictly by file name, or is that part of the registration process that I
>>> am missing.
>>>
>>> I tried adding the following line to My
>>> Documents\WindowsPowershell\profile.ps1 (not sure if this is the right
>>> thing to do or not, but it looked as though this is what the community
>>> extensions use):
>>> . "$ProfileDir\Parse-TextObject.ps1"
>>>
>>>
>>
>>
>
>