Kaz Kylheku wrote in <c3cd8637b859736730129d6f0b369...@kylheku.com>: |On 2024-04-26 12:54, Steffen Nurpmeso wrote: |> I come over via https://github.com/onetrueawk/awk/issues/228. |> For years the nawk build causes terminal mess in the unshare(1)d |> fakeroot(1) package build environment of the Linux distro i use |> (CRUX; sh(1) based). It looks like that: | |Downstream users should not have to run Yacc at all. It is best to capture
Well *that* you tell the wrong person, i myself have never used automatic code generators at all. (I am too stupid for yacc, really.) |the source code produced by the parser generator and ship that with the |rest of the sources. Only run the generator when the grammar changes. |At that point you can use the same version of the generator tool to ensure |minimal diffs in the output file. | |If you let downstream users run Yacc, you don't know what C code you're |getting. One user might run ancient Bison 2.5. Another might run |the latest version. A third one might use Berkeley Yacc or what have you. | |It's a kind of important part of the program to leave to chance. It seems to me it is pretty common to do it that way, though, including standardized built-in rules for make(1) and all that. |https://www.gnu.org/software/bison/manual/html_node/Versioning.html ... |> Note that if i do ls(1) --color=yes in the same environment, |> colors are ok. (However, vim(1) only starts up as rvim.) |> |> It is like that for years, i can reproduce it a hundred percent |> (also see the nawk issue). Todd Miller said in the issue that |> bison uses some GNU specific library for these terminal sequences, ... --End of <c3cd8637b859736730129d6f0b369...@kylheku.com> --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
