I've added bug-autoconf for this part of the discussion. On Thu, 23 Jul 2009, Eric Blake wrote:
> Joel E. Denny <jdenny <at> clemson.edu> writes: > > In the new test group, I wish I could check the case where a character > > literal ends at eof without a newline. However, the documentation for > > AT_DATA demands that the file contents end with an "end of line", so I'm > > not sure what to do. I might write the Autoconf people later if no one > > around here already knows how to work around this limitation. > > That's an inherent limitation of AT_DATA (since it is implemented using a > shell > here-doc); the only way around it is to manually use printf or $ECHO_N to > concatenate data to the end of the desired file. Thanks. In the Autoconf manual's section on portability, the entry for echo implies that printf is not as portable as AS_ECHO* constructs: New applications which are not aiming at portability should use `printf' instead of `echo'. M4sh provides the `AS_ECHO' and `AS_ECHO_N' macros, which choose between `echo -n' on implementations where that works, `printf' if it is available, or other creative tricks in order to work around the above problems. Shouldn't the entry for printf mention this portability shortcoming of printf as well? Also, I find the first sentence above confusing. Why is printf recommended if not for portability? > I've been meaning to add a new macro to autotest to allow more flexibility in > generating files (no trailing newline, and/or allowing shell expansions) but > it > will not be in time for autoconf 2.64. Feel free to ping the autoconf list, > so > that I'll have a reminder email. Is it necessary to have a new macro for omitting the trailing newline? Couldn't AT_DATA detect whether a trailing newline is present in the expansion and then work whatever magic is necessary to print the last line correctly? I'll try to remember to ping again later.
