Re: LSB spec included commands

[Jim Knoble <jmknoble@jmknoble.cx>]

Circa 2001-Feb-27 08:13:19 -0800 dixit Daniel Quinlan:

: I propose making the following changes to the included commands list
: in the LSB database.
: 
: remove:
: 
:   compress ("gzip" instead)
:   uncompress ("gunzip" instead)

Fine; gunzip allegedly handles compressed files.  Although, i don't
think it's necessary to specify gunzip; 'gzip -d' is fine.

:   uudecode (not needed)
:   uuencode (not needed)

Fine.

:   which ("type" instead, not standardized)

What subset of 'type'?  'which' handles commands located on the PATH
only.  'type' is usally shell-specific and handles some combination of
executables on PATH, shell functions, and aliases (if the shell
supports them).

csh and tcsh don't support 'type'.  Nor does ash.

Is the intent to make a 'type' executable that handles commands on the
PATH only?  If so, why?  Why not use 'which' instead?

Why specify a shell-specific command at the expense of a
non-shell-specific command?

: add:
:   
:   awk
:   basename
:   batch

Fine.

:   cal

Echo Alan's comment here.

:   cksum
    
Does anyone use CRC checksums anymore?  What good are they?  Is md5sum
specified?  Why not just use that?

:   dd
:   expand
:   fuser
:   logname
:   nice
:   nl
:   nohup
:   od
:   pathchk
:   pr
:   sendmail
:   sort
:   time
:   tty
:   wc

Fine.

:   zcat (gzip)
   /^^^^^
  /

'gzip -dc' works for this (as does 'gunzip -c').  Why specify this, if
we're specifying gzip already?  Additionally, 'zcat' is often part of
the 'compress' suite on other operating platforms.  If specified at all
(and yes, i know many folks won't like this), it really ought to be
'gzcat'.  As far as i'm concerned, 'gzip' is all that's necessary to be
specified.

-- 
jim knoble | jmknoble@jmknoble.cx | http://www.jmknoble.cx/