Portability problem in rtems custom cfg's

[joel at OARcorp.com (joel at OARcorp.com)]

On Tue, 10 Aug 1999, Ralf Corsepius wrote:

> joel at OARcorp.com wrote:
> 
> > On Tue, 10 Aug 1999, Ralf Corsepius wrote:
> >
> > > * Seding out any non-printable characters is highly sensitive to
> > > portablity issues and should be avoided (I.e. using sed to filter out
> > > \r is questionable in general)
> > >
> > > * A portable sed pattern would be something similar to
> > > 's/\([0-9A-Za-z]*\)/\1/', but this would be useless for filtering out
> > > \r if sed is expanding \n to \r\n on output => Given sed's behavior on
> > > Cygwin is correct (which I doubt :-), RTEMS's attempts to filter out
> > > \r are basically broken and can't be worked around by any sed pattern.
> >
> > This is the bottom line answer I was looking for. :)
> >
> > What about using tr to remove the '\r'?  Wouldn't that be portable?
> 
> I am not so familiar with tr, but I guess using octal numbers with tr might
> be portable, because autoconf uses tr '\012' ' ' in acgeneral.m4 (otherwise
> we have found a bug in autoconf :-).

That is a good sign from a portability standpoint. But does it solve
things.

> However I fear this also won't help, because I assume that the cause of
> this problem might be stdin and/or stdout being opened in text-mode on
> Cygwin. If this is true, sed, tr, '|' (pipe), packhex and probably any tool
> that reads from stdin or writes to stdout will all show the same problem.

I hate to generate a temporary file.  

Looking at this from a different standpoint, all of these tools pipe into
packhex.  There is no reason packhex can't fix this.  It already knows how
to limit the number of charcaters on an output line.  It could be viewed
as the "S record canonicalizer" for RTEMS and produce whatever CR,
CF/LF, or LF the target wants.  I suppose it could even be taught to strip
S0 records which eliminates invoking sed altogether.

--joel