newbie: Terminating while($line=<stdin>) on Windows

[Madhur]

Hello
while($line==<stdin>)
{

}
How would this be terminated. It is terminated by ^D on Unix system I
think.
But on windows It doesnt work.

--
Winners dont do different things, they do things differently.

Madhur Ahuja
India
email : madhur<underscore>ahuja<at>yahoo<dot>com

 

[Tintin]

Hello
while($line==<stdin>)
{

}
How would this be terminated. It is terminated by ^D on Unix system I
think.
But on windows It doesnt work.

Unix is not Windows, Windows is not Unix, and neither Windows nor Unix are
Perl.

^Z

 

[Matt Garrish]

Hello
while($line==<stdin>)
{

}
How would this be terminated. It is terminated by ^D on Unix system I
think.
But on windows It doesnt work.

Ctrl+C, Ctrl+Break, that little x in the corner of your dos window, via the
task manager, tmtowtdi...

Did you have a Perl question, though?

Matt

 

[Tad McClellan]

while($line==<stdin>)

^^
^^
^^ this isn't even your real code, is it?


while ( $line = <STDIN> )


Or you will have problems if you ever put that code into a package,
as the warning in perlop.pod states.

Space characters are not a scarce resource. Feel free to use as
many of them as you like to make your code easier to read
and understand.

How would this be terminated.

The sentence above should be terminated with a question mark.

It is terminated by ^D on Unix system I
think.
But on windows It doesnt work.

^Z

 

[John Deuf]

Hello
while($line==<stdin>)
{

}
How would this be terminated. It is terminated by ^D on Unix system I
think.
But on windows It doesnt work.

Hi,

maybe the line should be read as

while($line eq <stdin>)

But it is certainly not what you want.
If the initial line was

while($line = <stdin>)

you expect maybe that the while stops when STDIN becomes false.

With a PC you may have to face the ^M ending char, the irritating
carriage-return char added to line-feed. I.e. on PC, 2 chars to end
the line.

To cope with that problem, I propose this, but I'm sure there are
better algorithms, using $_ for instance

while (<STDIN>) # get line in $_
{
chomp; # removes the unix LF char
s/\015//; # removes the PC CR char
$line = $_; # if you really want the $line var...

.... your process ....
}

Regards

JD

 

[Martien Verbruggen]

Hi,

maybe the line should be read as

while($line eq <stdin>)

But it is certainly not what you want.
If the initial line was

while($line = <stdin>)

you expect maybe that the while stops when STDIN becomes false.

Not really. Thw loop would exit when <stdin> becomes undefined (not
false, but specifically undefined, see perlop documentation), and that
happens when there are no more lines to be read from the handle stdin
(not STDIN, Perl is case sensitive), i.e. when end-of-file is reached.

With a PC you may have to face the ^M ending char, the irritating
carriage-return char added to line-feed. I.e. on PC, 2 chars to end
the line.

Huh?

If you're on an operating system where in a file the end of line is
represented by more than one character, then inside of Perl, the end of
line is still a simple "\n". End of line is always "\n", irrespective of
what the representation in the external file is.

If you transport such files between platforms, and don't correctly
convert the end-of-line sequences, then you could end up reading
spurious characters, but that simply means that you're not reading a
regular text file for the platform you're on.

I am, of course, assuming that you're reading this file in text mode,
since end-of-line makes no sense in any other context.

To cope with that problem, I propose this, but I'm sure there are
better algorithms, using $_ for instance

while (<STDIN>) # get line in $_ { chomp; #
removes the unix LF char s/\015//; # removes the PC CR

If, on windows, you would actually see a \015 there, then that would
mean that the external file had a \015 before its normal end-of-line,
and there would have been a byte sequence of \015\015\012 in the file.
That's not really a text file, and indicates a problem with the file,
rather than with the program or programmer. Or it indicates that the
originator of the file wanted to have that extra \015 in there, for
whatever sick reason.

