2

Given a mixed environment of Windows servers, Linux (RHEL5) servers, and XP clients, can anyone foresee benefits and/or problems attempting to use Perl 5.10 for logon/logout scripts?

Thanks.

Using *.cmd files will be much easier and faster for the simple things I'll attempt with logon/logout scripts. Thanks for your insight.

Improve this question
1
  • Why not PowerShell? Commented Jun 8, 2009 at 5:23

4 Answers 4

Reset to default
2

I disagree with some of the other posts. I have never had a problem with Perl on Windows. If there are Linux/UNIX machines in the same environment, many scripts can be run as-is on both. Also, the only alternative I see on Windows would be VB, which if you don't know, there is little point in learning. If you are a Perl programmer, Perl is the right tool for the job.

Improve this answer
1

Personally, I wouldn't use Perl, simply because it's not native to Windows (and I love Perl). Ensuring that you have all of the requisite modules available somewhere either on the network or ensuring that every machine that has the exact same copy of Perl installed, with all required modules can get very painful.

If a login script requires a full programming language, you may be trying to do too much at login (and users don't appreciate long login delays). n most instances, you would be better placed using .cmd scripts or VBscript. The advantage of this is that you won't have to install anything and it should just work. The disadvantage, of course, is that you have to learn .cmd scripting or VBScript.

Improve this answer
1

An obvious advantage of Perl is that it's cross platform, so you can use the same code on all machines. (However, depending on what you want to accomplish, the way to accomplish it may itself vary between Linux and Windows, so that may or may not end up being an actual advantage.)

Consider Strawberry Perl (rather than ActiveState), it's considerably more streamlined these days.

Consider installing CPAN modules on one machine, and make the site_lib available over a network drive for all other machines (set the PERL5LIB environment variable to add it to the @INC directories). Hmmm... will this work for login scripts? Not sure.

Look into the Win32::OLE module for interacting with Windows specific things.

Improve this answer
0

Keeping the environment consistent will be rather obnoxious, particularly if you use CPAN modules.

I haven't seen logon scripts used in like 7-8 years... what are you trying to do?

Improve this answer
1
  • You can run Perl from a shared network location without needing an explicit install on each client to get around this - there will be some issues but they are less problematic than maintaining discrete installs on all clients which, as you rightly point out, is rather obnoxious. +1 on the need for logon scripts though - I still see them a lot but there are better solutions now (policies enforced by various means) and that handle more dynamic user behaviors (logons are rarer now, machine\user states change often between logons especially on laptops) that traditional logon scripts cannot. Commented Jun 20, 2009 at 1:47

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.