ls(1) new command line options '-/' and '-%': CIFS system attributes support [PSARC/2007/394 FastTrack timeout 07/11/2007]

[Joerg Schilling]

Joseph Kowalski <jek3 at sun.com> wrote:

> Joerg Schilling wrote:
> > I don't know why someone tries to mandate that every long option should have
> > a short option equivalent. It looks to me as if somebody did use the 
> > disadvantages of the Sun getopt() implementation as prototype for some 
> > guidelines.
> >   
> It was to allow all options to be expressible a short options.  By the 
> rationale, long-options
> are just a EOU for people need mnemonic hints.  (This is in the CLIP 
> rationale if anybody
> wants to read it or read it beyond a few tables.)

This is a paradigma that helps if the utility offers between 5..20 options
but it does not help for modern programs that give a lot more functionality
than programs did imlement in the 1970s. In the 1970s, programs have been 
limited in functionality by low amounts of RAM. Pipes have been invented and 
more complex functionality has been implemented as a pipeline chain of filter
programs.

But pipeline filters are limited in their functionality as they only may
filter the output of programs. They are not able to act as a filter to the
internal data structures of a program. A notable example in this context is 
"libfind". It is used by mkisofs and star and allows to filter the internal
data flow of the programs, giving you the ability to implement features that
are impossible with pilepines. We live in the age of shared libraries and could
use them more widely than done already ;-)

The paradigma of the 1970s was:

	"Write small programs and resuse them by combining their functionality
	via pipes."

This works with limited RAM and needs few options. The paradigma of today is:

	"Write reusable libraries and let more propgrams use them."

This needs more RAM (we just have it now) and more options in the resulting 
programs. For implementing option, we should not use the methods from the 1970s
but the methods of today....


> It find it funny that we are asserting that we need a greater option 
> space other than
> [a-zA-Z0-9]. That's 62 distinct option flags.  We should be very 
> red-faced that we
> are having this discussion rather than a discussion about well factored 
> utilities.
>
> Sigh,...  Poorly considered incremental changes...

If you really "design" a utility this way to have 62 single char options,
this would result in a utility that would be really hard to use. Nobody would
remember the relation between options and functionality.

You are right, utilities with more than 10 single char (only) options are 
poorly designed and in most cases a result of incremental changes.

Let us look at the reality of today, for all listed utilities, I did count only
basic options and not alias names to options:

GNU tar		implemented 70 options the last time I checked. I would
		guess it has ~ 80 options today.

Studio 12 cc	implements 142 options

mkisofs		implements 152 options

star		implements 157 options

Studio 12 CC	implements 159 options

GNU cc		implements an unknown but much bigger amount of options

All these utilities use long options and none of these utilities would be
able to live with single char option aliases for all options they implement.

For utilities that have less than ~ 10-20 options, I would like to see
long mnemonic options as aliases but we need to be very careful here and don't 
do the same mistake that has been done by the FSF. I do not like to see
FAQs that mention long options (being mnemocial help for POSIX short
options only) because this will create at least non-portable shell scripts
as widely seen on Linux.

If we would offer long option aliases (but not only then), I would like to see
warnings in the man pages that inform people about enhancements on the POSIX
utility interface and a note that shell scripts should not use these 
enhancements if portablity might be an issue.

As an example for the in-line help of a utility that helps people to avoid
non-portable scripts, I append the "sfind -help" output to the end of this 
mail... 


> At this point, somebody can create "Son of CLIP" if they want.  After 
> the discussion
> about CLIP it should be obvious incremental additions are not going to 
> accepted.  This
> was a painful exercise where everyone had a view and, more importantly, 
> the concepts
> related to each other in ways which aren't obvious. The CLIP cases took 
> something
> on the order of 4 years to complete and "killed" a number of sponsors.  
> Else, please
> accept the policy.

If the policy does no longer meet the reality, it needs to be updated.
I am willing to cooperate for such an updated guideline.

BTW: could you explain what you understand by "incremental additions are not 
going to accepted"?


/*--------------------------------------------------------------------------*/

Usage:	sfind [options] [path_1 ... path_n] [expression]
Options:
	-H	follow symbolic links encountered on command line
	-L	follow all symbolic links
*	-P	do not follow symbolic links (default)
*	-help	Print this help.
*	-version Print version number.
Operators in decreasing precedence:
	( )	group an expression
	!, -a, -o negate a primary (unary NOT), logical AND, logical OR
Primaries:
*	-acl	      TRUE if the file has additional ACLs defined
	-atime #      TRUE if st_atime is in specified range
*	-chgrp gname/gid always TRUE, sets st_gid to gname/gid
*	-chmod mode/onum always TRUE, sets permissions to mode/onum
*	-chown uname/uid always TRUE, sets st_uid to uname/uid
	-ctime #      TRUE if st_ctime is in specified range
	-depth	      evaluate directory content before directory (always TRUE)
*	-dostat	      Do not do stat optimization (always TRUE)
	-exec program [argument ...] \;
	-exec program [argument ...] {} +
*	-false	      always FALSE
*	-follow	      outdated: follow all symbolic links (always TRUE)
*	-fstype type  TRUE if st_fstype matches type
	-group gname/gid TRUE if st_gid matches gname/gid
*	-inum #	      TRUE if st_ino is in specified range
*	-linkedto path TRUE if the file is linked to path
	-links #      TRUE if st_nlink is in specified range
*	-lname glob   TRUE if symlink name matches shell glob
*	-local	      TRUE if st_fstype does not match remote fs types
*	-lpat pattern TRUE if symlink name matches pattern
*	-ls	      list files similar to 'ls -ilds' (always TRUE)
*	-maxdepth #   descend at most # directory levels (always TRUE)
*	-mindepth #   start tests at directory level # (always TRUE)
	-mtime #      TRUE if st_mtime is in specified range
	-name glob    TRUE if path component matches shell glob
	-newer file   TRUE if st_mtime newer then mtime of file
	-newerXY file TRUE if [acm]time (X) newer then [acm]time (Y) of file
	-nogroup      TRUE if not in group database
	-nouser       TRUE if not in user database
	-ok program [argument ...] \;
*	-pat pattern  TRUE if path component matches pattern
*	-path glob    TRUE if full path matches shell glob
	-perm mode/onum TRUE if symbolic/octal permission matches
*	-ppat pattern TRUE if full path matches pattern
	-print	      print file names line separated to stdout (always TRUE)
*	-printnnl     print file names space separated to stdout (always TRUE)
	-prune	      do not descent current directory (always TRUE)
	-size #	      TRUE if st_size is in specified range
*	-sparse	      TRUE if file appears to be sparse
*	-true	      always TRUE
	-type c	      TRUE if file type matches, c is from (b c d D e f l p P s)
	-user uname/uid TRUE if st_uid matches uname/uid
*	-xattr	      TRUE if the file has extended attributes
	-xdev, -mount restrict search to current filesystem (always TRUE)
Primaries marked with '*' are POSIX extensions, don't use them in portable scripts.
If path is omitted, '.' is used. If expression is omitted, -print is used.

Jörg

-- 
 EMail:joerg at schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js at cs.tu-berlin.de                (uni)  
       schilling at fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily