Re: LSB Commands and Utilities, Draft proposal
hi Jakob,
I've embedded some comments below:
> ---- 8< -- 8< -- Begin proposal -- 8< -- 8< ----
> Linux Standard Base Commands and Utilities
> Initial Proposal, v. 0.1
>
> Introduction
> ------------
> In an effort to maintain a commonality between Linux based operating systems
> and other GNU-like operating systems, LSB uses as the basis for its command
> and utility list the list of commands from the Single UNIX Specification,
> version 2, also known as UNIX98. However, in some cases it is either not
> possible for Linux based operating systems to comply and remain completely
> Free Software/Open Source, and in other cases a different program is more
> widely used on Linux based operating systems that provides the same
> functionality. Those places where LSB diverges from UNIX98 are detailed here,
> with rationale for each. For a listing of commands and utilities specified
> by UNIX98, along with a link to descriptions of how each command should
> operate and a note as to what package a Free Software/Open Source version of
> that command is available, see http://www.linuxbase.org/cu/
>
> Divergences
> -----------
>
> SCCS commands - admin, delta, get, prs, rmdel, sact, sccs, unget, val, what
> Divergence: These commands are not required by LSB. Instead, {RCS and/or CVS}
> are specified for LSB compliance.
> Rationale: These commands are part of the SCCS package, a method of managing
> and controlling revisions to files. I am not aware of a Free Software
> implementation of SCCS. However, RCS and CVS do similar jobs, are available
> as Free Software, and are presently in widespread use on Linux-based
operating
> systems.
This is not really a divergence since these commands are part of an
option in the Single UNIX Specification. I would just state that the
LSB does not support the optional SCCS development commands, by adding
something like:
"The SCCS commands are part of the Development option in the Single
UNIX Specification Version 2. These commands are not required to
be supported by the LSB".
As an aside I believe that there is an SCCS clone called CSSC, which
is GPL'd so you may want to redo the rationale a bit.
>
> Compression commands - pack, unpack, pcat, compress, uncompress, zcat
> Divergence: These commands are not required by LSB. Instead, the equivalent
> commands (gzip, gunzip, and zcat) from GNU Zip are specified for LSB
compliance.
> Rationale: Compress uses a patented algorithm and is therefore tricky to
> redistribute. Pack is marked as a legacy command in UNIX98. GNU Zip is Free
> Software unencumbered by patents, and also quite often produces better
> compression ratios than compress, as well as being the current de facto
> standard for compressed file distribution on Linux-based operating systems
and
> other GNU-like operating systems.
>
Again not a divergence for the optional LEGACY commands not to
be required, such as pack,pcat,unpack.
The specification for compress avoids the patented algorithm
and only describes compress in terms of uncompress and vice/versa
and so as written does not guarantee that much.
> Printing commands - cancel, lp, lpstat, pr
> Divergence: These commands are not required by LSB. Instead, the BSD printing
> commands (lpq, lpr, lprm, lptest, lpc, lpd, lpf, and pac).
> Rationale: These commands are from the System V style of managing printers.
> Linux-based operating systems tend to use the BSD family of printing tools.
>
The cancel and lpstat utilities are marked as part of the optional LEGACY
group in the Single UNIX Specification, so it can be documented
that the LSB does not support them.
The pr command appears to be supported by most Linux systems
and is part of the GNU package (not sure which one).
The lp command is from POSIX.2
> Archiving utilities - cpio, pax, tar
> Divergence: UNIX98 marks cpio and tar as legacy and pax as mandatory. LSB
> marks cpio and tar as mandatory and makes pax optional.
> Rationale: Both tar and cpio are widely used in current package formats for
> Linux-based operating systems (cpio being used by RPM and tar being used by
> basically all software distribution).
>
Again, its not a divergence to support cpio and tar, its just systems
not supporting the LEGACY option may not support them.
Pax is mandated by POSIX.2
Using the pax utility you can read both tar and cpio archives and
extended formats .
Recent experiments are that the available version of pax derived
from one of the BSD distributions handles cpio archives better than
cpio, but is a bit deficient in handle ustar format archives:-)
regards
Andrew
Reply to: