This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Opinion on shell script portability, please
- To: John Wehle <john at feith dot com>
- Subject: Re: Opinion on shell script portability, please
- From: "Zack Weinberg" <zackw at Stanford dot EDU>
- Date: Thu, 15 Mar 2001 21:02:28 -0800
- Cc: gcc at gcc dot gnu dot org
- References: <200103160311.WAA02389@jwlab.FEITH.COM>
On Thu, Mar 15, 2001 at 10:11:45PM -0500, John Wehle wrote:
> > od -c test.o | cut -c8- |
> > sed 's/\*/./g; s/ \\n/*/g; s/ [0-9][0-9][0-9]/./g; s/ \\[^ ]/./g' |
> > tr '*
> > ' '
> > ' | sed 's/ //g' | grep format
>
> Is this intended to turn the output of od into one long line? If so, then
> please keep in mind that some versions of grep don't support really long
> lines.
It turns most of the file into one really long line. But the strings
we're looking for have newlines in them, and after a great deal of
dinking around those newlines wind up as real newlines in the output.
I.e. if I chop off the 'grep format' bit, I get
.ELF............................$.......4.....(.....
format:PFEEEI@@:tamrof
format:.......C:tamrof
format:1Z@...#<:tamrof
format:..V.R..B:tamrof
format:.....Z(.:tamrof
............01.01....GCC:(GNU)2.95.320010219(prerelease)...symtab..strtab..shstr
tab..text..data..bss..note..comment.............................................
............4.......................!...............4...x...................'...
....................................,.......................................2...
................).......................................;.......................
................................................................................
................................................................................
....................................................x........test.c.gcc2_compile
d..table.
where the stuff starting with the line that has "GCC:(GNU)" in it is
all on one line.
I could throw a 'fold' in there, but I don't know if that's portable.
> Is the dot in D.PDP-10 the only problem preventing strings from being
> used? Any chance the candidate entry can be massaged?
I was told that normalized PDP-10 doubles always have an unprintable
character as their second byte.
There's a chance of round-off error causing the same problem in the
least significant byte of any of the tests. That's why we only
inspect the middle six bytes (since we don't know which end is least
significant).
zw