«

I have solved my actual programming problem, but was frustrated in my
attempt to determine the behaviour of @ARGV in the online docs.

I want to combine data from two files. This combined data will be sorted
and modified in various ways which aren't of any importance except that
I need to keep track of which file each datum came from.

I expected the following to do what I needed:

#!/usr/bin/perl
use warnings;
use strict;

my @data;
while (<>) {
chomp;
# print "$ARGV, $ARGV[0]\n"; # For debugging
my $file = ($ARGV eq $ARGV[0]) ? "First" : "Second";
push @data, [ $file , split(/,/) ];
}

foreach (@data) { print "@$_\n" };
__END__

I tested this program using two suitable files of three lines each
(appended at the end of this message) and was surprised by the following
output:

Use of uninitialized value in string eq at try line 8, <> line 4.
Use of uninitialized value in string eq at try line 8, <> line 5.
Use of uninitialized value in string eq at try line 8, <> line 6.
Second a b c
Second 1 2 3
Second 2 3 4
Second d f t r
Second 2 3 4 5
Second 5 6 8 8

I inserted the (commented out) print statement and concluded that the
elements of @ARGV are being 'shift'ed, but I wasn't able to find this
behaviour documented the online docs (perlvar, perlop, perlsyn, perldoc
-q, probably others). I had no success with Google either.

I fixed the program by saving a copy of @ARGV and using that copy
instead. Nevertheless I would like help in finding the documentation for
the way @ARGV is handled in this way.

Regards,
Neil

p.s. Here are the contents of the test files I used:

a,b,c
1,2,3
2,3,4

and

d,f,t,r
2,3,4,5
5,6,8,8

Neil Montgomery <> wrote:

> I have solved my actual programming problem, but was frustrated in my
> attempt to determine the behaviour of @ARGV in the online docs.


@ARGV is an array of _data_.

Data does not _have_ behaviour, code does.

So it must be something else...


> I need to keep track of which file each datum came from.


> while (<>) {


Now we're getting somewhere.

There is an _op_erator that we know makes use of the data in @ARGV.


> and concluded that the
> elements of @ARGV are being 'shift'ed, but I wasn't able to find this
^^^^ ^^^^^
> behaviour documented the online docs (perlvar, perlop, perlsyn, perldoc
> -q, probably others).


It ought to be in perlop.pod somewhere, but it took me a while to
find it too. The FAQ calls it the "diamond operator" but perlop
calls it the "null filehandle".

But you had the search terms that led me to find it:

grep ARGV *.pod | grep shift


See the "I/O Operators" section:

The null filehandle <> is special
...
It really does shift the @ARGV array


--
Tad McClellan SGML consulting
Perl programming
Fort Worth, Texas

* Neil Montgomery wrote:
>
> I have solved my actual programming problem, but was frustrated in my
> attempt to determine the behaviour of @ARGV in the online docs.
>
> I want to combine data from two files. This combined data will be sorted
> and modified in various ways which aren't of any importance except that
> I need to keep track of which file each datum came from.
>
> I expected the following to do what I needed:
>
> #!/usr/bin/perl
> use warnings;
> use strict;
>
> my @data;
> while (<>) {
> chomp;
> # print "$ARGV, $ARGV[0]\n"; # For debugging
> my $file = ($ARGV eq $ARGV[0]) ? "First" : "Second";
> push @data, [ $file , split(/,/) ];
> }
>
> foreach (@data) { print "@$_\n" };
> __END__

I think this is a good example to use "eof" without its parenthesis.
Please study `perldoc -f eof` to learn more about eof's behavior.


#!/usr/bin/perl -w
use warnings;
use strict;

my @data;
my $filecnt = 1;

while ( <> ) {
chomp;
push @data, [ $filecnt, split /,/ ];
$filecnt++ if eof;
}

print "@$_\n" for @data;
__END__


regards,
fabian

Tad McClellan <> writes:
> Neil Montgomery <> wrote:
>
> > I have solved my actual programming problem, but was frustrated in my
> > attempt to determine the behaviour of @ARGV in the online docs.
>
>
> @ARGV is an array of _data_.
>
> Data does not _have_ behaviour, code does.

The data does not have behaviour, but the variable referring to it may
well have. I don't think there is anything wrong with the expression
"the behaviour of <predefined variable name>", generally. It may be
misleading or misinformed in particular cases, of course.

And code, after all, is just data interpreted by a processor.

Arndt Jonasson <do-not-> wrote:
>
> Tad McClellan <> writes:
>> Neil Montgomery <> wrote:
>>
>> > I have solved my actual programming problem, but was frustrated in my
>> > attempt to determine the behaviour of @ARGV in the online docs.
>>
>>
>> @ARGV is an array of _data_.
>>
>> Data does not _have_ behaviour, code does.
>
> The data does not have behaviour, but the variable referring to it may
> well have.


Do you have an example of that?

(There isn't such an example in this thread, as it is the null
filehandle (input operator) that has the behaviour of
using/changing the data stored in @ARGV.
)

> I don't think there is anything wrong with the expression
> "the behaviour of <predefined variable name>", generally.


We will have to agree to disagree on that then.


> It may be
> misleading or misinformed in particular cases, of course.


I would classify "misleading" as "anything wrong", which is
why I said what I said in the first place.

It misled the OP to looking at @ARGV instead of at <>.


--
Tad McClellan SGML consulting
Perl programming
Fort Worth, Texas

Tad McClellan <> writes:
> Arndt Jonasson <do-not-> wrote:
> >
> > Tad McClellan <> writes:
> >> Neil Montgomery <> wrote:
> >>
> >> > I have solved my actual programming problem, but was frustrated in my
> >> > attempt to determine the behaviour of @ARGV in the online docs.
> >>
> >>
> >> @ARGV is an array of _data_.
> >>
> >> Data does not _have_ behaviour, code does.
> >
> > The data does not have behaviour, but the variable referring to it may
> > well have.
>
>
> Do you have an example of that?
>
> (There isn't such an example in this thread, as it is the null
> filehandle (input operator) that has the behaviour of
> using/changing the data stored in @ARGV.
> )

In Perl, the %ENV variable, for example. Assigning into it causes more
things to happen than just storage of a value (maybe the process
environment is only updated just before a `` or a system(), but that
can't be determined from within Perl code). Also, when using the value
of $!, it returns a string or a number, depending on context, which
most scalar don't. I find it useful to say that the variable "behaves"
in a particular way.

> > I don't think there is anything wrong with the expression
> > "the behaviour of <predefined variable name>", generally.
>
>
> We will have to agree to disagree on that then.

Fine.

> > It may be
> > misleading or misinformed in particular cases, of course.
>
>
> I would classify "misleading" as "anything wrong", which is
> why I said what I said in the first place.
>
> It misled the OP to looking at @ARGV instead of at <>.

That's true, but I took your comment to be relevant for all variables.
(And in all languages, but maybe you didn't mean that. We often do
give advice in this news group about general programming practices.)

I do seem to find at least one use in the documentation. perlretut.pod
has:
"The result C<$^R> is automatically localized, so that it will behave
properly in the presence of backtracking."

Tad McClellan wrote:
> Arndt Jonasson <do-not-> wrote:

>>The data does not have behaviour, but the variable referring to it may
>>well have.
>
> Do you have an example of that?

I would say that

perl -le 'print "$_ ".$|-- for (0..9)'

exhibits a variable that has peculiar behavior.

-Joe