[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: POSIX shell; bash ash pdksh & /bin/sh

	[This is a long post, but I have spent considerable time on
	this. Please read it through before unlimbering the flame

	This discussion is mostly moot, since bash is an essential
 package, and essential packages do not just go away on a whim. There
 are too many scripts that depend on bash (calling /bin/bash
 explicitly); and we have mentioned here in the past, essentially
 promising authors that /bin/bash shall always exist).

	 If we already have bash on the system, disk space arguments
 are fallacious, since when invoked as sh, look at what bash does:


      If bash is invoked with the name sh, it tries to mimic the
       startup behavior of historical versions of sh  as  closely
       as  possible,  while  conforming  to the POSIX standard as


	There you go. The best of both worlds. In fact, adding a
 requirement for pdksh shall only make things worse for people with
 less disk space. 

	With this, I consider I have give adequate rationale
 why we shall always have bash on the system, and thus why it makes
 sense to ship with bash liked to /bin/sh.

>>"Chris" == Chris Ulrich <cdulrich@ucdavis.edu> writes:

 Chris>   What exactly is a "POSIX shell"?  I know of several different
 Chris> versions of the POSIX standard, although I've never actually
 Chris> gotten a look at any of them.  I know of several different
 Chris> versions of UNIX(tm) that all claim to be POSIX(tm) compliant.

	A POSIX shell is a command interpreter that meets teh
 requirement set out in the standards documents referred to as:
 ISO/IEC 9945-2:1993(E) ANSI/IEEE Std. 1003.2-1993. This standard
 defines a source-code-level interface to command interpretation, or
 "shell", services and common utility programs for application

	Excerpted table of contents:
 Section 1: General
      scope,normative references,conformance,test methods
 Section 2: Terminology and general requirements
      conventions, definition,builtin utilities,character set, locale,
      environemnt variables, regular expression and notations, files...
 Section 3: Shell command Language
      Introduction,quoting,token recognition, reserved words,commands,
      parameters and variables, word expansions, redirection, grammar,...
       (includes builtins like break,colon,continue,dot,eval, exec,
       exit, export,readonly,return,set,shift,trap, unset)
 Section 4:Execution environment utilities
      awk, basename, bc, cat, cd, chgrp, chmod, chown, cksum, cmp,
      comm, command, cp, cut, date, dd, diff, dirname, echo, ed, ...
 Section 5: User portability utilities Option
      alias, at, batch, bg, crontab, csplit, ctags, df, du, ex,
      expand, fc, fg, file, jobs, man, mesg, more, newgrp, nice, ...
 Section 6: Software development utilities option
      ar, make, strip
 Section 7: Language Independent System Services
      Shell command interface, Access Environment variables, RE
      matching, pattern matching, command option parsing, ...

 Annex A: (normative) C-Language Development Utilities Option
      c89, lex, yacc
 Annex B: (normative) C-Language Binding Option
      C language definitions, C Numeric limits, c binding for shell
      command interface, c binding for Access Environemnt variables, ...
 Annex C: (normative) Forttran development and runtime utilities
 Annex D: (informative) Bibliography
 Annex E: (informative) Rationale and Notes
 Annex F: (informative) Portability Considerations
 Annex G: (informative) Simple National profile
 Annex H: (informative) Proposals for future revisions.

	So you see, determining what is or is not a POSIX shell is not
 a crap shoot. There is a large (1200 page) standard to help one do
 so. One need not switch between Digital UNIX, HP-UX, and Solaris, and
 look at unsubstantiated claims for vendors about whether the shells
 are POSIX compliant (though indeed that saves hours of work). 

	The point is, you do not have to accept the claims as such. 

	For your information, giving test 3 arguments when the first
 one is a binary primary, results are unspecified by the standard.

	In that case, two POSIX compliant shells may well produce
 different results; you can draw no conclusion from this lack of
 consistent behaviour. 

 Chris>   For example, Solaris 2.6 claims to be POSIX compliant (although
 Chris> I am not sure which version).  Yet Solaris 2.6 does *not* have
 Chris> a POSIX shell as /bin/sh.  I am sure DEC Unix 4.0b claims to be
 Chris> POSIX compliant, yet its /bin/sh is similarly lacking in "POSIX
 Chris> shell" features.

	Really, Bugs in other operating systems are not really
 relevant here. As a contractor working for DEC, I would be interested
 in what POSIX features you think are missing (though you claim no
 POSIX knowledge). 

 Chris> As far as I know, a "POSIX shell" is a Bourne compatible shell
 Chris> that has several features first implemented in the Korn shell,
 Chris> including such things as $() for subshells and $(()) for
 Chris> arithmetic.

	I think, though this may be close to the truth, this is an
 imprecise, and misleading, characterization of what the POSIX shell
 is. Read the standard (if you do not have a copy, please do not make
 judgements out of empirical observation).

 Chris> I only know this because HP-UX claims to have a POSIX shell in
 Chris> /bin/sh, and that /bin/sh has these features.

	Looking at the implementation as a means of deducing the
 standard is fraught with dangers. Imagine looking at visual c to
 determine what was part of the ANSI C standard!

 Chris>   Because the specific features of the POSIX shell are available
 Chris> in so few versions of /bin/sh, I hesitate to use them in shell
 Chris> scripts I write, and would suggest to others that they stick to
 Chris> the LCD of the 7th edition unix /bin/sh (although it's safe to 
 Chris> assume that test is a builtin these days, though it isn't in 
 Chris> ULTRIX).

	Your personal preferences are, (I'm sorry), irrelevant. I
 prefer looking at the standard and using the constructs found
 therein, rather than looking at years old beast.


 "The less you know about home computers the more you'll want the new
 IBM PS/1." Advertisment in the Edmonton Journal, Thursday, December
 13, 1990
Manoj Srivastava  <srivasta@acm.org> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E

To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: