chomp() returns the number of characters removed, not the chomped values. So even if you were to sidestep your immediate problem by doing

my @row = split("\t", chomp(my $line = <IN>));
[download]

chomp() is a special beast. It modifies its arguments. You can't modify a file handle in the same way.

What you're after is something like,

chomp(my $line = <IN>);
my @row = split /\t/, $line;
print $row[0];
[download]

After Compline,
Zaxo

chomp($line1=<DATA>);
my @row = split("\t",$line1) ;
print $row[0];
__DATA__
hello    world
[download]

1), From perldoc: You can actually chomp anything that can be an lvalue. FileHandle cannot be an lvalue.
2), chomp returns the number of characters removed. For the other part, use substr($string,0,-1) type variation.

artist

sub Chomped($) {
    my( $line )= @_;
    chomp( $line );
    return $line;
}

my @row= split /\t/, Chomped(<IN>);
[download]

My best guess as to the reasoning is that chomp was designed to also work as chomp( @array ); and it was more efficient to do this 'in-place', rather than returning the list which would have required copying the whole array.

I'm not adverse to efficient constructs, but given that in almost every scenario that I can think of, whenever I chomp a scalar, I then need to pass that scalar onto something else, I wish that when chomp was called with a single scalar argument in a scalar context, it would edit the argument in-place and then return an alias to the argument that could be used as an rvalue.

Its probably too late to change it as I'm sure that there are some circumstances in which this would break existing code. Though, off the top of my head, I can't think of any, but someone will show me the shallowness of my thoughts:)

The second error is what you expected it to return. From (perldoc -f chomp), "It returns the total number of characters removed from all its arguments." So @row gets one element, which is '1'.

--
[ e d @ h a l l e y . c c ]

The first error is because it can't choose between chomp SCALAR or chomp ARRAY usage.

No, the first error is because he's "passing" something to chomp() that can't be modified in place.

Try

  chomp(" foo ");
[download]

It's clearly a SCALAR, yet it won't work.

$ perl -e 'chomp(" foo ");'
Can't modify constant item in chomp at - line 1, near "" foo ")"
[download]

$ perl -e 'chomp(<STDIN>);'
Can't modify <HANDLE> in chomp at - line 1, near "<STDIN>)"
[download]

Different error messages. In the first case, it complains about modifying a non-lvalue (a constant item). In the second case, it complains about modifying the results of reading from a file handle.

I'll grant you that chomp SCALAR can't chomp a non-lvalue, if you'll grant that the ambiguous context of the syntax chomp <FOO> is another valid reason that the compiler gives a separate distinct message.

--
[ e d @ h a l l e y . c c ]

#!/usr/bin/perl

use strict;
use warnings;

printf("\n >> START PROCESS ...\n");
open (ARQ, "< ./arq.txt"); 
while ($line = <ARQ>) {
      chomp($line);
      printf("[$line]\n");
}
printf("\n    ... END PROCESS <<\n");
[download]

    while (<>) {
    chomp;    # avoid \n on last field
    @array = split(/:/);
    # ...
    }
[download]

    chomp($cwd = `pwd`);
    chomp($answer = <STDIN>);
[download]