Now, if you want to actually explain why you think it makes sense to combine CGI.pm with interactive input...

I apologise once again, I was trying to keep it simple, reducing the problem to the simplest case...

As it is, I see more explanation is in order. I have a perl script using sqlite that works very well. Very much simplified, it looks like this:

use strict;
use warnings;

use DBI;

my @fields = ( qw/ Genus Species Cultivar Common_Name / );
my $field = get_field( @fields );
my $value = get_value( $field );

# Omitted: code to connect to DB
my $select_query = qq/ select * from plant where $field = '$value' /;
# Omitted: code to execute, fetch and deallocate SQL query

sub get_field {
  # Highly simplified for testing purposes
  return $_[3]; 
}

sub get_value {
  print $_[0], ': ';
  chomp ( my $choice = <STDIN> ); # <- Problem here!
  return $choice;
}
[download]

...by telling us more about what you are trying to do...

I am converting this program to a CGI script. I decided to do the HTML output bit first. Of course, once I have finished, I will not be combining CGI.pm with interactive input once the development phase is finished. However, I was surprised that adding use CGI; to my code added a subtle bug that it took me a very long time to track down.

...then we could probably tell you the proper way to prevent this problem

It's all right, thanks: as I say, I've now tracked down the bug (which thanks to your explanation I accept is in my code, not in CGI.pm :) and found a workaround.

So, you wanted to keep reading from STDIN for sake of easy checking with different inputs. In that case, it is smart to use the debugging capabilities of CGI.pm.

use CGI qw(:debug);
chomp (my $choice = param('choice'));
[download]

---

Wiki | CPAN Testers wiki