How do you perl? (A question about operating systems and other dependencies)

[PerlingTheUK]

Hello esteemed Monks,

During the last weeks I have had an approach to PerlNET which - and I am sure ill get slaughtered for this - I actually quite like within the tiny niche it might serve.
However I am more interested in getting an understanding how other people actually use Perl. I have started using Perl at university and had lots of uses for it for a part time job. I created a very tiny CMS system using an XML database for a library. All this was pure UNIX even though the scripts would surely work on any windows machines as well they never lived up to it and likely never will.
After perling for about 2 years in Unix and Linux I suddenly had to call a windos executable. So suddenly I realized there were some Win (lose?) modules and that active state was around. What seemed to be an exotic exception has now developed to a full time Windows based development.
I am now working in a windows dominated place, and apart from simple administration jobs all I do is for windows.
About two months or so ago I finally got fed up with TK and had a nice idea: Visual studio offers an easy way to use C++ and other languages to develop user interfaces. So I have now started setting my "Forms" up in C# and it saves me days, and then reference my dll from what is still perl, using its unique power to handle my database interaction and data conversion that makes the huge share of my work.

So how are other people on this website using perl? From very limited .NET nodes I consider this to be very unpopular, but are you using Linux/Windows do you interface with other tools? I am interested in getting an overview about how other people have approached the variety of possiblities in how to use this.

[Dietz]

Well, I use Perl for all sorts of administrating IBM Tivoli (Framework and products like Monitoring, Event Console, and many more).
There are a lot of builtin binaries which come with Tivoli but if you want to get to the core details and have to manipulate configurations of registered objects (Endpoints, ProfileManagers, PolicyRegions, etc.) you have to lookup attributes and methods all by yourself with IDL commands in the Tivoli Object Database which is CORBA-based.

The output is often presented in nearly readable dumps and you have to pipe your desired output extraction to the next IDL command to handle your way to the core.
Though there are binaries to let you get overall information on registered objects but they are only scratching the surface of the object database.
Sometimes there is no other way than manipulating the object database because of the lack of existing builtin binaries.

And here comes Perl handy with its text processing power.

By coding scripts in Perl to maintain Tivoli, I learn a lot of Tivoli internals and the lack of yet not written but desired scripts/binaries, I too improve my Perl skills.

Thanks to IBM because in forcing me to write code for my own needs ;-)
Would I have learnt Perl anyways if it wasn't necessary for Tivoli's sake?
I'm not sure.

After 8 years in our company I switched over to our Tivoli Team.
I only had a Win32 background (and OS/2 in the old days) when I started with Tivoli back in 2002/2003.
I was doing general Systems Management, support and installations in our company before I switched over to our Tivoli Team.
Our TMR Server is on AIX so I had to adopt UNIX skills and that was the time I discovered Perl.
Nowadays I'm using Linux at home instead of Win32 and there is so much more to learn.

Knowing now the beauty and strength of Perl, I am thankful that I have moved this way.


Regards,
Dietz

[pg]

As for Tk, my principle is: if I already picked Perl for a task as it is the best fit, I will use Tk for GUI interface if there is a need; but if GUI is so important for that task, I will never pick Tk, in that case I would either go web, or Java (most likely will switch to C# in the near future.)

"From very limited .NET nodes I consider this to be very unpopular"

;-) Now this is a Perl site, we come here to talk about Perl. It is expected to see "very limited" .NET node, but it is sort of jump to concolusion when you said .NET is "very unpopular". It is impotrant to pick the right tool for the right task, to be able to do that, you have to first realize what tools are available there.

[strat]

My main usage of Perl for my profession is writing synchronisations between different kind of databases (e.g. synchronisation tools to metadirectories), and sometimes web programming with mod_perl (see http://develop.perl-community.de/ as an example) and sometimes CGI, Tk for administration tools and user applications, oneliners in the shell (e.g. filtering ldif-files perl -i.bak -ne '$/="\n\n";print unless /^attribute: value$/m' filename, which may be the reason why I never can't remember the exact syntax of some unix shell programs). As a hobby, I try about everything because I've found out that perl is the best game I know...

Main operating systems: Solaris, Linux, Win2003/XP/2k

[TedPride]

I mainly use Perl for algorithms-heavy stuff on my own comp (Mac OS 9 / OS X), and for site maintenance on our remote hosting account (some flavor of Unix). I tend to use PHP for the simpler inline coding, since the remote hosting account doesn't run mod_perl and PHP is easier to embed in pages.

[Courage]

Couple of years ago I used C++ Builder to draw GUI (WYSIWYG) and had hooks to my scripts from there.

After time passed I refused of this approach due to lack of supported OSes.
(no support for WinCE, which I very like to use)

Now I use Perl and Tcl/Tk simultaneously (Tcl/Tk only for GUI) and happy with that, because I have:

• WYSIWYG IDE (I mean http://vtcl.sf.net)
• crossplatform (I use Linux, Win32, WinCE)
• powerfull Text and Canvas widgets, which I really appresiate

[perlcapt]

My use of Perl is in a more traditional: information processing and management, generally without any GUI interface. My experiences with GUI building have led me to believe that I'm not cut out for that kind of work, except perhaps, the occasional CGI-type interface. Tk and I don't get along. I've tried several (Perl | Tcl)/Tk projects and ended up finding another way to develop the GUI.

As a clarification of what I consider "information processing," I include the searching, indexing, formatting, restructering of both textual and binary data. The later is usually considered data processing, but I have an unfortunate association of that term with COBOL. The processing of binary data may seem more appropriate to C++, but Perl has no bias toward just processing ASCII text; regular expressions can work very well on binary stuff, after all, they work on international text. Minimizing development time is more important to me than minimizing run time. If there are sections that are REALLY slow, and they are good Perl, they can, with some little effort, be rewritten in C++ and made into a runtime loadable library.

My platform of choice is *nix, mainly because that is what I grew up with. I do work in the Window environment, but primarily for running applications that one can find only there, and which typically are heavy on graphics. For developing, I still haven't found anything better than the *nix environment, editors, tools, shells, etc. None-the-less, I am always looking for better ways of using my Windows machines. Cygwin has been a great help in bridging the gap, as has ActiveState's Windows products. But, Linux isn't going to fade away any time soon. As long as it or something derived from the same roots is around, I'll be using it.

[WhiteBird]

My work environment is strictly windows based, so I primarily build using ActiveState Perl. Most of what I do are web-based applications and database connections into mySQL, MS SQL server and MS Access. I've also found Perl to be extremely useful for quick and easy data munging tasks, and occasional systems maintainence issues. Perl has even come in handy for a couple of tasks involving Lotus Notes and Domino. For me, Perl lives up to its reputation as being the swiss army knife in my programming toolbox.

I've come up with an interesting dilemma recently that involves .NET programming. I have to automate some data entry into our legacy system and the only scripting tools I have are built around Visual Basic .NET. Part of my task requires that I open a text file, unpack the data and feed it into different parts of the legacy system. It seems almost trivial to do the data work with Perl, but I can't get the legacy system to allow Perl into it's innards. So far, the .NET data manipulation seems cumbersome in comparison and since I'm not an experienced VB programmer I'm having to learn-as-I-go. I've been tempted to somehow drop some kind of Perl wrapper around the VB program, letting Perl do the text processing and then calling the .NET stuff to make the connection to the back end database to deliver the data. Your comments make me think that this idea isn't as crazy as I first thought. Maybe .NET and Perl can play well together?

[Mutant]

If I'm creating an application that needs some sort of non-technical person interface (which seems to be most of the time these days..) then I'll use a web interface (hopefully with mod_perl). Although web interfaces aren't as elegant as a full blown GUI, they massively simply things such as deployment, fault tracking and reporting/logging.

In my experience, the part the 'whole world' sees is usally about 20-30% of the application... the rest is the administration interface.

[rev_1318]

I use Perl almost exclusively for *nix system administration. We use it to automate creation of user accounts, websites etc.. When creating user interfaces, we use web-based forms and Perl CGI scripts to provide uniform interfaces for Operations. But most tools and applications come wothout interface (batch oriented) or with commandline interfaces. But, working in an all-unix environment, we're used to that. The main projects I'm working on at the moment are: Centralized jobscheduling, centralized web-based management of cisco routers and switches, uniform oracle database management and user/website management. Cheers, Paul