Saurabh Singhvi wrote: > well i was trying to understand the "regular > expressions" in perl when i came across <STDIN>
Please recognize this as the coincidence it is. Regular expressions and filehandles are two different subjects. If you are somehow linking the particular built-in filehandle with the regular epression tools, you should break the linkage, and study each on its own. > i > tried my best but i havent been able to get the > slightest idea on how the input thing works. The thing that works is not the filehandle itself, but the getline operator <>. Placing the filehandle STDIN within the angle barckets--in a context where the expreesion is an rvalue in a scalar assignment, tells the operator to act on STDIN. Likewise, when taken in an array or list context, the operator gets all lines/records from the file and pushes each into the list on the left of the assignment. > The > editor i use is DzSoft. Was this editor designed for Perl? I would recommend using a simple code editor that offers auto-indent and Unix line endings. but without code-sensitive features. Your best bet is to take the error and warnings messages directly from the command-line, since an intermediary application may simply add another layer of confusion > And it shows something like > "get" and something else below like script something "something"s will seldom lead to progess in debugging. I don't mean to be picky here, but programming is a preisise art, where each character is in the code for a specific, and hopefully well-tought-out reason. Likewise, debugging messages arte delivered in as exact a form as logically possible. I put it this way because the interpreter generally issues an error only when the meaning or intent of code is impossible to decipher. When you use strict, you essentially tell the interpreter to do a little ;ess mind-reading, and to tell you when your instructions are too vague to be dependable. > > with blank space. > > Any hopes 4 me?? :-( Sure. use strict; Pay attention to the exact wording of messages returned by the interpreter. Don't deal with thingies, gizmos, or whatnots. Learn specific program structures and constructs, and respect the material. If you have a true passion for creating process, and you are willing to put serous and careful work into it, you can learn to program. Joseph -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
