intro to perl scripting

[slag]

I'm not a programmer, but I use solaris and linux a lot at work and know that unix scripting and perl scripting would make my life much simpler, plus, its a great skillset to have.

Problem is, I'm not a book learner. I've read several into to perl scripting books and just cant grasp it. Its a foreign language to me and I don't really learn anything.

What technique do you use to learn something new like a scripting language? Sure, the books explain expressions and things like that, but I can't retain it and use it practically to where it would be useful to me.

 

[Chosonman]

w3schools.com

oops they don't teach perl..

 

[Chosonman]

Most server side scripting languages are very similar. If you learn one the others should be relatively easy to grasp. It also helps to install a server so you can "play" and test your code as you learn.

 

[Onund]

perl is probably the ugliest programming language out there. I believe the perl motto is "there's more than one way to do it" meaning you can probably invent 5 or 6 different ways of doing the same thing, take case structures for example, perl doesn't have the classic case statement so my O'Reilly book provides 6 alternatives to acheive the same thing. The more expert a coder is, the more archaic and less readable their perl code will be, IMO.

Still, I find perl extremely flexible and easy to use when it comes to parsing any type of text file so I use it lots and love it for that. I just don't expect to ever understand other peoples perl programs and don't expect people to be able to read mine

As for learning how to use perl without reading books, you'd need to come up with some sort of small program that would be handy for you, say you want to parse a log file for warnings. Assuming it's a log file from some tool you use. Break your program down into chunks and figure out how to do each step. For example:

1. open file
2. read each line
3. test line for words: "warning" and "WARNING" and Warning"
4. Display a message saying a warning was found at some line, and probably display the line
5. output the warning lines to some file
6. pick the Kentucky derby winner

Then you can incrementially build up your program. Step 1: google "perl open file" and see the examples, implement and see if your program will work. You can always use print statements to see what you're getting. Step 2: google "perl print"... you see where I'm going.

The trick is finding something that will be useful to you. If it isn't useful to you then you'll probably lack the motivation to do it.

 

[Crusty]

I took a 1 credit hour Perl class a few years ago. Gave me enough to get started. I don't use Perl every day and I'm by no means good at it, but I learned enough to get me by

 

[esun]

Pick a problem. For example, you have some data in a text file that you want to do something with (parse it, interpret it, whatever). Then, using the documentation at http://perldoc.perl.org/, write it.

Do that a dozen or so times. After that, you'll know it well enough to use it in day-to-day work.

 

[eakers]

i just did an online tutorial and after about five minutes I found it was a lot like shell scripting and php so I gave up on the tutorial and just did what i had to do.

There are some really good tutorials around, just google perl tutorial and work your way though one.

 

[NTB]

what sort of stuff are you looking to do? If you have some specific ideas, that might help us narrow down a way to help you get into the language.

For my own part, I *am* a bookworm, and I learned the basics by reading an on-line tutorial at work not long after I started - I was waiting to get all my access rights set up and some other programs installed on my PC before I could actually 'get to work'.

Almost 2 years later, I still use it quite a bit, and I like it. True, Perl can be ugly, but it doesn't have to be; it's all in how you choose to write. I like it because of the flexibility it offers. For example: my work PC is a Windows XP box, but I do a lot of work on HP-UX boxes (via telnet), as well. Perl allows me to develop and test most things own PC, and then when I get close to a working solution, move the code out to the UNIX machine with few, if any, changes.

Knowing Perl also means that, more often than not, if someone on my team at work comes across something unusual, I end up with it: 'here's what we need; here is what we've been given.'. And I have to figure out how to go between the two. It's always something a little different, and that keeps things interesting

Nathan