Follow-up Comment #7, sr #110403 (project autoconf): OK, I've verified that this is a bug in OmniOS /bin/sh.
OmniOS /bin/sh reads scripts in 8192-byte chunks. If the last line of a here-document straddles a chunk boundary, and the last character of that line is not a backslash, but the last character of the first chunk _is_ a backslash, and the first character of the second chunk is a dollar sign, then the here-document will be written out without a final newline. (I'm not sure whether the boundary has to fall within the last line of the here-document, or whether the first character of the second chunk has to be a dollar sign. I know \# doesn't work, though.) The attached file t-001fa2.sh.gz is a self-contained reproducer for the bug. If you uncompress it and run it with a shell that has this bug, it will print something like this: cmp: EOF on /tmp/tmp.LCyimJxG8v after byte 1, in line 1 + xxd /tmp/tmp.q5iPccsLOn 00000000: 240a $. + xxd /tmp/tmp.LCyimJxG8v 00000000: 24 $ + exit 1 + rm -f /tmp/tmp.q5iPccsLOn /tmp/tmp.LCyimJxG8v (Note that the script does not have a `#!` line. Also, you need to have `xxd` for it to work as intended, but both invocations of this utility are after the critical part of the code, so you can safely change them to any other hex-dump program you may happen to have around without breaking the test. I have also attached the program I used to generate the test script, which may be easier to tinker with.) (The name t-001fa2 refers to the number of padding characters in the script, before the actual code.) > I wonder why autoconf-2.69b does not exhibit the issue I believe this was pure luck. In your testing, autoconf-2.69b happened not to generate a script that had \$, inside a here document, at exactly the right offset. I don't see any reason why this couldn't have happened with _any_ version of Autoconf. It's also possible that the bug was recently introduced -- did you patch IP65-66-246-71.simplesystems.org recently? I wasn't able to reproduce the bug with any of /bin/sh, /bin/ksh, or /usr/xpg4/bin/sh on heritage Sun Solaris 10 or 11. ---- Now we know what's wrong, the question is what to do about it. Of course OmniOS should be notified. I looked at https://omniosce.org/ a bit and was not able to figure out how to report the bug. (It says that development happens on Github, and I found a link to what _seems_ to be the repo where development happens, namely https://github.com/omniosorg/illumos-omnios -- but that repo has no open issues at all, so I'm guessing that is _not_ the place to file bug reports.) It is not feasible to make Autoconf avoid ever writing out backslashes inside here-documents. Generation of config.status, in particular, involves using here-documents to emit shell code, in which backslashes are often necessary. What we _could_ do is add a test for this sh bug to _AS_DETECT_BETTER_SHELL. It would be a little fiddly but not difficult. I hesitate, though, because of how sensitive this test would be to unrelated modifications to the shell -- for instance, if someone happens to decide tomorrow that OmniOS sh should read files in 16kB chunks instead of 8kB chunks, a test that only probed the 8kB boundary would be invalidated. How many different offsets do we need to try before we have confidence that the bug is not present? cc:ing several other autoconf maintainers for their thoughts. (file #50563, file #50564) _______________________________________________________ Additional Item Attachment: File name: t-001fa2.sh.gz Size:0 KB <https://file.savannah.gnu.org/file/t-001fa2.sh.gz?file_id=50563> File name: test-gen.py Size:1 KB <https://file.savannah.gnu.org/file/test-gen.py?file_id=50564> _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/support/?110403> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/
