In addition to the critical problem diagnosed by state-o-dis-array, here are my candidates for things I would do differently:

sub get_sensor_id($) {
  ...
}
[download]

Don't use prototypes (the  ($) thingy in the above function definition). It didn't help you in the present case, and they probably don't do what you think they do, so why bother? Please see Prototypes in perlsub and Far More than Everything You've Ever Wanted to Know about Prototypes in Perl -- by Tom Christiansen.

sub add_iLO3_data() {
    $_ = "Memory    (a whole buncha stuff)       ";
    chomp;
    ...
}
[download]

chomp chomps a newline (in the default case) from the end of the  $_ default scalar if no other variable is specified to chomp, as in the code above. But you just finished assigning a string to $_. If you don't want a newline at the end of it, just don't put one there in the first place — as indeed you did not! No point in chomp-ing.

(Same code extract.) Don't use global variables, e.g.  $_ in the code above, unless you really know why you're using them. Use of global variables leads to "spooky action at a distance" problems such as the one pointed out by state-o-dis-array. Better (lexical variable, no chomp, no prototype):

sub add_iLO3_data {
    my $str = "Memory    (a whole buncha stuff)       ";
    ...
}
[download]

I read the article you suggested and I removed the prototypes, thank you very much for linking that article!

The second issue is minor, since I modified the script just enough to show you the useful part. Actually I was using readpipe, so I had the newline at end and no manual assignment of $_

sub get_sensor_id($) {
    my ($sensor) = @_;
    print "sensor input: $sensor\n";
    return 0;
}
[download]

$value =~ s/^\s+|\s+$//g;
[download]

I thought that @_ meant the list passed to the sub, so I used $_ when I passed a single element. My bad, I should have read perlsub better (or simply reread it).

I used your new regexp together with the suggestions below.

I thought that @_ meant the list passed to the sub, so I used $_ when I passed a single element.

@_ contains the list of arguments for a sub, but you want the first argument of that array, which is $_[0]. $_ is something completely different, as you already know.

There are two common idioms for accessing arguments:

sub foo
{
    my $onlyarg=shift; # @_ is the default argument for shift
    # more code
}
[download]

and

sub bar
{
    my ($huey,$dewey,$louie)=@_;
    # more code
}
[download]

Of course, you can also write

sub baz
{
    my $onlyarg=$_[0];
    # more code
}
[download]

or

sub moo
{
    my $huey=shift;
    my $dewey=shift;
    my $louie=shift;
    # more code
}
[download]

or even

sub ohnononononopleaseno
{
    my $huey=$_[0];
    my $dewey=$_[1];
    my $louie=$_[2];
    # more code
}
[download]

But that is uncommon and has some strange accent. Stick with the first two variants. Having only one argument needs no exception, you can use the list assignment even for a single argument, no need for shift:

sub foo2
{
    my ($onlyarg)=@_;
    # more code
}
[download]

Just remember the parentheses, or else $onlyarg will contain the number of arguments, in this case 1. Not what you want.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

    my @fields = split(/\|/);
    my $name = $fields[0];
    $name =~ s/\s*//;
    $name =~ s/\s*$//;
    my $value = $fields[1];
    $value =~ s/\s*//;
    $value =~ s/\s*$//;
    my $status = $fields[3];
    $status =~ s/\s*//;
    $status =~ s/\s*$//;
[download]

That should be:

    my ( $name, $value, undef, $status ) = split /\|/;
    s/^\s+//, s/\s+$// for $name, $value, $status;
[download]

I implemented your suggestion too, thanks!