> pic 1.21 is inconsistent about detecting carriage-return
> characters. [...]
Thanks for the report. I've `fixed' (more or less) by adding one more
check for invalid characters. Your input file `pstest'
.PS
define f { $1 }
.PE
.PS 2i
a = f(0)
.PE
with CRLF line terminations, processed with
pic pstest > /dev/null
now shows
pic:pstest:1: invalid input character code 13
pic:pstest:2: invalid input character code 13
pic:pstest:3: invalid input character code 13
pic:pstest:4: nested .PS
pic:pstest:5: invalid input character code 13
pic:pstest:6: invalid input character code 13
> Things get really mysterious if the first .PS...PE is in a separate
> file, with CRLF terminations, that is included via .PS <source in a
> second file with LF terminations. Then the only diagnostic is
> "there is no variable 'f'". (In fact this scenario is what brought
> the problem to my attention.)
Assuming the file names `pstest.dos' and `pstest.unix' for your test,
pic now reports this on stderr:
pic:pstest.dos:1: invalid input character code 13
pic:pstest.dos:2: invalid input character code 13
pic:pstest.dos:3: invalid input character code 13
pic:pstest.dos:4: end of file before .PE or .PF
pic:pstest.dos:1: .PS was here
Werner
_______________________________________________
bug-groff mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-groff
