Update of bug #59442 (group groff):

                  Status:                    None => Need Info              
                 Summary: [PATCH] groff.cpp: move soelim before preconv in
constructed pipeline => [PATCH] [groff] move soelim before preconv in
constructed pipeline

    _______________________________________________________

Follow-up Comment #12:

I've remained stuck on this because of the questions Dave raises in comment
#11 and the _groff_ simulator in my brain not being as good as
experimentation.

So I did an experiment.

To my surprise, the following worked.


$ locale charmap
UTF-8
$ cat EXPERIMENTS/entrée.troff 
the croque monsieur
$ cat EXPERIMENTS/so-a-fancy-filename.troff
.sp
We'll begin the meal with
.so entrée.troff
then continue with the paella
and wash it down with a stein of mead.
$ groff -I EXPERIMENTS -a EXPERIMENTS/so-a-fancy-filename.troff
<beginning of page>
We'll begin the meal with the croque monsieur then continue with the paella
and wash it down with a stein of mead.


Impressive, but fragile.  (Be aware that `-I` forces _soelim_ to run.)

The only reason this works is because the encoding of the text file
"so-a-fancy-filename.troff" is the same as the encoding used by the file
system to store the file name "entrée.troff".

There will be situations where that is not true.  And if we run _preconv_ on
such a file, it seems *more* likely to become *less* true, simply because it
multiplies the possibilities for character encoding conversion.

Things fall apart with a rather more modest file name character--the space. 
If I rename "entrée.troff" to "the entrée.troff" and update the `so` request
in "so-a-fancy-filename.troff" accordingly, here's what happens.


$ groff -I EXPERIMENTS -a EXPERIMENTS/so-a-fancy-filename.troff
soelim:./EXPERIMENTS/so-a-fancy-filename.troff:3: error: can't open 'the': No
such file or directory
<beginning of page>
troff:./EXPERIMENTS/so-a-fancy-filename.troff:3: error: can't open 'the': No
such file or directory
We'll begin the meal with then continue with the paella and wash it down with
a stein of mead.


Let's take _soelim_ out of the equation and see what happens.


$ cat EXPERIMENTS/so-a-fancy-filename.troff
.sp
We'll begin the meal with
.so EXPERIMENTS/the entrée.troff
then continue with the paella
and wash it down with a stein of mead.
$ groff -a EXPERIMENTS/so-a-fancy-filename.troff
<beginning of page>
troff:EXPERIMENTS/so-a-fancy-filename.troff:3: error: can't open
'EXPERIMENTS/the': No such file or directory
We'll begin the meal with then continue with the paella and wash it down with
a stein of mead.


So leaving aside fancy non-basic Latin characters, we're already sunk, and
have been for decades, by the simple obstacle of a space character.

Worse, this limitation was completely unnecessary: no _troff_ request that
takes a file name as a request argument locates it anywhere but as the _last_
argument, which means GNU _troff_ could have read file name arguments more in
the fashion that it did string definitions and appendments, by reading until
the newline.

(I don't propose to support newlines embedded in file names, and would oppose
doing so, [https://austingroupbugs.net/view.php?id=243 even if POSIX 2024,
finally, *finally* made it easier to cope with these.]  Solaris 10 will remain
lobotomized in a forgotten corner of the asylum^Wdata center, drooling
pitiably.


$ find . -print0
find: bad option -print0
find: [-H | -L] path-list predicate-list
bash-3.2$ xargs -0
xargs: illegal option -- 0
xargs: Usage: xargs: [-t] [-p] [-e[eofstr]] [-E eofstr] [-I replstr]
[-i[replstr]] [-L #] [-l[#]] [-n # [-x]] [-s size] [cmd [args ...]]
bash-3.2$ read -d
bash: read: -d: option requires an argument
read: usage: read [-ers] [-u fd] [-t timeout] [-p prompt] [-a array] [-n
nchars] [-d delim] [name ...]


)


I am consequently inclined to either reject this ticket or postpone it (again)
until after _groff_ 1.24.0.

Feedback?


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?59442>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/

Attachment: signature.asc
Description: PGP signature

Reply via email to