BTW, the end-of-line character (yes, a single one only) on Unix is \012,
not \015. Macs use a single \015, and windows uses \015\012. Also see
the perlport documentation for more information.

If oyu want to remove newlines, use chomp(). If you need to read broken
files, write specific routines to deal with that, but please, don't
advocate the use of this sort of code for regular text files. it is not
necessary, and in fact, broken.

You should not have to worry about what your machine uses as the
end-of-line indicator. In Perl it will be \n, and chomp will remove it.

char $line = $_; # if you really want the $line var...

And if you really want the "$line var", then you should simply use it,
and not $_:

while (my $line = <STDIN>)
{
chomp $line; # to remove the newline
# blahblah
}

Why use $_ at all? And why not scope the variable appropriately?

Martien

 

[John Deuf]

Not really. Thw loop would exit when <stdin> becomes undefined (not
false, but specifically undefined, see perlop documentation), and that
happens when there are no more lines to be read from the handle stdin
(not STDIN, Perl is case sensitive), i.e. when end-of-file is reached.


Huh?

If you're on an operating system where in a file the end of line is
represented by more than one character, then inside of Perl, the end of
line is still a simple "\n". End of line is always "\n", irrespective of
what the representation in the external file is.

If you transport such files between platforms, and don't correctly
convert the end-of-line sequences, then you could end up reading
spurious characters, but that simply means that you're not reading a
regular text file for the platform you're on.

I am, of course, assuming that you're reading this file in text mode,
since end-of-line makes no sense in any other context.


If, on windows, you would actually see a \015 there, then that would
mean that the external file had a \015 before its normal end-of-line,
and there would have been a byte sequence of \015\015\012 in the file.
That's not really a text file, and indicates a problem with the file,
rather than with the program or programmer. Or it indicates that the
originator of the file wanted to have that extra \015 in there, for
whatever sick reason.

BTW, the end-of-line character (yes, a single one only) on Unix is \012,
not \015. Macs use a single \015, and windows uses \015\012. Also see
the perlport documentation for more information.

If oyu want to remove newlines, use chomp(). If you need to read broken
files, write specific routines to deal with that, but please, don't
advocate the use of this sort of code for regular text files. it is not
necessary, and in fact, broken.

You should not have to worry about what your machine uses as the
end-of-line indicator. In Perl it will be \n, and chomp will remove it.


And if you really want the "$line var", then you should simply use it,
and not $_:

while (my $line = <STDIN>)
{
chomp $line; # to remove the newline
# blahblah
}

Why use $_ at all? And why not scope the variable appropriately?

Martien

Hi Martien

Thank you to answer my answer.

Did you at least read the initial question from the initial message
And tried to interpret it and answer it... Seemingly the initial user
is not a pro at Perl and needed to get a solution ready to use.

- <STDIN> being empty or false : actually it is finally evaluated to
false
Does playing with words really help the newbie

- Regarding the 2 chars on a PC coming from Unix - ok you program Perl
since the early nineties ... - but you should know my friend that on
some implementations and depending on the way it has been installed
the "chomp" removes only the \012 (LF) not the \015 (CR) ...

- STDIN : this is funny I'm sure you are not answering threads to
show off, since your time is so valuable, but my friend, as you say,
"read the doc" ) All the global special filehandles are given in
uppercase (Perl in a nutshell for instance p.55). You're lucky,
"stdin" works in lowercase. But try with ARGV !!

- Regarding $_, yes, you got the point, and, for once, you answered
the user. Good. However I think it is better to forget the C
programming and tend to use $_ instead of other variables (needing
allocation etc...). Moreover it is so convenient to use this default
variable...
while (<STDIN>)
{
chomp;
s/\015//; # in case your implementation needs it and (for our
friend)if
# you don't want to spend ages to find out where the PC
specific
# config is missing
...
}

Cheers

 

[Martien Verbruggen]

Hi Martien

Thank you to answer my answer.

