So what you're saying is:

1. Program A outputs data with "\n" at the end.
2. Program B chonks the data.
3. Program A fails in some way, and outputs a line without a terminating "\n"
4. Program B dies and reports the problem?

This will appear in test as.. what? a failure in Program A or Program B?

If Program A outputing "\n" at the end of the line is such a cruicial matter, shouldn't you be testing Program A's output explicitly for "\n" (or whatever your seperator is) instead of condeming the use of chomp everywhere?

And by using chop, how do you catch this in testing? like so?

$data = get_input_from_program_a();
$chopped = chop($data);
if ($chopped ne $/) {
   die "Program A is acting up";
}
[download]

I'm just not up to the level to think that deeply into your problem, maybe you can help me understand?

It is trivial to create a file in vi with no trailing newline. That's a program in a unix environment.

You are projecting your sense of "what is normal" onto everyone else's situation. It doesn't work that way. So far, in this discussion, I don't recall anyone else having to treat a text file without a trailing newline as "broken". If *your* particular functional requirements *demand* that files always end with a newline, then you have to take the necessary steps to validate your files. It does not then follow that the normal use of chomp() on line-oriented text input is somehow defective on its face.

"Normal" for most of us is that we just don't need to care about that trailing newline. You seem to have a real blind spot about that. Telling us that we are somehow "unprofessional" if we just use chomp() is absurd. Telling us that we would be better off to use "chomp or die" is equally absurd. You are trying to create a cargo-cultish practice, and we aren't going for it.