Thank you all for the suggestions. Based on discussion here, I went back and looked at my perl reference book. It looks like here-doc serves the purpose well. The answer was there but I did not know where to look ..
Thanks .. PS: BTW Boliger, there is nothing wrong with your english. It is better than mine for sure .. On 2/8/07, D. Bolliger <[EMAIL PROTECTED]> wrote:
Sharan Basappa am Mittwoch, 7. Februar 2007 16:13: > On 2/7/07, Rob Dixon <[EMAIL PROTECTED]> wrote: > > Sharan Basappa wrote: > > > On 2/6/07, Tom Phoenix <[EMAIL PROTECTED]> wrote: > > >> On 2/6/07, Sharan Basappa <[EMAIL PROTECTED]> wrote: > > >>> Question is how to embed text in a perl program instead of reading it > > >>> from a file or initializing the text in a string variable. [snipped] > > >> > while (<MY_BLOCK>) > > >> > > > >> > __MY_BLOCK__ > > >> > > >> It looks as if you've seen the special DATA filehandle and the > > >> __DATA__ marker; but those don't generalize like that. Nice try, > > >> though. (If you change those back to DATA in your program, I think it > > >> will do what you expected. Consider adding 'use strict' and 'use > > >> warnings', though.) > > > > > > What if I wanted to have multiple embedded (and separate) texts > > > embedded in > > > my program. [snipped] > > What the DATA filehandle does is to allow the Perl program to read from > > its own > > source file. The read position is set initially to the point after the > > end of > > the program marked by the __END__ tag (as a mnemonic the __DATA__ tag > > serves the > > same purpose). Since a program has only one source file there can be only > > one > > such magic filehandle. (As a point of interest, it's possible for a > > program to > > read its own source by issuing "seek DATA, 0, 0" before reading from the > > handle.) > > > > It's clearly possible to add markers within the data so the the program > > can > > split it up itself, but how about explaining a little more about what you > > want > > to do: I'm sure the list can come up with an appropriate solution for > > you. What > > is wrong, for instance, with using real separate data files? > > Actually I am writing a script that actually spits out various make > template files. > People then fill in these templates with neccessary details and use them. > The thing is that there are atleast 4-5 different templates and depending > on the > cmd line arg, the script needs to output one of these template files. > Definitely > I would not like to open a file, read it and then output it since moving > the script > (to another project etc) would mean that the files need to be moved too. > Having this information in the same script would make it self contained. > > Does that make sense... Hello Sharan Another possibility to avoid reading external data that would have to be moved with the script could be (but this depends a bit from the details) to design a template base class and, for every template, a separate subclass. The script itself could be very short, and would load (use) the appropriate subclass determined by the argument(s). To add a new template, you would not have to edit an existent file, but just add a new subclass. No need to move the modules around for a new project on the same machine; and for new projects on another machine, you could pack the modules into a distribution and install it with a few make commands. When going this way, chances are that you don't have to deal with redundant data at different places in case of changes/additions. From this point of view, a "self contained script" could be a disadvantage. This may be overkill; but if there's a possibility that the whole thing had to be expanded in the future, it's maybe not. Sorry for my english; I hope I did not miss an important point and my suggestions makes some sense. :-) Dani -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] http://learn.perl.org/