Did you at least read the initial question from the initial message
And tried to interpret it and answer it... Seemingly the initial user
is not a pro at Perl and needed to get a solution ready to use.

And? Your point is?

- <STDIN> being empty or false : actually it is finally evaluated to
false
Does playing with words really help the newbie

Accuracy does help. Programmers have to be accurate, because computers
are generally not very forgiving towards inaccurate programs.

- Regarding the 2 chars on a PC coming from Unix - ok you program Perl
since the early nineties ... - but you should know my friend that on
some implementations and depending on the way it has been installed
the "chomp" removes only the \012 (LF) not the \015 (CR) ...

And on those platforms, end-of-line is \012 or \015. Perl's chomp
removes whatever $/ is set to, and that, by default, is set to whatever
the end-of-line on the current platform is.

If you want to remove more than the end-of-line characters, then do so.
However, when you are working with _regular_ text files, you should
never ever worry about end-of-line sequences that might come from other
plartforms. never.

You just finished telling me that you thought the OP was "not a pro at
Perl", yet you decide that it would be a good idea to worry the OP with
this sort of stuff? And apart from that, you didn't just give him
inaccurate information in this resect, but wrong information. i
corrected that. This is Usenet, get used to it.

- STDIN : this is funny I'm sure you are not answering threads to
show off, since your time is so valuable, but my friend, as you say,
"read the doc" ) All the global special filehandles are given in
uppercase (Perl in a nutshell for instance p.55). You're lucky,
"stdin" works in lowercase. But try with ARGV !!

Te OP used stdin, you started using STDIN. It is by (mis)design that
both work in Perl, but not always. stdin is only synonmous for STDIN in
main::. You switched from one to the other without explaining why you
did that.

The OP should have used STDIN, probably. You didn't explain why.

I do not, and have never advocated the use of stdin above STDIN when
people mean to use the standard input stream. What I remarked was that
the OP used stdin, and you switched to STDIN, which is _not_ the same
thing, in general.

You just finished telling me that you thought the OP was "not a pro at
Perl", yet you decide that it would be a good idea to worry the OP with
the case-insensitivity of STDIN, STDOUT and STDERR, without explaining
that this only is the case in certain circumstances. You should have
sticked with stdin, if you are genuinely worried about the OP not being
"a pro at Perl", or you should have explained why it is better to use
STDIN.

- Regarding $_, yes, you got the point, and, for once, you answered
the user. Good. However I think it is better to forget the C
programming and tend to use $_ instead of other variables (needing
allocation etc...). Moreover it is so convenient to use this default
variable...

That is such nonsense that I don't even know where to start. You are
obviously an idiot. The use of named variables has absolutely nothing
whatsoever to do with C, and everything with good programming practices.

while (<STDIN>)
{
chomp;
s/\015//; # in case your implementation needs it and (for our
friend)if
# you don't want to spend ages to find out where the PC
specific
# config is missing

In my implementation, this garbage would never appear.

Also, you foget that I responded directly to some piece of code you
submitted:

while (<STDIN>) # get line in $_
{
chomp; # removes the unix LF char
s/\015//; # removes the PC CR char
$line = $_; # if you really want the $line var...

.... your process ....
}


I responded specifically to the line "$line = $_;", with the remark that
if you are going to use a named variable, that you should do so at the
start, instead of switching from one to the other in the middle. If you
want to use $_, fine, use it, but if you don't then don't. Don't be
wishy-washy about it, and do both, a little bit.

And you're right, my time is valuable. Too valuable to deal with
trolling idiots like you.

*plonk*

Martien

 

[Tad McClellan]

Seemingly the initial user
is not a pro at Perl

And neither are you.

Martien is.

Does playing with words really help the newbie

Does using technically precise terminology help when discussing
technical topics?

but you should know my friend

but my friend, as you say,
"read the doc"

- Regarding $_, yes, you got the point, and, for once, you answered
the user.

You correcting Martien is a ludicrous endeavor.

So long fool.