Re: POSIX shell; bash ash pdksh & /bin/sh
Hi,
[This is a long post, but I have spent considerable time on
this. Please read it through before unlimbering the flame
throwers]
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
well.
----------------------------------------------------------------------
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
programs.
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.
manoj
--
"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: