On Thu, 16 Oct 2014 15:49:29 +0200, m...@linux.it (Marco d'Itri) wrote:
On Oct 16, Thorsten Glaser t...@mirbsd.de wrote:
| If one of the members of the tech ctte considers that we should
| either overwrite the udev-maintainer or move printf to /bin, we
The coreutils maintainer may still
On Sun, 2014-10-19 at 11:48 +0200, Marc Haber wrote:
On Thu, 16 Oct 2014 15:49:29 +0200, m...@linux.it (Marco d'Itri) wrote:
On Oct 16, Thorsten Glaser t...@mirbsd.de wrote:
| If one of the members of the tech ctte considers that we should
| either overwrite the udev-maintainer or move
On Oct 19, Marc Haber mh+debian-de...@zugschlus.de wrote:
Ah. That explains your plans. Making life with a split-off /usr as
hard as possible to that people migrate to /usr on / because of the
artificially caused pain.
No, my evil plan is to use mind control to force people to migrate / in
On Wed, 15 Oct 2014, Ian Jackson wrote:
Actually, the problem is indeed in policy. In its resolution of
#539158 the TC decided unanimously (but unfortunately slightly
implicitly) that printf ought to be provided by our /bin/sh.
Somewhat.
As the maintainer of a minority shell, Thorsten has
On Wed, 2014-10-15 at 23:36 +0100, Ian Jackson wrote:
Actually, the problem is indeed in policy. In its resolution of
#539158 the TC decided unanimously (but unfortunately slightly
implicitly) that printf ought to be provided by our /bin/sh.
Unfortunately the policy has not been properly
Thorsten Glaser writes (Re: bash exorcism experiment ('bug' 762923 763012)):
I’d rather prefer to see this resolved by getting #428189 fixed.
Clearly you would, but #428189 (moving coreutils printf to /bin) was
also implicitly rejected by the TC in its decision on #539158. The
question
On Thu, 16 Oct 2014, Ian Jackson wrote:
| If one of the members of the tech ctte considers that we should
| either overwrite the udev-maintainer or move printf to /bin, we
The coreutils maintainer may still decide to do just that.
That’s what would help the most.
bye,
//mirabilos
--
Yes, I
On Oct 16, Thorsten Glaser t...@mirbsd.de wrote:
| If one of the members of the tech ctte considers that we should
| either overwrite the udev-maintainer or move printf to /bin, we
The coreutils maintainer may still decide to do just that.
That’s what would help the most.
In a few years,
On Mon, Oct 13, 2014 at 10:43:08AM +0200, Marco d'Itri wrote:
On Oct 13, Matthias Urlichs matth...@urlichs.de wrote:
Policy effectively states that Debian packages shall not depend on any
features which posh doesn't have.
So in what way is that a bad idea, and how should one know
On Sun, Oct 12, 2014 at 10:05:20PM +0200, Florian Weimer wrote:
If you need array variables, it's likely that the script has grown so
complex that switching to another language is a good idea.
/etc/init.d/nbd-client
It's not exactly *needed*; I could replace it with a set of eval
instructions.
On Oct 15, Wouter Verhelst wou...@debian.org wrote:
If you target posh, you target all shells that policy allows for --
including those that are smaller and/or faster than dash.
Can you list some, and what benefits they would bring over dash?
--
ciao,
Marco
signature.asc
Description:
On Mon, 13 Oct 2014, Stephane Chazelas wrote:
$*, $@, $* were not special in any way. They just underwent
the same rules as other variables. Only $@ was.
This changed in POSIX sh though. I remember having
to change some things in mksh to adhere to 2008 and
post-2008.
bye,
//mirabilos
--
On Wed, Oct 15, 2014 at 10:10:00AM +0200, Marco d'Itri wrote:
On Oct 15, Wouter Verhelst wou...@debian.org wrote:
If you target posh, you target all shells that policy allows for --
including those that are smaller and/or faster than dash.
Can you list some, and what benefits they would
Wouter Verhelst writes (Re: bash exorcism experiment ('bug' 762923 763012)):
But that's *also* not the point. The point is that we have a policy
which states particular things, and that you should follow that policy.
If you think policy is wrong, you're welcome to change it; doing so
really
]] Thorsten Glaser
Stephane Chazelas dixit:
[ a lot, with which I vehemently disagree ]
If you need arrays, use $@ or use perl/python/ruby..., but
please don't break yet another shell with the Korn arrays or
arithmetics.
The good part about mksh i̲s̲ that it’s a programming language,
Hi,
Marco d'Itri:
On Oct 11, Theodore Ts'o ty...@mit.edu wrote:
but if a user
wants to use /bin/posh, that's an individual user's choice :-)
We have no obligation to support every bad idea that people have.
Policy effectively states that Debian packages shall not depend on any
features
On Oct 13, Matthias Urlichs matth...@urlichs.de wrote:
Policy effectively states that Debian packages shall not depend on any
features which posh doesn't have.
So in what way is that a bad idea, and how should one know beforehand?
That there is no reason to waste time targeting posh, which is
On Sat, 11 Oct 2014, Theodore Ts'o wrote:
I assume that posh meets the strict definition of 10.4. And so
without actually changing policy, someone _could_ try setting /bin/sh
to be /bin/posh, and then start filing RC bugs against packages that
have scripts that break. Yes?
Yes, modulo two
On Mon, 13 Oct 2014, Dominik George wrote:
foo='x[$(rm -rf /)]'
echo $(( foo ))
Guess when the array index is evaluated? Now mind that it could be
This is fully and completely a user error. (User being the script.)
user-provided.
Never put “tainted” input into ksh arithmetics, period.
Theodore Ts'o writes (Re: bash exorcism experiment ('bug' 762923 763012)):
I assume that posh meets the strict definition of 10.4. And so
without actually changing policy, someone _could_ try setting /bin/sh
to be /bin/posh, and then start filing RC bugs against packages that
have scripts
2014-10-07 15:03:05 +0200, Thorsten Glaser:
On Sat, 4 Oct 2014, Russ Allbery wrote:
If we were to decide that #309415 should be fixed in policy (and hence
posh), then it should be done by requiring support for the obsolescent
The problems with posh and dash are also the sheer number of
2014-10-13 12:21:33 +0200, Thorsten Glaser:
On Mon, 13 Oct 2014, Dominik George wrote:
foo='x[$(rm -rf /)]'
echo $(( foo ))
Guess when the array index is evaluated? Now mind that it could be
This is fully and completely a user error. (User being the script.)
user-provided.
Stephane Chazelas dixit:
[ a lot, with which I vehemently disagree ]
If you need arrays, use $@ or use perl/python/ruby..., but
please don't break yet another shell with the Korn arrays or
arithmetics.
The good part about mksh i̲s̲ that it’s a programming language,
a nice one to use, much more
2014-09-29 09:22:58 +1000, Russell Stuart:
On Sun, 2014-09-28 at 16:47 +0200, Guillem Jover wrote:
I've attempted to port the many shell scripts I've written over the
years to dash. The three irritants are:
- pipefail,
http://cfajohnson.com/shell/cus-faq-2.html#Q11.
That's
2014-10-02 10:06:50 -0400, shawn wilson:
[...]
I hate the idea of dash. It's not more secure (see vmware cve for an
example) and I think it was more of an accident than anything else this
didn't hit dash too.
[...]
That CVE is not about a bug in dash. There are a few
misconceptions around that
* Russell Stuart:
- array variables.
Array variables practically imply arithmetic evaluation, amd this is a
shell feature which is rather difficult to use correctly because
compatibility with other shell encourages both recursive evaluation
and access to the full shell language in a few
On Oct 11, Theodore Ts'o ty...@mit.edu wrote:
But if individual Debian developers were to fix their own packages, or
suggest patches as non-RC bugs, there wouldn't be any real harm, and
possibly some good (especially for those people who are very much into
pedantry, and don't mind a slightly
Hi Florian,
On Sonntag, 12. Oktober 2014, Florian Weimer wrote:
Array variables practically imply arithmetic evaluation, amd this is a
shell feature which is rather difficult to use correctly because
compatibility with other shell encourages both recursive evaluation
and access to the full
On Sun, 2014-10-12 at 22:05 +0200, Florian Weimer wrote:
Array variables practically imply arithmetic evaluation, amd this is a
shell feature which is rather difficult to use correctly because
compatibility with other shell encourages both recursive evaluation
and access to the full shell
Array variables practically imply arithmetic evaluation, amd this is
a
shell feature which is rather difficult to use correctly because
compatibility with other shell encourages both recursive evaluation
and access to the full shell language in a few corners.
I think the idea here was not use
On Mon, 2014-10-13 at 06:23 +0200, Dominik George wrote:
foo='x[$(rm -rf /)]'
echo $(( foo ))
Guess when the array index is evaluated? Now mind that it could be
user-provided.
In dash it isn't executed which means on Debian at least it's most
harmless. That's another bouquet for dash.
Russell Stuart russell-deb...@stuart.id.au writes:
Not really. I'm about documentation reflecting reality. Think of
putting an electrical component whose documentation says its 200 degrees
on a motherboard, only to find it fails at 190. When you ask why, is
well we design it for 200, but
On Sat, Oct 11, 2014 at 10:37:26AM -0700, Russ Allbery wrote:
You have convinced me that in this case it's going to have to be that
way, so my prejudices notwithstanding. I've rationalised the pain away
by deciding it's no so bad as any competent programmer could see that is
it only
On Fri, 2014-10-03 at 09:20 -0700, Russ Allbery wrote:
Russell Stuart russell-deb...@stuart.id.au writes:
I looks to me like you are re-writing history.
I'm not sure how you meant this, but to note, this sentence made me very
sad, since it felt like you believe I'm being intentionally
On Sat, 4 Oct 2014, Russ Allbery wrote:
If we were to decide that #309415 should be fixed in policy (and hence
posh), then it should be done by requiring support for the obsolescent
The problems with posh and dash are also the sheer number of bugs
in corner cases, which the more actively
On Tue, Oct 07, 2014 at 03:03:05PM +0200, Thorsten Glaser wrote:
Yeah, but Md is an arsehole anyway and requires printf to be
a /bin/sh builtin instead of just adding /usr/bin to $PATH,
especially now that the initrd mounts /usr already anyway,
and CTTE decided to rather offend me than Md
On 10/07/2014 at 02:39 AM, Russell Stuart wrote:
On Fri, 2014-10-03 at 09:20 -0700, Russ Allbery wrote:
Oh! I didn't realize or internalize that you were proposing
switching the default shell to posh from dash. Yes, that would
certainly improve our compliance with Policy considerably.
On Tue, 7 Oct 2014, Adam Borowski wrote:
change your /bin/sh), 2. being (then) a violation of a must clause of
the policy.
To be fair: my bug wasn’t about -a and -o, but about the printf builtin
which Policy is silent about. Some shells do have a builtin printf,
most don’t. printf(1) lives in
On 09/28/2014 10:33 AM, Colin Watson wrote:
On Sat, Sep 27, 2014 at 09:11:44PM -0500, Troy Benjegerdes wrote:
Does update-menus really need bash? Why?
pipefail is actually a fairly useful bashism.
Use mispipe from moreutils instead.
--
Bernd ZeimetzDebian
On Fri, Oct 03, 2014 at 10:42:56AM +1000, Russell Stuart wrote:
On Fri, 2014-10-03 at 00:04 +, brian m. carlson wrote:
Unfortunately, some developers have outright refused to make their
software using /bin/sh work with posh, even when provided with a patch
(e.g. #309415), to the point
* Colin Watson cjwat...@debian.org, 2014-10-04, 09:43:
If we were to decide that #309415 should be fixed in policy (and hence
posh), then it should be done by requiring support for the obsolescent
XSI extensions test -a and test -o.
It's already fixed:
* ‘test’, if implemented as a shell
Jakub Wilk jw...@debian.org writes:
* Colin Watson cjwat...@debian.org, 2014-10-04, 09:43:
If we were to decide that #309415 should be fixed in policy (and hence
posh), then it should be done by requiring support for the obsolescent
XSI extensions test -a and test -o.
It's already fixed:
On Sat, Oct 04, 2014 at 11:19:42AM -0700, Russ Allbery wrote:
Jakub Wilk jw...@debian.org writes:
* Colin Watson cjwat...@debian.org, 2014-10-04, 09:43:
If we were to decide that #309415 should be fixed in policy (and hence
posh), then it should be done by requiring support for the
On Thu, 2014-10-02 at 20:43 -0700, Russ Allbery wrote:
A lot of people miss this about Policy 10.4. People seem to think that
Policy 10.4 is about requirements for shell scripts. But it's just as
much a standard for /bin/sh.
You wrote it, so I guess you get to say what it means. But if you
Russell Stuart russell-deb...@stuart.id.au writes:
On Thu, 2014-10-02 at 20:43 -0700, Russ Allbery wrote:
A lot of people miss this about Policy 10.4. People seem to think that
Policy 10.4 is about requirements for shell scripts. But it's just as
much a standard for /bin/sh.
You wrote it,
On Wed, 1 Oct 2014, Russell Stuart wrote:
The only reason I ported things to dash is /bin/sh is now linked to it,
which in view makes it the standard shell. Every script starting with
#!/bin/sh must work with. If I can't get it working because of a
This is wrong. Every script starting with
On Sep 30, 2014 7:59 PM, Russell Stuart russell-deb...@stuart.id.au
wrote:
On Tue, 2014-09-30 at 13:08 +0200, Thorsten Glaser wrote:
You really really should be looking at replacing any
ash variant with mksh. It’s not that much bigger (at
least if you add -DMKSH_SMALL to CPPFLAGS and build
shawn wilson ag4ve...@gmail.com writes:
I hate the idea of dash. It's not more secure (see vmware cve for an
example) and I think it was more of an accident than anything else this
didn't hit dash too.
The fact that this specific problem didn't hit dash certainly isn't an
accident. The
On Thu, Oct 2, 2014 at 11:33 AM, Russ Allbery r...@debian.org wrote:
shawn wilson ag4ve...@gmail.com writes:
I hate the idea of dash. It's not more secure (see vmware cve for an
example) and I think it was more of an accident than anything else this
didn't hit dash too.
The fact that this
On 02/10/14 17:30, shawn wilson wrote:
I'm pretty sure dash never got a rewrite? So this just happened to be
a feature that got ripped out of dash.
You seem to be under the impression that dash is some sort of fork or
derivative of bash. It isn't; I don't think they even have a common
ancestor.
shawn wilson ag4ve...@gmail.com writes:
On Thu, Oct 2, 2014 at 11:33 AM, Russ Allbery r...@debian.org wrote:
shawn wilson ag4ve...@gmail.com writes:
I hate the idea of dash. It's not more secure (see vmware cve for an
example) and I think it was more of an accident than anything else
this
Ok then, I stand (doubly) corrected. Thanks
On Thu, Oct 2, 2014 at 1:06 PM, Simon McVittie s...@debian.org wrote:
On 02/10/14 17:30, shawn wilson wrote:
I'm pretty sure dash never got a rewrite? So this just happened to be
a feature that got ripped out of dash.
You seem to be under the
On Thu, 2014-10-02 at 11:48 +0200, Thorsten Glaser wrote:
This is wrong. Every script starting with #!/bin/sh must work with a
POSIX shell that supports “local” and “echo -n” (Policy §10.4).
Solid, working software is hard enough to produce. A policy requiring
something you can't test for
On Fri, Oct 03, 2014 at 09:39:29AM +1000, Russell Stuart wrote:
IMO, if Debian has decided the in the default case /bin/sh == dash,
then the policy should say #!/bin/sh scripts must work with dash. It
then becomes trivial for Developers to test their code conforms with
policy. If we allow
On Fri, 2014-10-03 at 00:04 +, brian m. carlson wrote:
The shell you're describing is posh. It implements exactly those
features, and nothing more.
You've got me to look at posh. Thanks for that.
So we do have a shell that developers can use to test their scripts
match Debian policy.
Russell Stuart r...@debian.org writes:
IMO, if Debian has decided the in the default case /bin/sh == dash,
then the policy should say #!/bin/sh scripts must work with dash. It
then becomes trivial for Developers to test their code conforms with
policy.
Up until dash changes, and then you
On Fri, 03 Oct 2014, Russell Stuart wrote:
On Fri, 2014-10-03 at 00:04 +, brian m. carlson wrote:
The shell you're describing is posh. It implements exactly those
features, and nothing more.
You've got me to look at posh. Thanks for that.
So we do have a shell that developers can
Henrique de Moraes Holschuh h...@debian.org writes:
On Fri, 03 Oct 2014, Russell Stuart wrote:
You've got me to look at posh. Thanks for that.
So we do have a shell that developers can use to test their scripts
match Debian policy.
posh is useful to test if a script restricts itself to
On Thu, 2014-10-02 at 22:50 -0300, Henrique de Moraes Holschuh wrote:
Debian policy mandates that /bin/sh implement a _superset_ of POSIX, which
is out of scope for posh.
Regardless, posh implements all the additional features mandated by
10.4:
echo -n, if implemented as a shell built-in,
On Thu, 2014-10-02 at 18:05 -0700, Russ Allbery wrote:
Up until dash changes, and then you have absolutely no idea what to do
with that sort of policy. There's a reason why no standards document I've
ever seen says something like this. The ISO C standard isn't going to say
that anything that
Russell Stuart russell-deb...@stuart.id.au writes:
On Thu, 2014-10-02 at 18:05 -0700, Russ Allbery wrote:
Up until dash changes, and then you have absolutely no idea what to do
with that sort of policy. There's a reason why no standards document
I've ever seen says something like this. The
On Sun, 28 Sep 2014, Russell Stuart wrote:
- pipefail,
mksh has “set -o pipefail” and the PIPESTATUS array.
- local variables,
mksh has them, of course. ksh93 only has them in
functions declared with the “function” keyword,
and lacks a default “alias local=typeset” to make
it useful.
On Tue, 2014-09-30 at 13:08 +0200, Thorsten Glaser wrote:
You really really should be looking at replacing any
ash variant with mksh. It’s not that much bigger (at
least if you add -DMKSH_SMALL to CPPFLAGS and build
with klibc or dietlibc or so), but much saner.
I am not a fan of any
Russell Stuart russell-deb...@stuart.id.au writes:
The only reason I ported things to dash is /bin/sh is now linked to it,
which in view makes it the standard shell. Every script starting with
#!/bin/sh must work with. If I can't get it working because of a
missing feature like arrays then
On Tue, Sep 30, 2014 at 06:23:22PM -0700, Russ Allbery wrote:
Russell Stuart russell-deb...@stuart.id.au writes:
The only reason I ported things to dash is /bin/sh is now linked to it,
which in view makes it the standard shell. Every script starting with
#!/bin/sh must work with. If I
Hi,
Russell Stuart:
- array variables.
No workaround for this one? Pity. This is what usually prevents
conversion.
Well, you could use $ary_len to remember the length of the array,
$(eval echo \\$ary_$pos\)
for retrieving values, and
val=some random value which
On Mon, 2014-09-29 at 08:03 +0200, Matthias Urlichs wrote:
Russell Stuart:
- array variables.
No workaround for this one? Pity. This is what usually prevents
conversion.
Well, you could use $ary_len to remember the length of the array,
$(eval echo \\$ary_$pos\)
for
On Sat, Sep 27, 2014 at 09:11:44PM -0500, Troy Benjegerdes wrote:
Does update-menus really need bash? Why?
pipefail is actually a fairly useful bashism.
--
Colin Watson [cjwat...@debian.org]
--
To UNSUBSCRIBE, email to
On Sun, 2014-09-28 at 09:33 +0100, Colin Watson wrote:
On Sat, Sep 27, 2014 at 09:11:44PM -0500, Troy Benjegerdes wrote:
Does update-menus really need bash? Why?
pipefail is actually a fairly useful bashism.
I've attempted to port the many shell scripts I've written over the
years to dash.
- pipefail,
- local variables,
- array variables.
If dash had those features
Please don't -- some of us appreciate the fact that /bin/sh is
a reasonably minimal shell. Both ksh93 and pdksh/mksh have all three of
those, if memory serves.
-- Juliusz
--
To UNSUBSCRIBE, email to
Hi!
On Sun, 2014-09-28 at 18:39:50 +1000, Russell Stuart wrote:
On Sun, 2014-09-28 at 09:33 +0100, Colin Watson wrote:
On Sat, Sep 27, 2014 at 09:11:44PM -0500, Troy Benjegerdes wrote:
Does update-menus really need bash? Why?
pipefail is actually a fairly useful bashism.
I've
On Sep 28, Guillem Jover guil...@debian.org wrote:
- pipefail,
http://cfajohnson.com/shell/cus-faq-2.html#Q11.
Very practical.
There *is* a reason if we don't write all of our programs in C.
--
ciao,
Marco
signature.asc
Description: Digital signature
On Sun, Sep 28, 2014 at 06:02:09PM +0200, Marco d'Itri wrote:
On Sep 28, Guillem Jover guil...@debian.org wrote:
- pipefail,
http://cfajohnson.com/shell/cus-faq-2.html#Q11.
Very practical.
There *is* a reason if we don't write all of our programs in C.
And if you do then there is
On Sun, 2014-09-28 at 16:47 +0200, Guillem Jover wrote:
I've attempted to port the many shell scripts I've written over the
years to dash. The three irritants are:
- pipefail,
http://cfajohnson.com/shell/cus-faq-2.html#Q11.
That's one of those scratch my eyes out solutions. A more
Hi Troy,
On Sat, Sep 27, 2014 at 10:32:18AM -0500, Troy Benjegerdes wrote:
So far, I need to do the following to remove bash (and associated risk of
0-days until something sane is done about functions)
That is not supported, sorry. Bash is in the essential set, which
means that packages can
Hi!
On Sat, 2014-09-27 at 18:30:17 +0200, Wouter Verhelst wrote:
On Sat, Sep 27, 2014 at 10:32:18AM -0500, Troy Benjegerdes wrote:
So far, I need to do the following to remove bash (and associated risk of
0-days until something sane is done about functions)
That is not supported, sorry.
Hi,
On Sat, 27 Sep 2014, Guillem Jover wrote:
In the case of bash, dpkg can (and does!) use bash explicitly (i.e.,
without going through /bin/sh), so removing bash will pretty much nuke
your system.
Hmm, where?
Wouter has been too quick, it's not dpkg. The output shown by Troy points
to
On Sat, Sep 27, 2014 at 08:42:57PM +0200, Raphael Hertzog wrote:
Hi,
On Sat, 27 Sep 2014, Guillem Jover wrote:
In the case of bash, dpkg can (and does!) use bash explicitly (i.e.,
without going through /bin/sh), so removing bash will pretty much nuke
your system.
Hmm, where?
78 matches
Mail list logo
