OpenBSD sdiff Question
peterjeremy at optushome.com.au
Sun Mar 16 07:10:57 UTC 2008
On Sat, Mar 15, 2008 at 03:21:01PM -0700, Bert JW Regeer wrote:
>Even if BSD has no tradition to keep a separate program version, it is
>still very handy to be able to give this data to other developers if
>something is failing. Programs that don't have a -v or --version switch are
>frustrating to people who are trying to find a workaround for a bug that is
>in that program, or when looking at documentation online, when the
>documentation is for one version and not for a newer version.
This demonstrates the difference between the BSD approach of having a
complete, integrated operating system, and the GNU/Linux approach of
having a variety of packages, each of different versions, which were
riginally intended to supplant the vendor-provided versions of those
utilities. A single string like "sdiff (GNU diffutils) 2.8.7" can
only report that the sdiff you are using is part of GNU diffutils
version 2.8.7. It is not particularly useful for reporting a failure
because that failure is equally likely to be in (eg) glibc (the
version of which is not reported).
For a FreeBSD tool, the closest thing to a simple version number would
>Dropping -v would be a bad thing, and make the tools not compatible, thus
>breaking many scripts that do expect a -v.
The only sensible reason for a script to invoke a tool with '-v' would
be to try and determine whether that tool has some feature/defect that
the script needs to know about. In this case, the reported version
number needs to be both in a format that the script can parse and have
values that the script recognizes. If a script expects to see:
>> $ sdiff -v
>> sdiff (GNU diffutils) 2.8.7
>> Written by Thomas Lord.
>> Copyright (C) 2004 Free Software Foundation, Inc.
>> This is free software; see the source for copying conditions. There is NO
>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Then it is likely to choke on (eg)
$ sdiff -v
sdiff (FreeBSD) 700055
Please excuse any delays as the result of my ISP's inability to implement
an MTA that is either RFC2821-compliant or matches their claimed behaviour.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20080316/272e745a/attachment.pgp
More information about the freebsd-hackers