On Fri, Oct 19, 2012 at 07:48:32PM -0500, David Champion wrote: > > But I can assume that if perl or python is present, it will accomplish > this task in a predictable way.
I wouldn't bet on being able to run perl or python. mutt gets build on a lot of systems where these are not normally installed, even if installed they may not be in $PATH. I also know about issues with the versions of both of them. > Neither sed nor awk is very portable in advanced usage; awk, nawk, gawk, > mawk, etc have whole different language specifications, and sed has > varying punctuation requirements in different implementations. The sed > command you posted scares me quite a lot once I think about supporting > it under six or seven different sed variants, from a Makefile that might > be running under any of a dozen "make" programs, launching the sed via > sh, ksh, bash, zsh, ash, pdksh, or .... Most of these combinations will > work fine, but there are some that are pretty sketchy. That sed command might scare you, but it is very simple. Nothing in it is likely to be unsupported by and sed, and it doesn't require anything special from the shell. The makefile probably requires a bourne shell (and might require a posix shell) elsewhere. If you want a scary sed script try: http://cvsweb.netbsd.org/bsdweb.cgi/othersrc/usr.bin/protoz/protoz?annotate=1.4 > I'm also not really interested in approximating what the compiler says > it is with a printable US-ASCII reduction of its output. And I still > don't know what to do about trigraphs under your suggestion, other than > to explicitly escape each one, or to know how to disable trigraphs in > each compiler that supports them. Ignore trigraphs - do any compilers do any more than generate a warning saying they've been ignored. If you really are worried, modify the sed script to also add "" into any trigraph sequence ( s/??/??""/g ). > Anyway, I fundamentally just don't think that we can expect arbitrary > compilers to tolerate arbitrary text in an arbitrary encoding with 0x22 > escaped, as a C literal string. You can. In any case the data you are feeding in is almost certainly 7-bit ascii. If not you need it to be - otherwise it won't necessarily display correctly. > But I could be persuaded by examples of > highly portable programs that do this successfully. If you were trying to include a binary code 'blob', then accuracy would matter, but you are including config/version information - it doesn't. > I'm interested in predictable behavior much more than I'm interested in > minimizing requirements for a compilation. > > I know I'm talking about narrow edge cases, but I don't think any of > this is more of an edge case than a build platform that can't install > Python (or Perl, or whatever), or a cross-compile that can't specify a > native compiler in addition to the cross compiler. Am I wrong about > that? > > Options that I see: > > 1. Nothing to see here, move along > 2. Write it in perl and tcl too, and test for which version will run > 3. Write it in shell and drink myself silly, in whichever order works best > 4. Require "make NATIVECC=..." when cross-compiling > > I'm good with 1 or 4. I'll entertain strong arguments for 2 or 3, > especially if you're buying, but I'm not sure either is a complete > solution. 1 and 4 are, if you accept the transference of the problem to > documented conditions for compilation. Don't add gratuitous build dependencies. David -- David Laight: da...@l8s.co.uk
