Update: After reading the documentation, I can confirm the behaviour. You can use the autochomp option to turn this behaviour off.

Thanks a lot! It has worked.

Your immediate problem is that you read lines from a file with <IN> into the default variable and "write" them immediately into the tied object. However the tied object is essentially an array of lines. Because you haven't stripped the line end character from the input line you end up with two line ends on output.

However, there is a pile of other stuff that needs attention in your sample code. Consider this reworked version:

use strict;
use warnings;
use Tie::File;

my @records;

tie @records, 'Tie::File', "pile_out.txt";

my $in_file = "fake_vals.fem";
my $outIndex = 10; 

open my $in, '<', "$in_file" or die "cannot open '$in_file' for readin
+g: $!\n";

while (my $line = <$in>) {
    next if $line !~ /\bNODE\b/i;
    chomp $line;
    $records[$outIndex] = $line;
    ++$outIndex;
}
[download]

First off, always use strictures (use strict; use warnings; - see The strictures, according to Seuss).

Always use lexical file handles. In combination with strictures that will save some very embarrassing file messes.

Always use three parameter open. Usually at this point we suggest or die, but you are doing that already - great! However show the actual file path you were trying to open and the failure message. That will save a couple of iterations of debugging.

Avoid using the default variable. Using a manifest named variable helps with code readability and helps maintenance. It also avoids subtle problems with the default variable changing content when you don't expect it to.

A more contentions, but only marginally important suggestion is to use the pre increment operator unless logic demands the post increment operator. As a general rule stuff toward the end of a line gets lost and increment is important so do it up front.

First off, always use strictures

If they should always be used...why are they not on by default?

If they should always be used...why are they not on by default?

For backwards compatibility. Making strictures on by default for newer versions of Perl would break most old or poorly written Perl code. If you use 5.012; strictures are on by default.

Optimising for fewest key strokes only makes sense transmitting to Pluto or beyond

Perl 7 (not sure of the equivalent 5.x version but I think it is 5.32.0) is starting off with strict and warnings 'on' by default. They are not on by default in 5.x because it would break a lot of existing code.

For future reference, a FAQ list of PM nodes related to using strict and warnings (highest rep first):

• On Commenting Out 'use strict;' by Old_Gray_Bear (2004) - code review meeting where strict/warnings had been commented out because they "caused too many errors"!

• The strictures, according to Seuss (2008) - brilliant funny poem by toolic, a parody of Dr. Seuss' Green Eggs and Ham

• 'use strict' is not Perl by Ovid (2001) - Good coding is not language specific: use strict is good coding in Perl (and the principles behind it apply to other languages)
• Use strict warnings and diagnostics or die by tachyon (2001) ... plus an abbreviated version
• Use strict and warnings by runrig (2001)
• 101 reasons to use strict; by George_Sherston (2001)
• The power of strict typo-checking by tall_man (2004)
• RFC: Tutorial: use strict; now what!? by Xiong (2012)
• Why We Use Strict! by Ovid (2000)

• Can you use string as a HASH ref while "strict refs" in use? by choroba (2013)
• Perl archeology: Need help in refactoring of old Perl code that does not use strict by likbez (2017)

• Re: Why use warnings? -w by davido (2018) - part 1
• Re: Why use warnings? -w by davido (2018) - part 2

Some more recent ones:

• Newline's creep in, while using Tie::File by always_coys (2020) - with use strict provocation ("is it a universal belief that strictures should be on or a majority belief?") kindly provided by Bod
• Backdating strict by Bod (2020) - should strict always be used or are there circumstances when it makes sense not to use this pragma?

• Re^2: How to import "global" variables into sub-scripts from main script? by Polyglot (2021) - anti-strict rant
• Re^3: How to import "global" variables into sub-scripts from main script? by haukex (2021) - ... with excellent reply from haukex
• Re^2: "Experimental push on scalar is now forbidden" by building_arch (2021) - "I am perfectly willing to pay the price of nostrictness nowarningness", with excellent reply from Marshall

• Re^3: Referencing the locals by Chuma (2021) - sees using strict as "personal preference", haukex argues that it is a best practice
• Long list is long by Chuma (2022) - still not using strict ... will excellent advice from kcott be followed? ... (later reply trying to stir things up a bit :)

• Re^4: pattern matching once by justin423 (Aug 2023) - passive-aggressive response to use strict and warnings
• Re^5: pattern matching once (passive-aggressive) - my response

Some historic anti-strict rants:

• Re^2: Code Review Time! by linuxkid (2012) - A shocking rant "I've been working with perl for about 3 years, and using warnings and strict breaks everything" (the historic "bk" anti-strict rant that inspired Acme::USIG is also shown in a reply :)

Outside refs:

• Always use strict and warnings (perlmaven)
• Modern::Perl

Note: felt obliged to provide this FAQ list so as not to disappoint LanX. :)

You can also check my Can you use string as a HASH ref while "strict refs" in use? for a hard to debug behaviour you can get without strict 'refs' (and how to get the same confusing behaviour with strict, too).
map{substr$_->[0],$_->[1]||0,1}[\*||{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^*ARGV,3]