Why 2 strings program?

Originally Posted by smallpond The kernel has a very strict policy of maintaining binary compatibility with previous versions.

And?? What does that got to do with it. I was pointing out the absurdity of the notion of never modifying/improving any existing software because it might break things.

By the way - that's external binary compatibility. Internal compatibility gets broken all the time.

There's also eu-strings from the efiutils package, so that's actually 3 versions.

Both efi-utils and gnu versions include support for BSD's '-o' option (which the POSIX standard abandoned in favour of using '-t[dox]' due to inconsistent use of '-o' by different vendors).

Unfortunately, it seems that bsd went for a zero padding decimal on the location offset, while the other two went for space padding octal:

test@ws1:/usr/bin$ strings-GNU /tmp/file.txt 
this is a string.
and so is this.
test@ws1:/usr/bin$ strings-GNU -o /tmp/file.txt 
      0 this is a string.
     22 and so is this.
test@ws1:/usr/bin$ strings -o /tmp/file.txt 
0000000 this is a string.
0000018 and so is this.
test@ws1:/usr/bin$ eu-strings -o /tmp/file.txt 
      0 this is a string.
     22 and so is this.
test@ws1:/usr/bin$

As the bsd version doesn't conform to the POSIX standard (support '-t') I'd rather see one of the other versions being the default. I'd be interested to know what changing it would break, if anything.


afterthought: As the convention for octal representation is traditionally to include a leading zero, I guess all 3 got it wrong.

Originally Posted by briselec I don't get what point you're trying to make but if you have a look at the FreeBSD manpage for strings it looks a lot like the strings-GNU version.

Aha, indeed it has improved somewhat:-

https://svnweb.freebsd.org/base/rele...chain/strings/

Define "it works". I want to be able to tell it which character encoding to use for finding strings. I want it to give me offsets in hex. So for me it does not "work".

Defined as 'continues to work in the fashion in which it was originally intended'.

I would define your requirement as 'does not do what I want it to do / not fit for your purpose'.

What?? I was talking about adding functionality to the bsdstrings version without breaking existing usage. I'm not sure what you thought I was proposing.

Ah I see what you mean. Since strings-GNU already has the options you want, to me you'd adjust that version to be BSD strings compatible rather than the other way around.

I thought that the better option would be to upgrade to the new BSD strings, but looking at the man page for the latest BSD strings, they already broke the compatibility with the -o operator I used as an example from the BSD strings in Slackware; in which case you may as well just ditch BSD strings (or at least rename it to strings-BSD) and switch to the GNU version which works in the same way as the new BSD version.

I'll point Patrick to this thread.

Originally Posted by briselec A version I didn't know was there because someone, without consulting me, decided I get the crippled one by default.

Sorry, I just can't help but laugh at the notion that Pat should consult some random guy before making decisions about Slackware.

(Not that your complaint about the default strings program is unwarranted or anything -- I have no opinion about that -- just that your phrasing there is humorous.)

Originally Posted by montagdude Sorry, I just can't help but laugh at the notion that Pat should consult some random guy before making decisions about Slackware. (Not that your complaint about the default strings program is unwarranted or anything -- I have no opinion about that -- just that your phrasing there is humorous.)

The real reason for the long time between Slackware releases

Originally Posted by briselec The real reason for the long time between Slackware releases

Perhaps that's the reason why Slackware still exists until today, while other distro is struggling to survive
Every release is well tested until it's considered ready for public.