1. read_lines bug
- Posted by jmduro Mar 01, 2019
- 1387 views
On Linux, using read_lines on standard input with EU4.1 leads to display exceeding empty lines on standard output.
Let's consider this example:
include std/io.e procedure main(sequence cmd) sequence source = read_lines(0) -- read standard input end procedure main(command_line())
labo@silverstone1:~/Data/euphoria/v4$ /sbin/ifconfig eth0 | eui test_read_lines.ex labo@silverstone1:~/Data/euphoria/v4$
If read_lines is commented out in procedure main, then there is no additional empty line on standard output:
labo@silverstone1:~/Data/euphoria/v4$ /sbin/ifconfig eth0 | eui test_read_lines.ex labo@silverstone1:~/Data/euphoria/v4$
Jean-Marc
2. Re: read_lines bug
- Posted by irv Mar 01, 2019
- 1313 views
Well, that's caused by the following lines in io.e. around line 1151:
if fn = 0 then puts(2, '\n') end if
(writing to std_err if reading stdin)
The lines are easy enough to remove, but why are they there in the first place? Will removing them cause any other problems?
3. Re: read_lines bug
- Posted by ghaberek (admin) Mar 01, 2019
- 1317 views
Link to source for the curious: https://github.com/OpenEuphoria/euphoria/blob/master/include/std/io.e#L1125
The lines are easy enough to remove, but why are they there in the first place?
If I had to guess, maybe they were part of testing and left in by mistake. It'd make sense to want to see some indicate of the lines being read.
Will removing them cause any other problems?
In my testing with the example provided above, no. But who knows what fringe case there might have been for those few lines to exist.
-Greg
4. Re: read_lines bug
- Posted by euphoric (admin) Mar 01, 2019
- 1342 views
Link to source for the curious: https://github.com/OpenEuphoria/euphoria/blob/master/include/std/io.e#L1125
The lines are easy enough to remove, but why are they there in the first place?
Will removing them cause any other problems?
In my testing with the example provided above, no. But who knows what fringe case there might have been for those few lines to exist.
It generates unexpected and undesired behavior, it seems, so it should probably be taken out, so long as all tests still perform successfully with it removed.
5. Re: read_lines bug
- Posted by petelomax Mar 03, 2019
- 1227 views
Link to source for the curious: https://github.com/OpenEuphoria/euphoria/blob/master/include/std/io.e#L1125
The lines are easy enough to remove, but why are they there in the first place?
If I had to guess, maybe they were part of testing and left in by mistake. It'd make sense to want to see some indicate of the lines being read.
Will removing them cause any other problems?
In my testing with the example provided above, no. But who knows what fringe case there might have been for those few lines to exist.
-Greg
I'm wondering if they improve manual console input. If you take that line out and then enter one, two, three, does the screen end up looking like "onetwothree"?
It could of course behave quite differently on linux and windows. (I've messed up my install a bit so I can't test this particular one on eui.)
6. Re: read_lines bug
- Posted by irv Mar 03, 2019
- 1181 views
I'm wondering if they improve manual console input. If you take that line out and then enter one, two, three, does the screen end up looking like "onetwothree"?
It could of course behave quite differently on linux and windows. (I've messed up my install a bit so I can't test this particular one on eui.)
Taking them out seems to cause no problem on Linux.
7. Re: read_lines bug
- Posted by petelomax Mar 04, 2019
- 1159 views
I'm wondering if they improve manual console input. If you take that line out and then enter one, two, three, does the screen end up looking like "onetwothree"?
It could of course behave quite differently on linux and windows. (I've messed up my install a bit so I can't test this particular one on eui.)
Taking them out seems to cause no problem on Linux.
I got it to run by copying the routine in locally rather than using include std/io.e
It was a problem on windows in eui 4.0.0, but seems fine on 4.1.0 - which explains why that code was there.
EDIT: note that as phix slavishly copied the earlier rds eu behaviour, it remains a potential issue.
(Specifically gets0 in pfileioN.e tests for \r (and Ctrl Z) after each kernel32/ReadFile|syscall sys_read before echoing it with kernel32/WriteConsoleA|syscall sys_write)
