Newbie Question - Uses for PowerShell
Kim Finleyson
I'm a complete newbie to PowerShell, but have an occasional need for
scripting. I have 2 questions:
(1) Today one of the developers that I work with told me it was going to
replace VB and Perl. Is there any truth to this?
(2) I have a folder containing about 30 XML files. Occasionally I need to
run some kind of a global find and replace where specific text is found and
replaced with different text. Would PowerShell be the best tool to use to
automate this process?
Thanks
Brandon Shell
incredible ride. I think its important to understand that powershell really
doesn't replace... it is really a paradigm shift. Its a whole new way to
look at things and deal with problems.
- I would not go so far as to say it will replace Perl or vbscript, but I
believe as its market grows people will realize the power and will move away
from other languages. Also... as more MS/Third Party products adopt it (like
Exchange) it will start to dominate samples and thus one would be nudged in
that direction.
- The task your requesting is simple in powershell. Here is one liner. There
are tons of ways to do this. This was just the first I came up with.
PS> get-childitem *.xml | foreach-object{ (get-content $_.fullname) -replace
"Old Text","New Text" | out-file $_.FullName -Enc ASCII}
I break that line down to exactly what its doing (at the bottom if you care
:) )
Step/Step on one liner :)
get-childitem *.xml # list the XML files and sends them down the pipe
# foreach-object parses each item in the pipe... in this case each xml file
foreach-object
{
# get-content $_.FullName gets text from file and sends
# -replace is an operator that replaces string with newstring (more info
by help about_operator)
# out-file $_.FullName -Enc ASCII : out-file takes the text from the
pipe and writes to file.
(get-content $_.fullname) -replace "Old Text","New Text" | out-file
$_.FullName -Enc ASCII
}
"Kim Finleyson" <kfinleyson@[nospam]gmail.com> wrote in message
news:CAB78FDB-A869-4A89...@microsoft.com...
Jacques Barathon [MS]
news:uwM3lPR...@TK2MSFTNGP04.phx.gbl...
...
> - The task your requesting is simple in powershell. Here is one liner.
> There are tons of ways to do this. This was just the first I came up with.
> PS> get-childitem *.xml | foreach-object{ (get-content
> $_.fullname) -replace "Old Text","New Text" | out-file $_.FullName -Enc
> ASCII}
All three cmdlets get-childitem, get-content and out-file manipulate file
objects. Therefore you can directly pass the objects through the pipeline
without having to refer to their FullName property:
get-childitem *.xml | foreach {(get-content $_) -replace "old text","new
text" | out-file $_ -enc ASCII}
Jacques
RichS
given Microsoft statements that PowerShell support will be built into all
products and that VBScript is regarded as completed with no further
enhancements planned it is probably safe to assume that PowerShell will
become the standard scripting environment on the Microsoft platform.
It will not happen overnight and VBScript and PowerShell will co-exist for
quite a while yet. Given the flexibility and power of PowerShell it will be
the language to learn for Windows adminsitrative scripting
--
Richard Siddaway
Please note that all scripts are supplied "as is" and with no warranty
Blog: http://richardsiddaway.spaces.live.com/
PowerShell User Group: http://www.get-psuguk.org.uk
"Jacques Barathon [MS]" wrote:
> "Brandon Shell" <tshel...@gmail.com> wrote in message
> news:uwM3lPR...@TK2MSFTNGP04.phx.gbl...
> ....
Al Dunbar
"RichS" <Ri...@discussions.microsoft.com> wrote in message
news:CA928E99-DF2F-44AE...@microsoft.com...
> Perl isn't a Microsoft technology so PowerShell can't replace it. However
> given Microsoft statements that PowerShell support will be built into all
> products and that VBScript is regarded as completed with no further
> enhancements planned it is probably safe to assume that PowerShell will
> become the standard scripting environment on the Microsoft platform.
I once thought of vbscript in the same way. I will find it more interesting
to see that powershell's "market share" increase without being supplanted by
an as yet unimagined new paradigm, than to see it beat the other scripting
platforms into the ground.
> It will not happen overnight and VBScript and PowerShell will co-exist for
> quite a while yet. Given the flexibility and power of PowerShell it will
> be
> the language to learn for Windows adminsitrative scripting
Most definitely. But it still seems a bit of a "version 1.0" thing in some
areas, including ADSI and remote scripting capability, to name just two.
Still, if seems way out in the lead in the admin scripting area. But there
are other areas, like logon scripting, where it seems a bit overblown.
/Al
RichS
a route I would want to go just yet
--
Richard Siddaway
Please note that all scripts are supplied "as is" and with no warranty
Blog: http://richardsiddaway.spaces.live.com/
PowerShell User Group: http://www.get-psuguk.org.uk
Chris Warwick
<Ri...@discussions.microsoft.com> wrote:
>Logon scripts are definitely an issue for PowerShell I think. Not sure thats
>a route I would want to go just yet
Wouldn't it be good if it were installed by default and controlled
through group policy? No issue then.
Chris
Al Dunbar
"Chris Warwick" <ne...@remove.this.bit.nuney.com> wrote in message
news:d7a083hlc7lug0si2...@4ax.com...
I see an issue. If you are doing so much in your logon scripts that you need
a scripting language as powerful as powershell, I would suggest you are
pushing logon script functionality beyond its useful range. But that's just
me...
/Al
Chris Warwick
From my point of view (and as already mentioned by someone else in a
similar thread today) the issue isn't that you *need* to use
PowerShell, it's that PowerShell is your scripting tool of choice and
you don't want to have to (Unix stylee) use multiple tools if you
don't have to. Sure I could write my logon scripts in .cmd files (or
KixTart, or Perl, or VBScript or even Awk I guess) but why should I
need to?
I'm just ever-so-slightly frustrated that MS are providing a great
tool but are making it more difficult to access than it needs to be in
some cases (and possibly, unfortunately, for internal political rather
than technical reasons).
Not a big deal - but that's the way I see it!
Chris
Al Dunbar
> On Wed, 27 Jun 2007 00:23:23 -0600, "Al Dunbar"
> <Alan...@hotmail.com.nospaam> wrote:
>
>>
>>"Chris Warwick" <ne...@remove.this.bit.nuney.com> wrote in message
>>news:d7a083hlc7lug0si2...@4ax.com...
>>> On Mon, 25 Jun 2007 08:57:00 -0700, RichS
>>> <Ri...@discussions.microsoft.com> wrote:
>>>
>>>>Logon scripts are definitely an issue for PowerShell I think. Not sure
>>>>thats
>>>>a route I would want to go just yet
>>>
>>> Wouldn't it be good if it were installed by default and controlled
>>> through group policy? No issue then.
>>
>>I see an issue. If you are doing so much in your logon scripts that you
>>need
>>a scripting language as powerful as powershell, I would suggest you are
>>pushing logon script functionality beyond its useful range. But that's
>>just
>>me...
>>
>>/Al
>>
>
> From my point of view (and as already mentioned by someone else in a
> similar thread today) the issue isn't that you *need* to use
> PowerShell, it's that PowerShell is your scripting tool of choice
I would have to agree with you there...
> and
> you don't want to have to (Unix stylee) use multiple tools if you
> don't have to.
Certainly not if you don't have to. But sometimes it makes sense to put the
backhoe away in favour of that old shovel for the smaller jobs.Same, imho,
with scripting tools. Now, I wouldn't suggest one go out and learn vbscript
because it might be considered better sized for writing logon scripts, but
if you already know it... Note that, in my mind, logon scripts are and
should be VERY simple, so should not require a vbscript degree to write.
> Sure I could write my logon scripts in .cmd files (or
> KixTart, or Perl, or VBScript or even Awk I guess) but why should I
> need to?
Well, what do you write them in now? If you are using these, then the issue
is not "why" you should need to but "that" you should need to. I try to
avoid spending/wasting too much time wondering why things are the way they
are, that only keeps me from actually getting somewhere.
> I'm just ever-so-slightly frustrated that MS are providing a great
> tool but are making it more difficult to access than it needs to be in
> some cases (and possibly, unfortunately, for internal political rather
> than technical reasons).
Perhaps they steered away from making it more logon-script friendly in
favour of dealing with the 1001 other scripting tasks that were crying out
for something new.
/Al
Chris Warwick
<Alan...@hotmail.com.nospaam> wrote:
...
>Certainly not if you don't have to. But sometimes it makes sense to put the
>backhoe away in favour of that old shovel for the smaller jobs.Same, imho,
>with scripting tools. Now, I wouldn't suggest one go out and learn vbscript
>because it might be considered better sized for writing logon scripts, but
>if you already know it... Note that, in my mind, logon scripts are and
>should be VERY simple, so should not require a vbscript degree to write.
Very true! I'd just prefer a very simple script in PowerShell than in
.cmd:-)
Having said that I once got involved (against my advice) in writing a
KixTart login script for a large London-based regional public
transport organisation that spanned several pages; no one wants to
maintain that I'm sure:-)
>Well, what do you write them in now?
.cmd script mostly (I have a pathological dislike of VBScript; no one
else knows JScript and no other facilities (including PowerShell) are
included on all installations, which leaves cmd.exe as the lowest
common denominator)
> I try to
>avoid spending/wasting too much time wondering why things are the way they
>are, that only keeps me from actually getting somewhere.
Fantastic point - very well made! I can't resist rattling the bars
every so often though:-)
>Perhaps they steered away from making it more logon-script friendly in
>favour of dealing with the 1001 other scripting tasks that were crying out
>for something new.
I actually don't think it's "logon-script-unfriendly" - I just wish
there were at least plans to include it globally (like vbs, js, cmd)
so I could rely on it being there on arbitrary machines for my use -
at least in the future....
Thanks for your thoughts - sorry to be a moany old git:-)
Chris
Al Dunbar
> On Wed, 27 Jun 2007 16:34:31 -0600, "Al Dunbar"
> <Alan...@hotmail.com.nospaam> wrote:
>
> ...
>>Certainly not if you don't have to. But sometimes it makes sense to put
>>the
>>backhoe away in favour of that old shovel for the smaller jobs.Same, imho,
>>with scripting tools. Now, I wouldn't suggest one go out and learn
>>vbscript
>>because it might be considered better sized for writing logon scripts, but
>>if you already know it... Note that, in my mind, logon scripts are and
>>should be VERY simple, so should not require a vbscript degree to write.
>
> Very true! I'd just prefer a very simple script in PowerShell than in
> .cmd:-)
>
> Having said that I once got involved (against my advice) in writing a
> KixTart login script for a large London-based regional public
> transport organisation that spanned several pages; no one wants to
> maintain that I'm sure:-)
Then you'll appreciate what I faced when I took on the task of converting a
similarly messy set of kixtart scripts (the national script called the
region-specific script which called the site-specifit script, and all were
authored by different individuals) into a vbscript version that maintainted
the essentials of the original scripts...
>>Well, what do you write them in now?
>
> .cmd script mostly (I have a pathological dislike of VBScript; no one
> else knows JScript and no other facilities (including PowerShell) are
> included on all installations, which leaves cmd.exe as the lowest
> common denominator)
At least you state your bias up-front - I like that. Where we differ is that
I tend to like VBScript.
>> I try to
>>avoid spending/wasting too much time wondering why things are the way they
>>are, that only keeps me from actually getting somewhere.
>
> Fantastic point - very well made! I can't resist rattling the bars
> every so often though:-)
Same here, but I'm an "old enough git" myself to realize that fewer of these
arguments are as winnable as when I was younger...
>>Perhaps they steered away from making it more logon-script friendly in
>>favour of dealing with the 1001 other scripting tasks that were crying out
>>for something new.
>
> I actually don't think it's "logon-script-unfriendly" - I just wish
> there were at least plans to include it globally (like vbs, js, cmd)
> so I could rely on it being there on arbitrary machines for my use -
> at least in the future....
>
> Thanks for your thoughts - sorry to be a moany old git:-)
You're welcome. As to the logon-unfriendly status, that is my bias showing,
powershell being the backhoe to vbscript's shovel, or to CMD's trowel.
Sometime after I finished the logon script conversion I mentioned above, I
found out from the Microsoft consultant of some performance issues related
to the script consisting of multiple files located in a moderately nested
directory structure. I wonder what similar impacts there might be running a
powershell logon script. And can it be specified directly, or would it have
to be launched from a batch file?
/Al