|
Home > Archive > Debian Developers > November 2006 > Proposed new POSIX sh policy, version two
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Proposed new POSIX sh policy, version two
|
|
| Russ Allbery 2006-11-21, 1:31 am |
| Okay, here's try number two. I tried to incorporate the feedback from
various people. Please critique.
--- debian-policy-3.7.2.2/policy.sgml 2006-10-02 15:36:50.000000000 -0700
+++ /home/eagle/dvl/policy/policy.sgml 2006-11-20 22:35:59.000000000 -0800
@@ -5662,7 +5670,7 @@
<file>/etc/default</file>, which typically will have the same
base name as the <file>init.d</file> script. This extra file
should be sourced by the script when the script runs. It
- must contain only variable settings and comments in POSIX
+ must contain only variable settings and comments in SUSv3
<prgn>sh</prgn> format. It may either be a
<tt>conffile</tt> or a configuration file maintained by
the package maintainer scripts. See <ref id="config-files">
@@ -6723,34 +6731,54 @@
</p>
<p>
- The standard shell interpreter <file>/bin/sh</file> can be a
- symbolic link to any POSIX compatible shell, if <tt>echo
- -n</tt> does not generate a newline.<footnote>
- Debian policy specifies POSIX behavior for
- <file>/bin/sh</file>, but <tt>echo -n</tt> has widespread
- use in the Linux community (in particular including this
- policy, the Linux kernel source, many Debian scripts,
- etc.). This <tt>echo -n</tt> mechanism is valid but not
- required under POSIX, hence this explicit addition.
- Also, rumour has it that this shall be mandated under
- the LSB anyway.
+ Scripts may assume that <file>/bin/sh</file> implements the
+ SUSv3 Shell Command Language<footnote>
+ Single UNIX Specification, version 3, which is also IEEE
+ 1003.1-2004 (POSIX), and is available on the World Wide Web
+ from <url id="http://www.unix.org/version3/online.html"
+ name="The Open Group"> after free
+ registration.</footnote>
+ plus the following additional features not mandated by
+ SUSv3:<footnote>
+ These features are in widespread use in the Linux community
+ and are implemented in all of bash, dash, and ksh, the most
+ common shells users may wish to use as <file>/bin/sh</file>.
</footnote>
- Thus, shell scripts specifying <file>/bin/sh</file> as
- interpreter must only use POSIX features. If a script
- requires non-POSIX features from the shell interpreter, the
- appropriate shell must be specified in the first line of the
- script (e.g., <tt>#!/bin/bash</tt> ) and the package must
- depend on the package providing the shell (unless the shell
- package is marked "Essential", as in the case of
- <prgn>bash</prgn> ).
+ <list>
+ <item><tt>echo -n</tt>, if implemented as a shell built-in,
+ must not generate a newline.</item>
+ <item><tt>test</tt>, if implemented as a shell built-in, must
+ support <tt>-a</tt> and <tt>-o</tt> as binary logical
+ operators.</item>
+ <item><tt>local</tt> to create a scoped variable must be
+ supported; however, <tt>local</tt> may or may not preserve
+ the variable value from an outer scope and may or may not
+ support arguments more complex than simple variable. Only
+ uses such as:
+<example compact>
+fname () {
+ local a
+ a=''
+ # ... use a ...
+}
+</example>
+ must be supported.
+ </item>
+ </list>
+ If a shell script requires non-SUSv3 features from the shell
+ interpreter other than those listed above, the appropriate shell
+ must be specified in the first line of the script (e.g.,
+ <tt>#!/bin/bash</tt> ) and the package must depend on the package
+ providing the shell (unless the shell package is marked
+ "Essential", as in the case of <prgn>bash</prgn> ).
</p>
<p>
- You may wish to restrict your script to POSIX features when
- possible so that it may use <file>/bin/sh</file> as its
- interpreter. If your script works with <prgn>dash</prgn>
- (originally called <prgn>ash</prgn> ), it's probably POSIX
- compliant, but if you are in doubt, use
+ You may wish to restrict your script to SUSv3 features plus the
+ above set when possible so that it may use <file>/bin/sh</file>
+ as its interpreter. If your script works with <prgn>dash</prgn>
+ (originally called <prgn>ash</prgn> ), it probably complies with
+ the above requirements, but if you are in doubt, use
<file>/bin/bash</file>.
</p>
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Bruce Sass 2006-11-21, 1:31 am |
| On Mon November 20 2006 23:52, Russ Allbery wrote:
> + from <url id="http://www.unix.org/version3/online.html"
> + name="The Open Group"> after free
> + registration.</footnote>
Any reason for not using:
http://www.opengroup.org/onlinepubs/009695399/
(no registration required) or mentioning "apt-get install susv3" (which
fetches from the opengroup.org URI)?
- Bruce
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Russ Allbery 2006-11-21, 7:25 am |
| Bruce Sass <bmsass@shaw.ca> writes:
> On Mon November 20 2006 23:52, Russ Allbery wrote:
[vbcol=seagreen]
> Any reason for not using:
> http://www.opengroup.org/onlinepubs/009695399/
Presumably that's a URL generated by someone else who registered, yes? I
don't like the registration business, but if that's what they want to do,
I don't really feel right about bypassing it.
> (no registration required) or mentioning "apt-get install susv3" (which
> fetches from the opengroup.org URI)?
I thought about mentioning the latter, but I'm a little leery of
mentioning a contrib installer package in Policy. Plus, basically it just
does what you can do yourself with a web browser, I thought... yeah, it's
a pretty simple package.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Bruce Sass 2006-11-21, 7:25 am |
| On Tue November 21 2006 01:40, Russ Allbery wrote:
> Bruce Sass <bmsass@shaw.ca> writes:
>
> Presumably that's a URL generated by someone else who registered,
> yes? I don't like the registration business, but if that's what they
> want to do, I don't really feel right about bypassing it.
http://www.opengroup.org/ is The Open Group's website, I don't think
they would need to register themselves.
>
> I thought about mentioning the latter, but I'm a little leery of
> mentioning a contrib installer package in Policy. Plus, basically it
> just does what you can do yourself with a web browser, I thought...
> yeah, it's a pretty simple package.
makes sense
- Bruce
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Bruce Sass 2006-11-21, 7:25 am |
| On Tue November 21 2006 03:18, Bruce Sass wrote:
> On Tue November 21 2006 01:40, Russ Allbery wrote:
>
> http://www.opengroup.org/ is The Open Group's website, I don't think
> they would need to register themselves.
Hmmm, ok, I see what you are getting at, from the terms and conditions:
"""
We ask readers to give us their name and email address for a number of reasons:
To enable us to gauge the interest in any particular document/subject area
To enable us to alert you to new editions of the specification
To enable us to send you details of any corrigenda
"""
The 009695399 in the www.opengroup.org URI looks to be a publication
number of some sort (one digit shy of an ISBN though); it is used by the
wikipedia entry (where I first found it), and the similar 9-digit bit of
the URL in the Debian susv3 installer gets rewritten to it.
I think that if the susv3 Maintainer (Jeff Bailey) registered as "Debian" to
get the URL then it would be OK, maybe even preferable, to use:
http://www.opengroup.org/onlinepubs/007904975/ in Policy.
- Bruce
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Jeff Bailey 2006-11-21, 1:20 pm |
| On 21/11/06, Bruce Sass <bmsass@shaw.ca> wrote:
>
> On Tue November 21 2006 03:18, Bruce Sass wrote:
> "
At this point, I don't remember why the URL got chosen. I was on the Austin
lists for quite some time, and Andrew Josey put out a call for people to
package the SUSv3 standards. I remember sorting out the details with him at
the time.
Hmmm, ok, I see what you are getting at, from the terms and conditions:[vbcol=seagreen]
> """
> We ask readers to give us their name and email address for a number of
> reasons:
> To enable us to gauge the interest in any particular document/subject area
> To enable us to alert you to new editions of the specification
> To enable us to send you details of any corrigenda
> """
>
> The 009695399 in the www.opengroup.org URI looks to be a publication
> number of some sort (one digit shy of an ISBN though); it is used by the
> wikipedia entry (where I first found it), and the similar 9-digit bit of
> the URL in the Debian susv3 installer gets rewritten to it.
>
> I think that if the susv3 Maintainer (Jeff Bailey) registered as "Debian"
> to
> get the URL then it would be OK, maybe even preferable, to use:
> http://www.opengroup.org/onlinepubs/007904975/ in Policy.
I could do this, but I don't know how to get appropriate permission to
represent myself as "Debian" to the Open Group. I've added
leader@debian.org to the cc: list to see if there's a suggestion.
--
Jeff Bailey - http://www.raspberryginger.com/jbailey/
| |
| Russ Allbery 2006-11-21, 1:20 pm |
| Bruce Sass <bmsass@shaw.ca> writes:
> The 009695399 in the www.opengroup.org URI looks to be a publication
> number of some sort (one digit shy of an ISBN though); it is used by the
> wikipedia entry (where I first found it), and the similar 9-digit bit of
> the URL in the Debian susv3 installer gets rewritten to it.
If you register, all you get is a link with one of those numbers in it. I
registered a while back and I have a bookmark with a similar number in it.
I presumed it was just a registration number generated by their code.
The registration system is not particularly aggressive about
authenticating you.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Anthony Towns 2006-11-21, 7:22 pm |
| On Tue, Nov 21, 2006 at 07:13:50AM -0800, Jeff Bailey wrote:
> I could do this, but I don't know how to get appropriate permission to
> represent myself as "Debian" to the Open Group. I've added
> leader@debian.org to the cc: list to see if there's a suggestion.
Consider yourself so delegated to act in Debian's name on that matter.
I'd suggest emailing Andrew Josey / the open group as well, but your call.
Cheers,
aj
| |
| Clint Adams 2006-11-22, 1:40 am |
| > Okay, here's try number two. I tried to incorporate the feedback from
> various people. Please critique.
Other than wanting the 'echo -n' and -a/-o bits to go away, I think this
looks pretty good.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Jari Aalto 2006-11-22, 7:22 pm |
| Russ Allbery <rra@debian.org> writes:
> Okay, here's try number two. I tried to incorporate the feedback from
> various people. Please critique.
>
> --- debian-policy-3.7.2.2/policy.sgml 2006-10-02 15:36:50.000000000 -0700
> +++ /home/eagle/dvl/policy/policy.sgml 2006-11-20 22:35:59.000000000 -0800
> @@ -5662,7 +5670,7 @@
> <file>/etc/default</file>, which typically will have the same
> base name as the <file>init.d</file> script. This extra file
> should be sourced by the script when the script runs. It
> - must contain only variable settings and comments in POSIX
> + must contain only variable settings and comments in SUSv3
> <prgn>sh</prgn> format. It may either be a
> <tt>conffile</tt> or a configuration file maintained by
> the package maintainer scripts. See <ref id="config-files">
> @@ -6723,34 +6731,54 @@
> </p>
>
> <p>
> - The standard shell interpreter <file>/bin/sh</file> can be a
> - symbolic link to any POSIX compatible shell, if <tt>echo
> - -n</tt> does not generate a newline.<footnote>
> - Debian policy specifies POSIX behavior for
> - <file>/bin/sh</file>, but <tt>echo -n</tt> has widespread
> - use in the Linux community (in particular including this
> - policy, the Linux kernel source, many Debian scripts,
> - etc.). This <tt>echo -n</tt> mechanism is valid but not
> - required under POSIX, hence this explicit addition.
> - Also, rumour has it that this shall be mandated under
> - the LSB anyway.
> + Scripts may assume that <file>/bin/sh</file> implements the
> + SUSv3 Shell Command Language<footnote>
> + Single UNIX Specification, version 3, which is also IEEE
> + 1003.1-2004 (POSIX), and is available on the World Wide Web
> + from <url id="http://www.unix.org/version3/online.html"
> + name="The Open Group"> after free
> + registration.</footnote>
> + plus the following additional features not mandated by
> + SUSv3:<footnote>
> + These features are in widespread use in the Linux community
> + and are implemented in all of bash, dash, and ksh, the most
> + common shells users may wish to use as <file>/bin/sh</file>.
> </footnote>
> - Thus, shell scripts specifying <file>/bin/sh</file> as
> - interpreter must only use POSIX features. If a script
> - requires non-POSIX features from the shell interpreter, the
> - appropriate shell must be specified in the first line of the
> - script (e.g., <tt>#!/bin/bash</tt> ) and the package must
> - depend on the package providing the shell (unless the shell
> - package is marked "Essential", as in the case of
> - <prgn>bash</prgn> ).
> + <list>
> + <item><tt>echo -n</tt>, if implemented as a shell built-in,
> + must not generate a newline.</item>
> + <item><tt>test</tt>, if implemented as a shell built-in, must
> + support <tt>-a</tt> and <tt>-o</tt> as binary logical
> + operators.</item>
> + <item><tt>local</tt> to create a scoped variable must be
> + supported; however, <tt>local</tt> may or may not preserve
> + the variable value from an outer scope and may or may not
> + support arguments more complex than simple variable. Only
> + uses such as:
> +<example compact>
> +fname () {
> + local a
> + a=''
> + # ... use a ...
> +}
> +</example>
> + must be supported.
> + </item>
> + </list>
> + If a shell script requires non-SUSv3 features from the shell
> + interpreter other than those listed above, the appropriate shell
> + must be specified in the first line of the script (e.g.,
> + <tt>#!/bin/bash</tt> ) and the package must depend on the package
> + providing the shell (unless the shell package is marked
> + "Essential", as in the case of <prgn>bash</prgn> ).
> </p>
I would drop that "special" case and always require explicit
requirement for the shell. It's more clear to see which packages
"need" bash to make them work. someone may then provide a patch to
"make bash go away". I suggest removing the last 2 lines:
If a shell script requires non-SUSv3 features from the shell
interpreter other than those listed above, the appropriate shell
must be specified in the first line of the script (e.g.,
<tt>#!/bin/bash</tt> ) and the package must depend on the package
providing the shell.
</p>
> <p>
> - You may wish to restrict your script to POSIX features when
> - possible so that it may use <file>/bin/sh</file> as its
> - interpreter. If your script works with <prgn>dash</prgn>
> - (originally called <prgn>ash</prgn> ), it's probably POSIX
> - compliant, but if you are in doubt, use
> + You may wish to restrict your script to SUSv3 features plus the
> + above set when possible so that it may use <file>/bin/sh</file>
> + as its interpreter. If your script works with <prgn>dash</prgn>
> + (originally called <prgn>ash</prgn> ), it probably complies with
> + the above requirements, but if you are in doubt, use
> <file>/bin/bash</file>.
> </p>
>
> --
> Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Russ Allbery 2006-11-22, 7:22 pm |
| Jari Aalto <jari.aalto@cante.net> writes:
> I would drop that "special" case and always require explicit requirement
> for the shell. It's more clear to see which packages "need" bash to make
> them work. someone may then provide a patch to "make bash go away".
This would conflict with Policy 3.5, which says that packages should not
depend on any essential package unless they need a specific version.
Policy shouldn't contradict itself, so I think this would require further
discussion and justification for making an exception for bash.
In practice, I don't think it would ever be possible to remove any feature
from the set of essential packages in Debian.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Thomas Bushnell BSG 2006-11-22, 7:22 pm |
| On Thu, 2006-11-23 at 01:15 +0200, Jari Aalto wrote:
>
> I would drop that "special" case and always require explicit
> requirement for the shell. It's more clear to see which packages
> "need" bash to make them work. someone may then provide a patch to
> "make bash go away". I suggest removing the
Russ has already explained why this would violate other parts of policy.
I'm interested in why we should care at all. PERL is a far bigger space
hog than bash.
Someone somewhere told a Big Lie: "bash isn't essential to Debian".
Lots of people perhaps believe this lie, and have a Grand Quest to "make
bash go away". What is the reason? Why is it worth energy on the part
of *everyone else*?
Thomas
| |
| Jari Aalto 2006-11-23, 7:35 am |
| Thomas Bushnell BSG <tb@becket.net> writes:
> On Thu, 2006-11-23 at 01:15 +0200, Jari Aalto wrote:
>
> Russ has already explained why this would violate other parts of policy.
>
> I'm interested in why we should care at all. PERL is a far bigger space
> hog than bash.
>
> Someone somewhere told a Big Lie: "bash isn't essential to Debian".
> Lots of people perhaps believe this lie, and have a Grand Quest to "make
> bash go away". What is the reason? Why is it worth energy on the part
> of *everyone else*?
Bash is not essential for running Debian. It is possible to run old
PCs and old laptops completely free of bash. The point here is not the
disk consumption, but the reduced memory constrainsts. When scripts
are written with only "sh" in mind, they become portable to even
embedded systems (think busybox). Every bash-dependent scipt that runs
on the system, takes memory out from other processes.
Explicitly listing bash in "Depends:" may be redundant but it makes
things transparent and not "hidden". It announces what is the required
"feature" that the package cannot be run without.
It is possible to remove bash after install and use alternative
shells, as has been demonstrated. And if Package is patched so that
no more bash constructs are needed, it becomes generic.
Education sector and 3rd world still have PCs that are *years* and
*tears* old. Everybody do not live in countries where computers or
hardware are cheap.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Jari Aalto 2006-11-23, 7:35 am |
| Russ Allbery <rra@debian.org> writes:
> Jari Aalto <jari.aalto@cante.net> writes:
>
>
> This would conflict with Policy 3.5, which says that packages should not
> depend on any essential package unless they need a specific version.
> Policy shouldn't contradict itself, so I think this would require further
> discussion and justification for making an exception for bash.
>
> In practice, I don't think it would ever be possible to remove any feature
> from the set of essential packages in Debian.
I'm not suggesting to remove features from essential, but I think the
policy should take the shells as special case, because the
sh-compliances (SusV/POSIX) itself is a matter of its own. There are
no viable alternative implementation of PERL which is in essential, likewise
for the rest.
But for the shells there are. I think the Policy should exempt shells
and require that if package is not POSIX/Susv -compiant, it needs to
announce dependance on a particular shell -- where it bash, tcsh,
pdksh ..., if it uses those shells special features.
Jari
--
To UNSUBSCRIBE, email to debian-policy-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Marvin Renich 2006-11-23, 1:17 pm |
| * Jari Aalto <jari.aalto@cante.net> [061123 06:56]:
>
> But for the shells there are. I think the Policy should exempt shells
> and require that if package is not POSIX/Susv -compiant, it needs to
> announce dependance on a particular shell -- where it bash, tcsh,
> pdksh ..., if it uses those shells special features.
>
> Jari
>
Making an exception like this is not a good idea, and is not necessary.
If it is decided that allowing bash to be replaced by one of a short
list of other shells is a good idea, then make each shell in the list
Provide: almost-posix-shell (or something) and make almost-posix-shell
essential (can a virtual package be essential?). Or make a real package
almost-posix-shell that depends on bash | dash | ....
I have no particular opinion on the bash/dash/* issue, but making policy
conflict with itself or have unnecessary special cases is bad.
In fact, you could remove the whole issue of listing specific features
required of /bin/sh from the policy if you make a real package
almost-posix-shell, place the documentation of what can be expected of
it in the package, and replace bash by almost-posix-shell in the
"essential" list.
This doesn't, of course, do anything to help the issue of ensuring the
non-bugginess (w.r.t. requirements of almost-posix-shell) of the shells
that almost-posix-shell depends on, but it simplifies policy and moves
the details into a single location.
....Marvin
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Jari Aalto 2006-11-23, 1:17 pm |
| Marvin Renich <mrvn@renich.org> writes:
> * Jari Aalto <jari.aalto@cante.net> [061123 06:56]:
>
> Making an exception like this is not a good idea, and is not necessary.
> If it is decided that allowing bash to be replaced by one of a short
> list of other shells is a good idea, then make each shell in the list
> Provide: almost-posix-shell (or something) and make almost-posix-shell
> essential (can a virtual package be essential?). Or make a real package
> almost-posix-shell that depends on bash | dash | ....
Russ, I'm CC'ing - please tell if you'd rather read the list.
I agree. Your suggestion solves this for all parties. The policy stays
intact, but the underlying dependencies need an improvement. The
problem I see in current situation is that
Packages' dependencies tend to be implicit. Sometimes it would
be more better to be explicit and not optimize dependencies away
with the assumption that a feature is provided by "essential".
In a way, Policy encourages view that listing explicit
dependencies is considered bad and wrong. On the contrary The
policy could encourage to make things transparent; this is good
testing and QA methodology. Policy should not care whether
package announces all dependencies or that some package
announces only those not covered in "essential".
The lack of explicit 'Depends:' is now shadowed byt the Policy which
does not require bash to be listed ... because it's in essential.
Your suggestion, that there should be something like:
Provides: standard-compliant-shell
in every shell packages that provide the standard (were it POSIX or
SusV) features expected in Debian. Even better, there should be a
test suite:
Package: standard-compliant-shell-test-suite
which could be used as measure to see which shells qualify the
"compliance"; whatever that would be.
A more simpler approach would be making /bin/dash the "test suite" and
suggesting developer's to test scripts under it. The dash could be
fixed to correct any non-standard features it might contain.
I'm not sure what's the deal with /bin/posh vs /bin/dash; but from
testing and QA perspective the more the marrier; if script passes
both, then it must be in good shape.
Jari
--
To UNSUBSCRIBE, email to debian-policy-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Bill Allombert 2006-11-23, 1:17 pm |
| On Thu, Nov 23, 2006 at 01:15:28AM +0200, Jari Aalto wrote:
> I would drop that "special" case and always require explicit
> requirement for the shell. It's more clear to see which packages
> "need" bash to make them work. someone may then provide a patch to
> "make bash go away". I suggest removing the last 2 lines:
Personnally I rather look forward for the day where the use of shells
for non-interactive task is deprecated in Debian.
Cheers,
--
Bill. <ballombe@debian.org>
Imagine a large blue swirl here.
--
To UNSUBSCRIBE, email to debian-policy-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Thomas Bushnell BSG 2006-11-23, 7:19 pm |
| On Thu, 2006-11-23 at 13:43 +0200, Jari Aalto wrote:
>
> Bash is not essential for running Debian. It is possible to run old
> PCs and old laptops completely free of bash. The point here is not the
> disk consumption, but the reduced memory constrainsts. When scripts
> are written with only "sh" in mind, they become portable to even
> embedded systems (think busybox). Every bash-dependent scipt that runs
> on the system, takes memory out from other processes.
What about "perl". Is that essential? Why are you not going for big
targets?
> Education sector and 3rd world still have PCs that are *years* and
> *tears* old. Everybody do not live in countries where computers or
> hardware are cheap.
Guess what? I used bash on that old hardware when it was shiny and new
also. Didn't seem to have any problems.
Thomas
| |
| David Weinehall 2006-11-23, 7:19 pm |
| On Thu, Nov 23, 2006 at 09:16:15AM -0800, Thomas Bushnell BSG wrote:
> On Thu, 2006-11-23 at 13:43 +0200, Jari Aalto wrote:
>
> What about "perl". Is that essential? Why are you not going for big
> targets?
>
> Guess what? I used bash on that old hardware when it was shiny and new
> also. Didn't seem to have any problems.
Somehow I doubt that you used today's version of bash (which I bet
is a lot bigger and more memory-consuming due to new features).
Regards: David
--
/) David Weinehall <tao@debian.org> /) Rime on my window (\
// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ // Diamond-white roses of fire //
\) http://www.acc.umu.se/~tao/ (/ Beautiful hoar-frost (/
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Jari Aalto 2006-11-23, 7:19 pm |
| Thomas Bushnell BSG <tb@becket.net> writes:
> On Thu, 2006-11-23 at 13:43 +0200, Jari Aalto wrote:
>
> What about "perl". Is that essential? Why are you not going for big
> targets?
I don't see PERL used that much for maintainer scripts, or daemon
scripts. As I explained in previous mails that there is no viable
alternative versions of Perl, like there are alternative versions of
shells.
Perl isn't likely to be included in embedded systems either.
>
> Guess what? I used bash on that old hardware when it was shiny and new
> also. Didn't seem to have any problems.
The issue is not having or experiencing problems or not. The issue is
portability and making things work in wider spectrum than bash. People
have personal preferences and it is possible to accomodate those.
Some prefer bash and see no problems. Others consider bash's memory
consumption a problem when compared to other alternatives.
Jari
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Steinar H. Gunderson 2006-11-23, 7:19 pm |
| On Thu, Nov 23, 2006 at 06:37:52PM +0100, David Weinehall wrote:
> Somehow I doubt that you used today's version of bash (which I bet
> is a lot bigger and more memory-consuming due to new features).
Comparing bash from woody and sid, respectively:
-rwxr-xr-x root/root 511400 2002-04-08 21:07 ./bin/bash
-rwxr-xr-x root/root 677184 2006-10-22 15:55 ./bin/bash
RSS of woody's bash is 4528 kB on my system; 4888 kB for sid's bash.
So, unless you want to claim that 162 kB bigger and using 8% more memory is
"a lot", you should probably be less careless about your betting.
/* Steinar */
--
Homepage: http://www.sesse.net/
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Martijn van Oosterhout 2006-11-23, 7:19 pm |
| On 23 Nov 2006 13:43:52 +0200, Jari Aalto <jari.aalto@cante.net> wrote:
> Bash is not essential for running Debian. It is possible to run old
> PCs and old laptops completely free of bash. The point here is not the
> disk consumption, but the reduced memory constrainsts. When scripts
> are written with only "sh" in mind, they become portable to even
> embedded systems (think busybox). Every bash-dependent scipt that runs
> on the system, takes memory out from other processes.
If disk-consumption is not the issue, the you don't need to uninstall
it, you just need to point the /bin/sh symlink somewhere else. Bash
can stay where it is and we don't have to have anyone declare
dependancies on it either.
If we want to mandate that maintainer scripts using /bin/sh should
also work with dash, then do that, but I don't think we need we need
to add complexity to the packaging system to deal with this.
> Education sector and 3rd world still have PCs that are *years* and
> *tears* old. Everybody do not live in countries where computers or
> hardware are cheap.
There's a difference between requiring maintainer scripts to say
/bin/bash if they need bash constructs and rewriting existing scripts
to work with some generic shell. The former is going to be *much*
easier. Isn't that enough?
Have a nice day,
--
Martijn van Oosterhout <kleptog@gmail.com> http://svana.org/kleptog/
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| David Weinehall 2006-11-23, 7:19 pm |
| On Thu, Nov 23, 2006 at 07:09:49PM +0100, Steinar H. Gunderson wrote:
> On Thu, Nov 23, 2006 at 06:37:52PM +0100, David Weinehall wrote:
>
> Comparing bash from woody and sid, respectively:
>
> -rwxr-xr-x root/root 511400 2002-04-08 21:07 ./bin/bash
> -rwxr-xr-x root/root 677184 2006-10-22 15:55 ./bin/bash
>
> RSS of woody's bash is 4528 kB on my system; 4888 kB for sid's bash.
>
> So, unless you want to claim that 162 kB bigger and using 8% more memory is
> "a lot", you should probably be less careless about your betting.
Most hardware that was nice and shiny back in 2002 wasn't exactly
underpowered, seeing as the Pentium 4 and Athlon Palomino was what was
used back then. So, I kind of doubt that the statement was concerning
Woody. Try Potato or Slink.
Oh, and 8% is quite a difference if you only have a limited amount to
begin with. It's not like bash is the only thing that's bloated since
then either.
On an embedded system, 162kB more storage or 360kB more RAM *is* a big
difference.
And compared to dash, the difference is vast:
-rwxr-xr-x 1 root root 80200 2006-11-21 16:36 /bin/dash
RSS for dash on sid seems to be 464kB. No woody to compare with.
Now the choice of 464kB or 4528kB on a desktop where you're actually
using the shell for interactive things is probably not a big deal,
personally I'd never use dash, posh, or busybox (except for rescue
purposes) on a desktop (or server, for that matter) other than for
scripts.
But for an embedded system, where the shell is only used for scripts
anyway, and for that matter, for scripts used on bootup (where speed
counts), any performance difference and every kB is gonna count.
On a machine with 64MB of RAM, a shell that takes 4.5MB of that is quite
a hog.
Regards: David
--
/) David Weinehall <tao@debian.org> /) Rime on my window (\
// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ // Diamond-white roses of fire //
\) http://www.acc.umu.se/~tao/ (/ Beautiful hoar-frost (/
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Bill Allombert 2006-11-23, 7:19 pm |
| On Thu, Nov 23, 2006 at 07:41:08PM +0100, David Weinehall wrote:
>
> And compared to dash, the difference is vast:
>
> -rwxr-xr-x 1 root root 80200 2006-11-21 16:36 /bin/dash
>
> RSS for dash on sid seems to be 464kB. No woody to compare with.
dash in woody was still called ash.
Cheers,
--
Bill. <ballombe@debian.org>
Imagine a large blue swirl here.
--
To UNSUBSCRIBE, email to debian-policy-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| David Weinehall 2006-11-23, 7:19 pm |
| On Thu, Nov 23, 2006 at 07:49:10PM +0100, Martijn van Oosterhout wrote:
[snip]
>
> There's a difference between requiring maintainer scripts to say
> /bin/bash if they need bash constructs and rewriting existing scripts
> to work with some generic shell. The former is going to be *much*
> easier. Isn't that enough?
If you just want to avoid things breaking, it's enough. If you want to
be able to use the scripts on an embedded platform, or to take advantage
of the performance boost of using dash instead of bash, it isn't.
Regards: David
--
/) David Weinehall <tao@debian.org> /) Rime on my window (\
// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ // Diamond-white roses of fire //
\) http://www.acc.umu.se/~tao/ (/ Beautiful hoar-frost (/
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| David Weinehall 2006-11-23, 7:19 pm |
| On Thu, Nov 23, 2006 at 07:54:46PM +0100, Bill Allombert wrote:
> On Thu, Nov 23, 2006 at 07:41:08PM +0100, David Weinehall wrote:
>
> dash in woody was still called ash.
What I meant was that I don't have a system running woody =)
Regards: David
--
/) David Weinehall <tao@debian.org> /) Rime on my window (\
// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ // Diamond-white roses of fire //
\) http://www.acc.umu.se/~tao/ (/ Beautiful hoar-frost (/
--
To UNSUBSCRIBE, email to debian-policy-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Thomas Bushnell BSG 2006-11-23, 7:19 pm |
| On Thu, 2006-11-23 at 20:07 +0100, David Weinehall wrote:
> On Thu, Nov 23, 2006 at 07:49:10PM +0100, Martijn van Oosterhout wrote:
> [snip]
>
> If you just want to avoid things breaking, it's enough. If you want to
> be able to use the scripts on an embedded platform, or to take advantage
> of the performance boost of using dash instead of bash, it isn't.
Debian does not support every need.
| |
| Thomas Bushnell BSG 2006-11-23, 7:19 pm |
| On Thu, 2006-11-23 at 13:50 +0200, Jari Aalto wrote:
> I'm not suggesting to remove features from essential, but I think the
> policy should take the shells as special case, because the
> sh-compliances (SusV/POSIX) itself is a matter of its own. There are
> no viable alternative implementation of PERL which is in essential, likewise
> for the rest.
Why should shells be a special case and all the other things mentioned
by SusV/POSIX are not? Why do we not want users to have the ability to
substitute a different ls, a different du, a different cp, a different
cat, a different grep?
Thomas
| |
| Thomas Bushnell BSG 2006-11-23, 7:19 pm |
| On Thu, 2006-11-23 at 19:33 +0200, Jari Aalto wrote:
> I don't see PERL used that much for maintainer scripts, or daemon
> scripts.
Exactly the *point*. So why isn't this your target?
> Some prefer bash and see no problems. Others consider bash's memory
> consumption a problem when compared to other alternatives.
The only alternative in Debian is dash, which explicitly says it's not a replacement:
"bash" is a better shell for most users, since it has some nice
features absent from "dash", and is a required part of the system.
Thomas
| |
| David Weinehall 2006-11-23, 7:19 pm |
| On Thu, Nov 23, 2006 at 11:23:23AM -0800, Thomas Bushnell BSG wrote:
> On Thu, 2006-11-23 at 13:50 +0200, Jari Aalto wrote:
>
> Why should shells be a special case and all the other things mentioned
> by SusV/POSIX are not? Why do we not want users to have the ability to
> substitute a different ls, a different du, a different cp, a different
> cat, a different grep?
Well, let's hope people don't use any of the non-SuSv3 features of cat
in their shell scripts... ls and du aren't used in scripts (normally),
and only "normal" features of cp are used in scripts. As for grep,
yes, it would be nice to be able to use busybox grep. Busybox grep
isn't fully SuSv3 compliant though, it lacks the -x option.
Personally I wouldn't mind limiting init-scripts and scripts that are
parts of essential to use only SuSv3 compliant features. I think
rewriting *all* scripts to use only SuSv3 features would be too big of
an ordeal, but just fixing the initscripts, plus all scripts in
essential should be doable.
Regards: David
--
/) David Weinehall <tao@debian.org> /) Rime on my window (\
// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ // Diamond-white roses of fire //
\) http://www.acc.umu.se/~tao/ (/ Beautiful hoar-frost (/
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Mike Hommey 2006-11-23, 7:19 pm |
| On Thu, Nov 23, 2006 at 04:42:45PM +0100, Bill Allombert <allomber@math.u-bordeaux.fr> wrote:
> On Thu, Nov 23, 2006 at 01:15:28AM +0200, Jari Aalto wrote:
>
> Personnally I rather look forward for the day where the use of shells
> for non-interactive task is deprecated in Debian.
What would you like instead ? PERL ? Python ?
Mike
--
To UNSUBSCRIBE, email to debian-policy-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Russ Allbery 2006-11-23, 7:19 pm |
| Jari Aalto <jari.aalto@cante.net> writes:
> Russ, I'm CC'ing - please tell if you'd rather read the list.
I read the list (both of them); no need to cc.
> I agree. Your suggestion solves this for all parties. The policy stays
> intact, but the underlying dependencies need an improvement. The problem
> I see in current situation is that
> Packages' dependencies tend to be implicit. Sometimes it would
> be more better to be explicit and not optimize dependencies away
> with the assumption that a feature is provided by "essential".
I think you've missed the point of Essential. Or maybe you're questioning
the point of Essential.
Anyway, either way, I think this is far afield from what I'm trying to
accomplish with this patch, so I'm going to ask that you put together a
separate proposal and pursue this separately rather than try to tackle any
of this as part of the sh policy. We can always remove the paranthetical
later; the larger changes that you're proposing are mostly in a different
Policy section.
To be frank, I don't think you're going to have a lot of luck. Basically,
you're trying to move bash into the same category as awk, where it's not
explicitly essential and can be handled by something akin to alternatives,
but given that this will require modifying all packages that use bash
explicitly and there's little incentive for maintainers to do this unless
it's made RC (and I have a hard time imagining that would happen), I don't
think the transition is likely to happen. It's a lot of work, and the
amount of gain doesn't seem to warrant it.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| David Weinehall 2006-11-23, 7:19 pm |
| On Thu, Nov 23, 2006 at 11:20:03AM -0800, Thomas Bushnell BSG wrote:
> On Thu, 2006-11-23 at 19:33 +0200, Jari Aalto wrote:
>
> Exactly the *point*. So why isn't this your target?
>
>
> The only alternative in Debian is dash, which explicitly says it's not a replacement:
>
> "bash" is a better shell for most users, since it has some nice
> features absent from "dash", and is a required part of the system.
dash is better for scripts (smaller memory footprint, faster), bash is
better for interactive use. Most users need a good interactive shell,
hence it's better for most users. That doesn't mean we should limit
ourselves to using bash for non-interactive use though.
Regards: David
--
/) David Weinehall <tao@debian.org> /) Rime on my window (\
// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ // Diamond-white roses of fire //
\) http://www.acc.umu.se/~tao/ (/ Beautiful hoar-frost (/
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Thomas Bushnell BSG 2006-11-23, 7:19 pm |
| On Thu, 2006-11-23 at 20:46 +0100, David Weinehall wrote:
> Well, let's hope people don't use any of the non-SuSv3 features of cat
> in their shell scripts...
Why? Who cares?
This is some huge amount of work for some very little benefit.
Thomas
| |
| David Weinehall 2006-11-23, 7:19 pm |
| On Thu, Nov 23, 2006 at 11:56:48AM -0800, Thomas Bushnell BSG wrote:
> On Thu, 2006-11-23 at 20:46 +0100, David Weinehall wrote:
>
> Why? Who cares?
Well, be honest. Have you ever used any options *at all* to cat in
your scripts?
> This is some huge amount of work for some very little benefit.
It's work that has to be done only once, and as long as people accept
patches, you don't even have to do it yourself, there's plenty of other
people willing to help.
Regards: David
--
/) David Weinehall <tao@debian.org> /) Rime on my window (\
// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ // Diamond-white roses of fire //
\) http://www.acc.umu.se/~tao/ (/ Beautiful hoar-frost (/
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Jari Aalto 2006-11-23, 7:19 pm |
| "Martijn van Oosterhout" <kleptog@gmail.com> writes:
> On 23 Nov 2006 13:43:52 +0200, Jari Aalto <jari.aalto@cante.net> wrote:
>
> There's a difference between requiring maintainer scripts to say
> /bin/bash if they need bash constructs and rewriting existing scripts
> to work with some generic shell. The former is going to be *much*
> easier. Isn't that enough?
My point. If there is explicit "Depends: bash", then someone can post
a patch to provide alternative solution to a person who may not know
alternative constructs (having learned only bashism).
Note, that I did not suggest rewriting any existing scripts, but I was
looking forward to making the need of bash more transparent that what
it is now in packages.
Jari
--
To UNSUBSCRIBE, email to debian-policy-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Jari Aalto 2006-11-23, 7:19 pm |
| Thomas Bushnell BSG <tb@becket.net> writes:
> On Thu, 2006-11-23 at 20:07 +0100, David Weinehall wrote:
>
> Debian does not support every need.
I think the spirit of Debian is to be versatile and going towards it
or improving it is the spirit of itself.
Jari
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Jari Aalto 2006-11-23, 7:19 pm |
| Thomas Bushnell BSG <tb@becket.net> writes:
> On Thu, 2006-11-23 at 20:46 +0100, David Weinehall wrote:
>
> Why? Who cares?
>
> This is some huge amount of work for some very little benefit.
Some of us do. If we're interested in putting manpower and effort on
it, it soudnät bother anyone who does not care.
Jari
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Jari Aalto 2006-11-23, 7:19 pm |
| David Weinehall <tao@debian.org> writes:
> On Thu, Nov 23, 2006 at 07:09:49PM +0100, Steinar H. Gunderson wrote:
>
> Now the choice of 464kB or 4528kB on a desktop where you're actually
> using the shell for interactive things is probably not a big deal,
> personally I'd never use dash, posh, or busybox (except for rescue
> purposes) on a desktop (or server, for that matter) other than for
> scripts.
Actually it is. In desktop (low memory PC; 64M or less), you open
several terminals to work efficiently. It's quite natural to have
10-20 open.
Count 20 x bash against some other alternative shell and the
consumed memory becomes apparent.
Jari
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Jari Aalto 2006-11-23, 7:19 pm |
| Russ Allbery <rra@debian.org> writes:
> Jari Aalto <jari.aalto@cante.net> writes:
>
> To be frank, I don't think you're going to have a lot of luck. Basically,
> you're trying to move bash into the same category as awk, where it's not
> explicitly essential and can be handled by something akin to alternatives,
> but given that this will require modifying all packages that use bash
> explicitly and there's little incentive for maintainers to do this unless
> it's made RC (and I have a hard time imagining that would happen), I don't
> think the transition is likely to happen. It's a lot of work, and the
> amount of gain doesn't seem to warrant it.
I must have explained poorly then.
- There is no need to make *any* changes to packages
- But it would be helpful if patches to make things transparent
were made acceptable.
The problem is that policy gives a leverage to the maintainers to
shrug their shoulders to anything that touches something belonging
Essential: "It's there so I don't care". And when the Policy text
alleviates that "packages provided by Essestial need not be
mentioned", that the final straw.
Now, I'm asking for thinking it another way around:
- It's all good to announce only dpendencies that are not in Essential
- BUT, it should be encouraged to list all dependencies even if
in essential.
This would change the whole mindset and expose package to full set of
dependencies if someone wants to do that. It sould also make it
possible to provide patches to the "Depends:".
.... and if someone cares anough, he could even start converting some
bashism to sh-only and send a patch. Encourageable practise again,
if policy were with it.
Jari
--
To UNSUBSCRIBE, email to debian-policy-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Jari Aalto 2006-11-23, 7:19 pm |
| Thomas Bushnell BSG <tb@becket.net> writes:
> On Thu, 2006-11-23 at 19:33 +0200, Jari Aalto wrote:
>
> Exactly the *point*. So why isn't this your target?
>
>
> The only alternative in Debian is dash, which explicitly says it's not a replacement:
>
> "bash" is a better shell for most users, since it has some nice
> features absent from "dash", and is a required part of the system.
This refers to inteactive use. dash suits well for scripts.
Jari
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Jari Aalto 2006-11-23, 7:19 pm |
| David Weinehall <tao@debian.org> writes:
> On Thu, Nov 23, 2006 at 11:20:03AM -0800, Thomas Bushnell BSG wrote:
>
> dash is better for scripts (smaller memory footprint, faster), bash is
> better for interactive use. Most users need a good interactive shell,
> hence it's better for most users. That doesn't mean we should limit
> ourselves to using bash for non-interactive use though.
Right. Here is data for "alternative" interactive shells. Also
available in graphical format.
E.g. *ksh shells like mksh are real replacements for bash in
interactive use in low memory systems.
Jari
Picture 17. Memory consumption of various shells.
http://debian.cante.net/stem/faq/#can_i_save_even_more
PROGRAMS: shells
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
30933 foo 16 0 1664 464 396 S 0.0 0.1 0:00.00 dash
[1.x - 1.14.6]
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
10011 foo 17 0 3348 1988 1132 S 0.0 0.6 0:00.14 bash1
[3.x - 3.1.14]
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
10229 foo 15 0 4692 1568 1260 S 0.0 0.5 0:00.33 bash
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
30781 foo 17 0 2372 996 744 S 0.0 0.3 0:00.01 esh
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1579 foo 16 0 3032 1112 900 S 0.0 0.3 0:00.01 ksh
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
32107 foo 16 0 1784 588 484 S 0.0 0.2 0:00.00 mksh
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1602 foo 17 0 1764 536 440 S 0.0 0.2 0:00.00 pdksh
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
30899 foo 16 0 1676 544 448 S 0.0 0.2 0:00.00 posh
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
31445 jaalto 17 0 6992 4928 2132 S 0.0 1.5 0:00.36 psh
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
31002 foo 15 0 808 204 164 S 0.0 0.1 0:00.00 sash
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
27122 foo 16 0 3800 2236 1596 S 0.0 0.7 0:00.14 zsh
--
To UNSUBSCRIBE, email to debian-policy-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Bruce Sass 2006-11-23, 7:19 pm |
| On Thu November 23 2006 13:56, Jari Aalto wrote:
> Thomas Bushnell BSG <tb@becket.net> writes:
>
> This refers to inteactive use. dash suits well for scripts.
Straddling the line somewhat is GIT. Installing dash to provide sh and
setting GIT_SHELL to /bin/sh results in a noticeable improvement on
even a 1GHz box.
- Bruce
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Hamish Moffatt 2006-11-23, 7:19 pm |
| On Thu, Nov 23, 2006 at 07:41:08PM +0100, David Weinehall wrote:
> Most hardware that was nice and shiny back in 2002 wasn't exactly
> underpowered, seeing as the Pentium 4 and Athlon Palomino was what was
> used back then. So, I kind of doubt that the statement was concerning
> Woody. Try Potato or Slink.
>
> Oh, and 8% is quite a difference if you only have a limited amount to
> begin with. It's not like bash is the only thing that's bloated since
> then either.
>
> On an embedded system, 162kB more storage or 360kB more RAM *is* a big
> difference.
[..]
> But for an embedded system, where the shell is only used for scripts
> anyway, and for that matter, for scripts used on bootup (where speed
> counts), any performance difference and every kB is gonna count.
>
> On a machine with 64MB of RAM, a shell that takes 4.5MB of that is quite
> a hog.
FWIW, we ran bash 1.14.6 in buzz on hardware which was much more
restricted than that. I think my first machine was a 40MHz 386 with 5Mb
or RAM or similar.
Jari's table says
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
30933 foo 16 0 1664 464 396 S 0.0 0.1 0:00.00 dash
[1.x - 1.14.6]
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
10011 foo 17 0 3348 1988 1132 S 0.0 0.6 0:00.14 bash1
[3.x - 3.1.14]
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
10229 foo 15 0 4692 1568 1260 S 0.0 0.5 0:00.33 bash
I don't remember it being terribly bad...
It would be interesting to have the above data on a whole buzz system
(as presumably the above is against sarge-era libraries.) Too bad you
can't debootstrap buzz 
Hamish
--
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Manoj Srivastava 2006-11-24, 1:31 am |
| On Thu, 23 Nov 2006 16:42:45 +0100, Bill Allombert <allomber@math.u-bordeaux.fr> said:
> On Thu, Nov 23, 2006 at 01:15:28AM +0200, Jari Aalto wrote:
[vbcol=seagreen]
> Personnally I rather look forward for the day where the use of
> shells for non-interactive task is deprecated in Debian.
That is the day I'll fork Debian :P. If Debian ever departs
so far from its UNIX roots, then it would be mostly useless windows
clone in my eyes.
manoj
--
"Hello again, Peabody here..." Mister Peabody
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-policy-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Manoj Srivastava 2006-11-24, 1:31 am |
| On 23 Nov 2006 01:15:28 +0200, Jari Aalto <jari.aalto@cante.net> said:
> I would drop that "special" case and always require explicit
> requirement for the shell. It's more clear to see which packages
> "need" bash to make them work. someone may then provide a patch to
> "make bash go away". I suggest removing the last 2 lines:
No, that is a separate discussion. Steve Langasek had an
email where he detailed reasons why one should not depend on
Essential packages; since it prevents moving the essential
functionality to other packages. And it is simple enough to see when
maintainer scripts explicitly use bash; that is far better than
making packages explicitly depend on Essential packages.
This is unlikely to change in the near term, unless there are
compelling arguments to make the dependency explicit (like there is
if a package has a versioned dependency on an Essential
package. Merely makes it easy to see which packages on th4e off
chance that someone manages to make bash go away at some time in the
improbable and remote future is not going to cut the mustard.
> In a way, Policy encourages view that listing explicit
> dependencies is considered bad and wrong. On the contrary The
This is exactly right.
> policy could encourage to make things transparent; this is
> good testing and QA methodology. Policy should not care
> whether package announces all dependencies or that some
> package announces only those not covered in "essential".
I don't think that adding a clutter of Essential packages to
the list of every single package out there adds transparency; it is
clutter, it is redundant; and good QA practice is to abstract away
the common dependency set and make it tacit.
manoj
--
It may be that your whole purpose in life is simply to serve as a
warning to others.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Russ Allbery 2006-11-24, 1:31 am |
| Jari Aalto <jari.aalto@cante.net> writes:
> Russ Allbery <rra@debian.org> writes:
[vbcol=seagreen]
> I must have explained poorly then.
> - There is no need to make *any* changes to packages
You proposed a wording change to Policy making adding a dependency to bash
mandatory for packages that use bash. That requires making changes to
*lots* of packages.
Maybe you meant to propose a change that just made it *optional* to add a
dependency on bash?
> The problem is that policy gives a leverage to the maintainers to shrug
> their shoulders to anything that touches something belonging Essential:
> "It's there so I don't care". And when the Policy text alleviates that
> "packages provided by Essestial need not be mentioned", that the final
> straw.
Right, that's much of the point of Essential. You've seen the Policy
footnote, I presume?
Essential is defined as the minimal set of functionality that must be
available and usable on the system even when packages are in an
unconfigured (but unpacked) state. This is needed to avoid
unresolvable dependency loops on upgrade. If packages add unnecessary
dependencies on packages in this set, the chances that there will be
an unresolvable dependency loop caused by forcing these Essential
packages to be configured first before they need to be is greatly
increased. It also increases the chances that frontends will be unable
to calculate an upgrade path, even if one exists.
Also, it's pretty unlikely that functionality from Essential shall
ever be removed (which is one reason why care must be taken before
adding to the Essential packages set), but packages have been removed
from the Essential set when the functionality moved to a different
package. So depending on these packages just in case they stop being
essential does way more harm than good.
That's a pretty strong argument against doing what you're proposing in
general. I think a lot of justification is required to change this.
> Now, I'm asking for thinking it another way around:
> - It's all good to announce only dpendencies that are not in Essential
> - BUT, it should be encouraged to list all dependencies even if
> in essential.
I'm opposed to doing this for the reasons spelled out in Policy. I think
it adds a bunch of additional work and causes problems for dependency
resolution with no significant benefit.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Ganesan Rajagopal 2006-11-24, 1:31 am |
| >>>>> Manoj Srivastava <srivasta@debian.org> writes:
> On Thu, 23 Nov 2006 16:42:45 +0100, Bill Allombert <allomber@math.u-bordeaux.fr> said:
[vbcol=seagreen]
[vbcol=seagreen]
> That is the day I'll fork Debian :P. If Debian ever departs
> so far from its UNIX roots, then it would be mostly useless windows
> clone in my eyes.
I think you misunderstood. The keyword is "non-interactive", as in replacing
shell scripts with Perl/Python/Whatever. FWIW, I disagree with Bill. I do
find myself rewriting many of shell scripts with Python when they get
bigger. However, for simple stuff like stringing together a few shell
commands, nothing beats the shell.
Ganesan
--
Ganesan Rajagopal
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Jari Aalto 2006-11-24, 1:31 am |
| Russ Allbery <rra@debian.org> writes:
> Jari Aalto <jari.aalto@cante.net> writes:
>
>
>
>
> You proposed a wording change to Policy making adding a dependency to bash
> mandatory for packages that use bash. That requires making changes to
> *lots* of packages.
>
> Maybe you meant to propose a change that just made it *optional* to add a
> dependency on bash?
Correct.
>
> Right, that's much of the point of Essential. You've seen the Policy
> footnote, I presume?
>
> Essential is defined as the minimal set of functionality that must be
> available and usable on the system even when packages are in an
> unconfigured (but unpacked) state.
And making bash essential on the gounds that "must be available" is
not a good idea. I guess this is a chicken and egg situation
I'd rather make it read:
> Essential represents the minimal set of functionality that are
> available on a system even when packages are in an
> unconfigured (but unpacked) state.
> This is needed to avoid
> unresolvable dependency loops on upgrade. If packages add unnecessary
> dependencies on packages in this set, the chances that there will be
> an unresolvable dependency loop caused by forcing these Essential
> packages to be configured first before they need to be is greatly
> increased. It also increases the chances that frontends will be unable
> to calculate an upgrade path, even if one exists.
>
> Also, it's pretty unlikely that functionality from Essential shall
> ever be removed (which is one reason why care must be taken before
> adding to the Essential packages set), but packages have been removed
> from the Essential set when the functionality moved to a different
> package. So depending on these packages just in case they stop being
> essential does way more harm than good.
>
> That's a pretty strong argument against doing what you're proposing in
> general. I think a lot of justification is required to change this.
>
>
>
> I'm opposed to doing this for the reasons spelled out in Policy. I think
> it adds a bunch of additional work and causes problems for dependency
> resolution with no significant benefit.
I think the policy should be implementation agnostic. What is referred
here is tying it to the dependency resolution algorithm that is true at a
particular time. I'm quite sure that the install case can be
made to skip any package that is mentioned in the "Depends: " that is
in the the list of Essential. Like:
Depends: bash, .....
=> Algorithm:
Hm, bash is in the list of essential-packages.lst, drop it and
resolve only other packages mentioned in Depends:
Listing the packages in the Depends should not necessarily cause any
more work to the tools. I'm sure patches can me made to correct the
tools.
Jari
--
To UNSUBSCRIBE, email to debian-policy-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Thomas Bushnell BSG 2006-11-24, 1:22 pm |
| On Thu, 2006-11-23 at 22:56 +0200, Jari Aalto wrote:
> Thomas Bushnell BSG <tb@becket.net> writes:
>
>
> This refers to inteactive use. dash suits well for scripts.
You miss the point. If there is any interactive use at all, then bash
needs to be on the system. Embedded systems are nifty, but they are not
an issue for Debian.
Thomas
| |
| Thomas Bushnell BSG 2006-11-24, 1:22 pm |
| On Thu, 2006-11-23 at 22:54 +0200, Jari Aalto wrote:
> David Weinehall <tao@debian.org> writes:
>
>
> Actually it is. In desktop (low memory PC; 64M or less), you open
> several terminals to work efficiently. It's quite natural to have
> 10-20 open.
>
> Count 20 x bash against some other alternative shell and the
> consumed memory becomes apparent.
Somebody needs to explain to Jari the concept of a shared text segment.
Thomas
| |
| David Weinehall 2006-11-24, 7:19 pm |
| On Fri, Nov 24, 2006 at 11:10:19AM -0800, Thomas Bushnell BSG wrote:
> On Thu, 2006-11-23 at 22:56 +0200, Jari Aalto wrote:
>
> You miss the point. If there is any interactive use at all, then bash
> needs to be on the system. Embedded systems are nifty, but they are not
> an issue for Debian.
You miss the point too... dash is suitable scripts, and any Linux
machine, embedded or not, runs lots of scripts. dash runs those scripts
faster. To be able to run those scripts at all, it needs the scripts to
be free from bashisms.
You can use whatever bashisms you like when you're working
interactively, that won't hinder dash from executing shells on boot and
elsewhere. Using bashisms in scripts does however cause a problem.
Oh, and there *are* other suitable interactive shells than bash. tcsh,
ksh, zsh, rc... Whether any of these actually consume less memory than
bash, I cannot say, since I'm a bash user myself on the desktop. Yet
all the scripts I write run perfectly well (and faster) in dash.
Regards: David
--
/) David Weinehall <tao@debian.org> /) Rime on my window (\
// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ // Diamond-white roses of fire //
\) http://www.acc.umu.se/~tao/ (/ Beautiful hoar-frost (/
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Thomas Bushnell BSG 2006-11-24, 7:19 pm |
| On Fri, 2006-11-24 at 21:08 +0100, David Weinehall wrote:
> You can use whatever bashisms you like when you're working
> interactively, that won't hinder dash from executing shells on boot and
> elsewhere. Using bashisms in scripts does however cause a problem.
I think it's time to realize that "bash" specifies a programming
language, and so does "dash".
Instead of focusing and hammering again and again on /bin/sh, why not
instead ask maintainers to do #!/bin/dash?
> Oh, and there *are* other suitable interactive shells than bash. tcsh,
> ksh, zsh, rc... Whether any of these actually consume less memory than
> bash, I cannot say, since I'm a bash user myself on the desktop. Yet
> all the scripts I write run perfectly well (and faster) in dash.
I said that dash was not a substitute for bash, by its own claim. This
is like a game of whackamole. If the claim is made that dash involves
less disk space or memory use, it's nearly irrelevant, because bash will
be there anyway.
There may well be advantages to dash for this or that application. So
then, maintainers should be encouraged to use it. The best way, of
course, is #!/bin/dash.
Thomas
| |
| Bruce Sass 2006-11-24, 7:19 pm |
| On Fri November 24 2006 13:15, Thomas Bushnell BSG wrote:
> Instead of focusing and hammering again and again on /bin/sh, why not
> instead ask maintainers to do #!/bin/dash?
because bash offers a larger superset of sh features than dash, and "sh"
is a standard part of System V-like unix systems like Linux
> There may well be advantages to dash for this or that application.
> So then, maintainers should be encouraged to use it. The best way,
> of course, is #!/bin/dash.
and stop using "sh" altogether, or should the www.emdebian.org people
fork the entire distribution?
- Bruce
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Thomas Bushnell BSG 2006-11-24, 7:19 pm |
| On Fri, 2006-11-24 at 14:03 -0700, Bruce Sass wrote:
> On Fri November 24 2006 13:15, Thomas Bushnell BSG wrote:
>
> because bash offers a larger superset of sh features than dash, and "sh"
> is a standard part of System V-like unix systems like Linux
But #!/bin/sh scripts aren't allowed to use those. What I'm saying is
that the energy spent on making rules about #!/bin/sh would be better
spent encouraging people to simply switch--when appropriate--to
#!/bin/dash.
>
> and stop using "sh" altogether, or should the www.emdebian.org people
> fork the entire distribution?
What I said was that *if* it is better for a given script to run with
dash than with bash, the maintainer should be encouraged to say
#!/bin/dash.
I don't think it's my job to start saying what *other* distributions,
which are not Debian, should do.
Thomas
| |
| Jari Aalto 2006-11-24, 7:19 pm |
| Thomas Bushnell BSG <tb@becket.net> writes:
> On Fri, 2006-11-24 at 21:08 +0100, David Weinehall wrote:
>
> I think it's time to realize that "bash" specifies a programming
> language, and so does "dash".
>
> Instead of focusing and hammering again and again on /bin/sh, why not
> instead ask maintainers to do #!/bin/dash?
Because the correct is #!/bin/sh and not to be tied on particular shell.
>
> I said that dash was not a substitute for bash, by its own claim. This
> is like a game of whackamole. If the claim is made that dash involves
> less disk space or memory use, it's nearly irrelevant, because bash will
> be there anyway.
Bash is not there "nayway". It is posisble to substitute it for the
reasons explained (memory consumption), without any significant loss of
interactive functionality.
> There may well be advantages to dash for this or that application. So
> then, maintainers should be encouraged to use it. The best way, of
> course, is #!/bin/dash.
The point was making script sh-agnostic. dash is just an
implementation of sh. Someone may very well use busybox or /bin/posh.
Jari
--
To UNSUBSCRIBE, email to debian-policy-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Thomas Bushnell BSG 2006-11-24, 7:19 pm |
| On Fri, 2006-11-24 at 23:55 +0200, Jari Aalto wrote:
>
> Because the correct is #!/bin/sh and not to be tied on particular shell.
I can't tell what you mean. There is nothing wrong with using
#!/bin/dash if that's what the maintainer wants to specify.
> Bash is not there "nayway". It is posisble to substitute it for the
> reasons explained (memory consumption), without any significant loss of
> interactive functionality.
And around and around we go. Dash itself say it is not suitable for
interactive use, and, bash is an Essential part of Debian.
>
> The point was making script sh-agnostic. dash is just an
> implementation of sh. Someone may very well use busybox or /bin/posh.
Sure, if the maintainer thinks one of those is best, they could be used
too.
Thomas
| |
| Bruce Sass 2006-11-24, 7:19 pm |
| On Fri November 24 2006 14:42, Thomas Bushnell BSG wrote:
> On Fri, 2006-11-24 at 14:03 -0700, Bruce Sass wrote:
>
> But #!/bin/sh scripts aren't allowed to use those. What I'm saying
> is that the energy spent on making rules about #!/bin/sh would be
> better spent encouraging people to simply switch--when
> appropriate--to #!/bin/dash.
If someone uses dash features not included in, both, the spec for "sh"
and other Bourne shells allowed to become "sh", they should use
#!/bin/dash. IMO. bash is in the same boat.
>
> What I said was that *if* it is better for a given script to run with
> dash than with bash, the maintainer should be encouraged to say
> #!/bin/dash.
Sure, but since all "sh" scripts would be better off if they specified
dash as their command interpreter... #!/bin/sh use would disappear.
> I don't think it's my job to start saying what *other* distributions,
> which are not Debian, should do.
but it is Debian's job to be responsive to its users needs and Debian
has made a choice to strive for susv3 compatibility
- Bruce
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Jari Aalto 2006-11-24, 7:19 pm |
| Thomas Bushnell BSG <tb@becket.net> writes:
> On Thu, 2006-11-23 at 22:54 +0200, Jari Aalto wrote:
>
> Somebody needs to explain to Jari the concept of a shared text segment.
And why do you think that? please take a look at the RES values.
Jari
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Thomas Bushnell BSG 2006-11-24, 7:19 pm |
| On Fri, 2006-11-24 at 23:57 +0200, Jari Aalto wrote:
> And why do you think that? please take a look at the RES values.
I know you don't understand it, because you just appealed to the RSS
values.
If many processes are sharing text, they all get accounted with the size
of the resident text in their RSS, but they are sharing the segment;
they are not each getting their own copy.
Thomas
| |
| Thomas Bushnell BSG 2006-11-24, 7:19 pm |
| On Fri, 2006-11-24 at 15:12 -0700, Bruce Sass wrote:
> Sure, but since all "sh" scripts would be better off if they specified
> dash as their command interpreter... #!/bin/sh use would disappear.
So?
>
> but it is Debian's job to be responsive to its users needs and Debian
> has made a choice to strive for susv3 compatibility
I don't think you understand what "compatibility" means in this context.
It does not mean that you can substitute any component of the system
with a different standards-compliant version and everything must
continue to work.
Our users needs do not, by and large, include embedded systems.
Thomas
| |
| Bruce Sass 2006-11-25, 1:31 am |
| On Fri November 24 2006 15:24, Thomas Bushnell BSG wrote:
> On Fri, 2006-11-24 at 15:12 -0700, Bruce Sass wrote:
>
> So?
Just pointing out that encouraging #!/bin/dash instead of #!/bin/sh when
a script would be better off with a lighter shell than bash results in
the demise of #!/bin/sh.
>
> I don't think you understand what "compatibility" means in this
> context. It does not mean that you can substitute any component of
> the system with a different standards-compliant version and
> everything must continue to work.
So, what does "compatibility" mean in this context?
> Our users needs do not, by and large, include embedded systems.
I am glad that "by and large" is not the standard, for that would make
Debian somewhat less universal than it is.
- Bruce
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Hubert Chan 2006-11-25, 1:31 am |
| On 23 Nov 2006 22:40:01 +0200, Jari Aalto <jari.aalto@cante.net> said:
> My point. If there is explicit "Depends: bash", then someone can post
> a patch to provide alternative solution to a person who may not know
> alternative constructs (having learned only bashism).
Sorry, but I don't understand what you're trying to do here. Can you
please explain what dependencies have to do with wishlist bugreports?
--
Hubert Chan <uhoreg@debian.org> -- Jabber: hubert@uhoreg.ca
PGP/GnuPG key: 1024D/124B61FA http://www.uhoreg.ca/
Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Thomas Bushnell BSG 2006-11-25, 1:31 am |
| On Fri, 2006-11-24 at 16:28 -0700, Bruce Sass wrote:
>
> So, what does "compatibility" mean in this context?
Debian has *achieved* susv3 compatibility. There is nothing more to be
done.
A compatible implementation is allowed to have special options "behind
the scenes" which it uses to implement things. Compatibility (actually,
I believe the term is compliance) refers to the entire system, not its
individual components.
>
>
> I am glad that "by and large" is not the standard, for that would make
> Debian somewhat less universal than it is.
*Yawn*.
I don't care about making a distribution suitable for every possible
purpose. I see no shame in saying that we are suitable for some
purposes and not others.
Thomas
| |
| Anthony DeRobertis 2006-11-25, 7:22 am |
| Thomas Bushnell BSG wrote:
> Somebody needs to explain to Jari the concept of a shared text segment.
>
Bash:
anthony@Feynman:~$ grep 'Private_Dirty' /proc/$$/smaps | PERL -e '$t = 0; while (<> ) { /(\d+) kB$/ or die "parse err: $_"; $t += $1 } print "tot: $t\n"'
tot: 2800
Dash:
$ grep 'Private_Dirty' /proc/$$/smaps | PERL -e '$t = 0; while (<> ) { /(\d+) kB$/ or die "parse err: $_"; $t += $1 } print "tot: $t\n"'
tot: 84
Indeed, checking /proc/pid/status, we find bash's VmData is a mere 16
times larger than dash's.
Something tells me that 2.8MB * 20 could indeed be a problem on a 64MB
system.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Jari Aalto 2006-11-25, 7:22 am |
| Thomas Bushnell BSG <tb@becket.net> writes:
> On Fri, 2006-11-24 at 16:28 -0700, Bruce Sass wrote:
>
> Debian has *achieved* susv3 compatibility. There is nothing more to be
> done.
>
> A compatible implementation is allowed to have special options "behind
> the scenes" which it uses to implement things. Compatibility (actually,
> I believe the term is compliance) refers to the entire system, not its
> individual components.
>
> *Yawn*.
>
> I don't care about making a distribution suitable for every possible
> purpose. I see no shame in saying that we are suitable for some
> purposes and not others.
You don't have to care. There are people who do. Let them do the work.
That's how the Debian can come where it is now. It compiles in systems
where none other distro does because people have cared to make porting
work.
Porting from bash to dash to towards generic sh-SusV compliance is
similar work. We could even talk about "standards-compliant" init
scripts
I'm sure you're not against work towards overall generalism. You
should not care if someone puts effort on it. Any work of this kind
should be highly encouraged and not discouraged.
Jari
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Jari Aalto 2006-11-25, 7:22 am |
| Thomas Bushnell BSG <tb@becket.net> writes:
> On Fri, 2006-11-24 at 23:55 +0200, Jari Aalto wrote:
>
> I can't tell what you mean. There is nothing wrong with using
> #!/bin/dash if that's what the maintainer wants to specify.
And if the system does not have dash installed? And if the scrpts work
fine with the /bin/sh of his choice?
Hard coding is always been bad.
>
> And around and around we go. Dash itself say it is not suitable for
> interactive use, and, bash is an Essential part of Debian.
>
> Sure, if the maintainer thinks one of those is best, they could be used
> too.
And this is only possible if scripts use
/bin/sh
The /bin/sh could be any valid shell that provided the standard set
of features.
The installation system ("Essential") which sets /bin/sh to point to
/bin/bash in this respect has been a bad choice because people are not
aware of the bashinm they might be using as a result of it.
Jari
--
To UNSUBSCRIBE, email to debian-policy-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Jari Aalto 2006-11-25, 7:22 am |
| Hubert Chan <uhoreg@debian.org> writes:
> On 23 Nov 2006 22:40:01 +0200, Jari Aalto <jari.aalto@cante.net> said:
>
>
> Sorry, but I don't understand what you're trying to do here. Can you
> please explain what dependencies have to do with wishlist bugreports?
"Depends:" make dependency visible, whereas filing a wishlist is
usually result of someone by accident finding the script to include
bashism. He may offer a patch to convert those constructs to standard
sh-way-of-doing-things.
It's easier to eyeball packages that explicitly announce "bash".
Those could be put to a stress test through:
/bin/dash
/bin/posh
...
If someone feels up to.
Jari
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| David Weinehall 2006-11-25, 7:22 am |
| On Sat, Nov 25, 2006 at 10:02:14AM +0200, Jari Aalto wrote:
> Hubert Chan <uhoreg@debian.org> writes:
>
>
> "Depends:" make dependency visible, whereas filing a wishlist is
> usually result of someone by accident finding the script to include
> bashism. He may offer a patch to convert those constructs to standard
> sh-way-of-doing-things.
>
> It's easier to eyeball packages that explicitly announce "bash".
> Those could be put to a stress test through:
>
> /bin/dash
> /bin/posh
> ...
>
> If someone feels up to.
I don't really see the point. If the maintainer knows the package
contains bashisms, he might just as well fix them instead.
Regards: David
--
/) David Weinehall <tao@debian.org> /) Rime on my window (\
// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ // Diamond-white roses of fire //
\) http://www.acc.umu.se/~tao/ (/ Beautiful hoar-frost (/
--
To UNSUBSCRIBE, email to debian-policy-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Mike Hommey 2006-11-25, 7:22 am |
| On Sat, Nov 25, 2006 at 09:51:37AM +0200, Jari Aalto <jari.aalto@cante.net> wrote:
> And this is only possible if scripts use
>
> /bin/sh
>
> The /bin/sh could be any valid shell that provided the standard set
> of features.
>
> The installation system ("Essential") which sets /bin/sh to point to
> /bin/bash in this respect has been a bad choice because people are not
> aware of the bashinm they might be using as a result of it.
Maybe bash should restrict its features when called sh... like gzip
changes its features when called gunzip, etc.
Mike
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Petter Reinholdtsen 2006-11-25, 7:22 am |
|
[Thomas Bushnell]
> I'm interested in why we should care at all. PERL is a far bigger space
> hog than bash.
Debian Edu had to switch /bin/sh from bash to dash to get shutdown to
umount /usr/ when we use libnss-ldap (bug #159771). Bash loads user
information using nss when it starts, and thus loads the shared ldap
library from /usr/ on invocation. This make it unusable in a system
with LDAP users.
Switching to dash as /bin/sh gave us a nice surprise with reduced
memory consumption and faster boots as well, but that was not the
reason why we switched.
Friendly,
--
Petter Reinholdtsen
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Stephen Gran 2006-11-25, 1:16 pm |
| This one time, at band camp, Jari Aalto said:< | | |