Conference turris::digital_unix

    Could you clarify what command sequence you're running.
    
    grep <search string> <binary file>
    
    	       ANS/OR
    
    /usr/bin/strings <binary file> | grep <search string>
    
    For it's worth /usr/bin/grep & /usr/ucb/grep are the same file /usr/ucb
    is a symbolic link to /usr/bin.
    
    strings <pattern> will search the initialised data space
    strings -a <pattern> will search the whole object file.
    
    You should also note the following comment in the man pages for grep
    
    [Digital]  Running grep on a non-text file (for example, an .o file)
    pro- duces unpredictable results and is discouraged.
    
    
    Brendan
    
    

.1 >   You should also note the following comment in the man pages for grep
.1 >  [Digital]  Running grep on a non-text file (for example, an .o file)
.1 >   pro- duces unpredictable results and is discouraged.
 
.0>First off, the customer and I both know that results of grep 
.0>on non-text files are unreliable. 

It's ok, both I and the customer know this, that's why I made it the 
first thing I said, should have known better and mentioned it at the 
end too  :-) 

This query is as much for my sake to help me understand what 
differences it makes to grep having the non-text file and why 
one variant might behave differently to another. 

The customer has already been told not to expect it to work. 



Anyway back to the technical incantations....
the actual command being used are:

/usr/bin/grep dbdev2 aaaaa.en   
/sbin/grep dbdev2 aaaaa.en

Where dbdev2 is a text string in the file being searched for
and aaaaa.en is the file name. 

No switches, no nothing else.  

The first one fails, the second one works on v4.0b, 
(on 3.2g they both worked). 

The strings command only came into it in that if he does a strings and
then pipes it to the failing variant of grep it then works and this 
is used as a work around to make sure he's complying with the man 
pages by only making grep search a bunch of text characters. 


Thanks if you can explain why the two greps seem to behave differently ... 
I didn't even realise we had two different greps until now  :-) 

Details from repro posted below... 


Jo. 

[email protected]> /usr/bin/grep dbdev2 aaaaaaaa.en
[email protected]> /usr/ucb/grep dbdev2 aaaaaaaa.en
[email protected]> /sbin/grep dbdev2 aaaaaaaa.en
dbdev2                  6.1a$2
dbdev2                  6.1a$2
dbdev2                  6.1a$2
[email protected]> uname -a
OSF1 host40b.uvo.dec.com V4.0 564 alpha


[email protected]> /usr/bin/grep dbdev2 aaaaaaaa.en
dbdev2                  6.1a$2
dbdev2                  6.1a$2
dbdev2                  6.1a$2
[email protected]> /sbin/grep dbdev2 aaaaaaaa.en
dbdev2                  6.1a$2
dbdev2                  6.1a$2
dbdev2                  6.1a$2
[email protected]> /usr/ucb/grep dbdev2 aaaaaaaa.en
dbdev2                  6.1a$2
dbdev2                  6.1a$2
dbdev2                  6.1a$2
[email protected]> uname -a
OSF1 host32g.uvo.dec.com V3.2 62 alpha

	Jo,

	/usr/bin/grep and /sbin/grep are built from the same source
	file, grep.c, so you'd think they'd give the same results.
	They should.  They're built from different makefiles though
	and that's the key.

	In V4.0, we added -D_SBCS to the makefile for /usr/bin/grep
	to turn on an optimization in grep.c.  But we forgot to do
	the same in the makefile for /sbin/grep.

	So the reason for the different results is that the two
	greps are following different code paths.  Perhaps one is
	right and one is wrong, or perhaps the "lines" in the binary
	files you're searching are longer than grep's maximum line
	length and the two code paths are just handling that case
	differently.  Not sure.

	I'll QAR this.

	Thanks for posting this, Jo!

	Tom

>        /usr/bin/grep and /sbin/grep are built from the same source
>        file, grep.c, so you'd think they'd give the same results.

sendmail, mailq, and newaliases are built from the same sources, but I don't 
expect them to give the same results.

PJDM

                   <<< Note 9918.6 by BIGUN::nessus.cao.dec.com::Mayne "A wretched hive of scum and villainy" >>>
    
    sendmail,mailq,newaliases (and smtpd) are not only built from the same
    sources, they are delivered as the same file with all the above names
    hardlinked to it. /usr/bin/grep and /sbin/grep on the other hand are
    built and delivered as two distinct files.
    
    	Yaacov

    

Thanks for the explaination - it all makes a lot more sense now. 
A colleague and I had suposed there were probably different 
libraries being used or something like that. 

So they should both fail, and will in a future version when the 
QAR is implemented - all the more weight to making sure the 
customer does strings piped to grep, jolly good. 

Incidentally LANG didn't appear to be set, if this still makes
a difference. 

Re: sendmail and all the rest - they might be the same sources
but surely like chsh, chfn and passwd they check how they are 
called and behave differently accordingly.  In some ways that's 
no different to saying that tar t, tar c and tar x are all 
built from the same sources isn't it? 

They also have man pages that tell you that dependant on how 
you call them they will behave differently.  The grep man page
however doesn't specify whether it's refering to the 
/usr/ucb, the /usr/bin or the /sbin version which rather 
implies that they are interchangable and behave the same. 

Either way thanks, main objective of this note, expanding my 
knowledge of how these things may differ has been achieved. 

Thanks again 

Jo. 

That was my point: saying that two files use the same sources is meaningless 
without further explanation.

PJDM