in reply to printing a scalar as an array

Jonathan,

I'm not quite clear on what you want. If you have space separated data, you can use split as per sh1tn's post. On the other hand, if you want the array names in the __DATA__ block, you can do this:

my @array1 = qw(1 2 3 4 5); my @array2 = qw(a b c d e); my @array3 = qw(6 7 8 9 0); my @array4 = qw(f g h i j); while (<DATA>) { foreach (eval($_)) { print "$_\n"; } print "\n"; } __DATA__ @array1; @array2; @array3; @array4;

Update: Removed the quotes around $_ - quite right AM, my mistake. I tried various approaches to this problem, and the quotes were left over from a previous one.

As to use strict, I always always always use strict. In future I'll leave it in when posting code snippets.

VGhpcyBtZXNzYWdlIGludGVudGlvbmFsbHkgcG9pbnRsZXNz

Replies are listed 'Best First'.
Re^2: printing a scalar as an array
by tphyahoo (Vicar) on Feb 23, 2005 at 12:26 UTC
    Very nice. Two things

    1) use the strictures

    2) if you use perl -l flag in the shebang you can avoid newlines at the end of your prints.

    #!perl -l use strict; use warnings; my @array1 = qw(1 2 3 4 5); my @array2 = qw(a b c d e); my @array3 = qw(6 7 8 9 0); my @array4 = qw(f g h i j); while (<DATA>) { foreach (eval("$_")) { print "$_"; } print ''; } __DATA__ @array1; @array2; @array3; @array4;

    UPDATE: I semi-agree with dragonchild. Personally, I just recently have been learning about the command line flags, and I have a lot of scripts where the "\n" everywhere does annoy me a bit, and I like not having to do it anymnore. But OTOH it is a bit obfu.

    UPDATE2: Dragonchild opined to me that "command line switches are for use in the command line" which on reflection seems reasonable enough. So if you agree with this point of view, delete the shebang line (#!) and just call the script using "perl -l". I think I may adopt this approach myself.

    Update3: (Red in the face) All right, all right! Save the -l for one-liners. Never mind.

      Somedays, I wish I could both ++ and -- a post. (Guess which one I ended up doing ...)

      Yes, use the strictures. But, don't use the commandline flags in a production script! Good Gods, man, are you trying to get the OP to write obfuscated code?!? Who looks at the shebang line? If I were to read that code, I would be going bonkers trying to figure out how the newline was getting in there, and I golf with -l on a regular basis. (He shoots a 14 handicap, in case you're wondering.)

      Being right, does not endow the right to be rude; politeness costs nothing.
      Being unknowing, is not the same as being stupid.
      Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
      Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

        But, don't use the commandline flags in a production script! Good Gods, man, are you trying to get the OP to write obfuscated code?!? Who looks at the shebang line?
        Well, I think that -l is safe enough in short enough scripts. So it all depends on how short the production script will be, and of course a "production script", whatever it could be, tends to give the idea of being a rather longish thing, or if it is not, it's still likely to grow into one, so I think that you're right in the vast majority of cases.

        I think I have a tendency to overuse -l myself, because I like not to have to include literal newlines. But then when I want both this and to be safe I do

        { local $\="\n"; # or $/, if it's not been changed... print whatever; print something_else; # ... }

        Of course if we had Perl6's say() we wouldn't be bothered, but then someone will certainly point out that we already have a module for that. OTOH, IMHO it could easily leak into the core in some next major perl5 release, couldn't it?

      Using the stricture adds, uhm, exactly nothing at all to the above program. It just increases the size of the program text. As for adding -l, I tend to only do that for only liners - with normal programs, you just want to use 'print' without newlines often enough to make it a nuisance (it's still possible by using printf though). I disagree with the remark in update2 though. "Just calling the script using 'perl -l'" is a major PITA. You want to call program by just typing their file names, having to remember which interpreter they need is hard - and it's even harder to remember which program needs which command line options! Not to mention that that will make debugging even harder than having -l mentioned in the she-bang line - that's easier to spot than the -l enforced on the program from the outside.

      However, I only write this node because of something else. What's with the quotes around $_ in the print statement? If you're going to nag about (pointless in this case) missing "use strict" statements, and whether or not to use -l vs. a newline, you should at least get rid of the not needed quotes around the variable.

        "use strict" is not an option - it's a way of life!

        I would much rather see nagging (if I have to see nagging) about use strict than quotes around a $_ which will not add any overhead (?)

        Update: As for the 'perl -l' - I would lean away from that, but I have no real reasons I could back up. Why not just ($\="\n") ?
        --------------
        It's sad that a family can be torn apart by such a such a simple thing as a pack of wild dogs