I always prefer to have separate data file, unless it's a test or something.

What I would do in your case, is default to a file name, but allow the user to specify an alternate at the command line if they don't want to use the default. Go ahead and try this code without an argument (ie. perl script.pl), then create a second valid file, and run it with the arg (eg: perl script.pl input2.txt). Then, send in an invalid file name. In this case, it'll use the default (input.txt) (eg: perl script.pl not_exist.txt):

use warnings;
use strict;

my $file = 'input.txt';

if (@ARGV){
    if (! -e $ARGV[0]){
        warn "$ARGV[0] is not a valid file, using default\n";
    }
    else {
        $file = $ARGV[0];
    }
}

open my $fh, '<', $file or die $!;

while (<$fh>){
    print;
}
[download]

personally i (ab)use a lot the __DATA__ token. It's useful because can be used as other (even if bareword) filehandles.

It's free because magically appears to be valid as it is encountered in the file.

I use it when data is small or when I need to test some data exceptions so I put there worst cases mixed to some sane data and eventually some invalid row.

When I'm happy I just add a line opening an external file and I put the new (now lexical!) filehandle into the loop.

Also I hate Excel. More than the program in itself I hate the fact many people look at you bad if you do not declare to be an Excel wizard. So when some Excel task is given to me I export to comma separeted plain file and I put that blob under __DATA__ token. Then I excel..

In such, rare cases, i stick with the data into the file because both have no sense without the other.

But generally yes seems a good principle to have data separted from logic.

For default i use sometimes:$ARGV[0]//='input.txt' or $file=$ARGV[0]//='input.txt' for programs where only one argument is admitted. If more I use always Getopt::Long

For small hacks i (ab)use oneliners perl -lane ... does a lot of useful work for you in nothing. For example it auto chomp lines, thing you forgot to do in your above example ;=)

PS another useful thing for data are heredocs: sometimes I use one or more of them to test some XML parser logic extracted from a huge unreadable file.

L*

Q-1) Is this approach fine or is there any better way to do it?

It's fine so long as your dataset is regular and well-formed. If it starts to become less so there are other options: use a different format (XML, JSON, YAML, etc.), use a module (say Text::xSV or Text::CSV_XS), pre-process it, etc.

Q-2) Will it be better to embed the data in input.txt in the code itself rather than keeping it in a separate file?

Almost invariably no. Do you use a version control system? Hopefully the answer is "yes" in which case you would be committing deltas every time you change the dataset if it were embedded in the source. Equally, anyone else using your code would have to fire up an editor and know enough perl to be able to change the data without messing up the script syntax. Far, far better to have the data separated from the code.

The only time it is a good idea to embed data in code is for testing (including SSCCE). Your test data may not change (usually should not change) as if it did your test results might not be conclusive or reproducible.

All IMHO, of course.

If your data is small and changes with each run, you might want to consider just putting it on the command line:

$ myprogram.pl 'text1 string1 word1 number1,text2 string2 ...

# then process @ARGV
for ( split /,/, $ARGV[0] ){
    subroutine1( split/ /, $_ );
}
[download]

Thank you stevieb, Discipulus, Anonymous Monk, hippo for all your inputs.

This is not for test so I'll not add data in code and will keep it in separate file as it is now. Making the default file and giving user option to give a different filename is pretty useful but this has to be run through a cron in this particular case. I have not used __DATA__ much until now but will explore it.