On Thu, Jun 20, 2002 at 11:31:42PM -0400, Clint Adams wrote: > > Having echo aliased to `printf "%s\n" "$*"' would give you better POSIX > > compliance too. > No, in fact, it would not. > Compare the output of > ash -c 'echo "test\c"' > versus > printf "%s\n" "test\c"
Ah, I see. So, POSIX recognises that there are two distinct traditional
behaviours, then specifies something that's specifically incompatible with
both of them, and the GNU utilities?
If it's not to enable backwards and cross-Unix compatability, why do we
care about POSIX at all?
bash, /bin/echo and POSIXLY_CORRECT /bin/echo all treat "\c" as a literal,
for reference.
> > And facilitating system breakage is a win somehow?
> No, I'm pointing out that someone can use a POSIX-compliant shell as
> /bin/sh and have a system where fakeroot, debconf, and lots of package
> scripts don't work.
Yes, we can agree about this, evidently.
> Now this would be perfectly fine if the explicit requirement were "ash
> or bash" or there were a certification policy&procedure for /bin/sh.
> Since neither are true, [...]
I suspect this is just talking at cross-purposes, but we do have a
certification policy&procedure for changing what's allowable as /bin/sh,
viz editing policy and filing bugs and changing scripts. I don't see any
reason why that wouldn't be a perfectly reasonable way of doing things,
and, assuming we could avoid having the bugs gratuitously closed or
flamewars about them, I'm optimistic you'd agree.
And while the former isn't how policy's written, it *is* the practical
requirement for /bin/sh, and afaik ash is the only alternative shell
anyone's really considered up until now.
> I would assume something along the lines of the following:
> Bourne shells that make an attempt toward POSIX-compliance when called
> as /bin/sh may be installed as /bin/sh.
Certainly: I'd've assumed the same. It turns out we're wrong: our scripts
don't work with random POSIX-compliant shells, just with bash and ash.
> If the shell fails to accurately interpret a POSIX-compliant script, a
> bug should be filed against that shell's package.
>
> If the shell fails to accurately interpret a non-compliant #!/bin/sh
> script, a bug should be filed against that script's package.
Which is all very well if it's just one script, but it's not so great
when it's a whole bunch of scripts in a whole bunch of packages. That's
why we have a special case for mass-filed bugs: discussion and consensus
*first*, to make sure that that policy is what we actually *want*.
> > No, I maintain that in practice, no matter what policy says, bash and
> > ash are the only shells that work reliably on Debian, and thus are the
> > only ones users should consider using as /bin/sh.
> I don't see what you've got against pdksh. I imagine that it would work
> quite well.
I've never tried it, I haven't seen anyone else try it, and given that
there are a significant number of issues generally, I'd expect some of
them to cause pdksh problems. Additionally, I haven't seen anyone give
any reason why they'd want pdksh instead of bash or ash.
> > I realise this isn't what policy might indicate, and given that I still
> > haven't seen any particularly good reasons to use any other shell,
> > I'm much more inclined to consider this a bug in policy than in all the
> > various packages.
> Debian is about choice. If someone wants to write a POSIX sh in Java,
> are going to prevent them from using it as /bin/sh because you find it
> offensive?
Debian's about choice: if someone wants to rm -rf /usr/bin/perl*, are
you going to prevent them from doing so because you're in love with perl
and you're going to marry it?
No, I'm not going to prevent them, and I'm not in love with perl, I'm
not going to marry it, and I don't find anything offensive about using
shells other than bash and ash as /bin/sh.
That, however, isn't the question being discussed. The question is whether
I'm going to *support* them in doing so: fix problems that wouldn't have
existed if they hadn't done so, or avoid creating them in the first place.
The other question which I've been implying for a couple of messages
now, is if we do support them, how should we prioritise it in relation
to other issues. And the answer to that should be, IMO, nowhere near as
highly as DFSG-freeness or security problems.
> > So now you're offering good reasons why we shouldn't encourage people
> > to use anything but bash as /bin/sh?
> No, that was a good reason not to use Linux 2.5.
Well, whether Linux 2.5 is nice or not seems pretty irrelevant.
> > Considering I invented the serious severity and proposed the various
> > changes to policy and the BTS to support it, I think I have some vague
> > idea what I'm talking about, yes.
> As such, it's bizarre that you seem to object to it.
If it seems so bizarre, perhaps it's an indication that you're not
grokking what I'm saying.
> > How, precisely? What practical benefits does using any shell other than
> > bash or ash as /bin/sh bring you? I've asked this three or four times
> > now without an answer, so please don't expect me to just accept the
> > above as fact.
> Why do they have to be practical? Assuming we agree on what benefits
> are practical--size, speed, compatibility--then the potential benefits
> would be size, speed, or compatibility.
I'm sorry, I'm not interested in "potential" benefits, I'm interested in
actual ones. As far as size is concerned:
-rwxr-xr-x root/root 112272 2002-04-28 17:14:26 ./bin/ash
-rwxr-xr-x root/root 141536 2002-06-19 08:05:46 ./bin/posh
-rwxr-xr-x root/root 217576 2001-12-27 19:00:07 ./bin/ksh
(sizes are from the most recent hppa .deb; posh's is in queue/new on auric
and is readable)
You've already given one example where bash is *more* compatible as
/bin/sh than alternatives (ie, (some versions of?) the Linux 2.5 kernel),
and I'm far from knowing much about POSIX, but the specification for
echo doesn't seem to be doing much to improve compatibility, as far as
I can see.
I haven't been able to observe any speed differences between ash and bash,
so I don't expect I'd see any anywhere else. If you've got something
where there's an observable improvement in speed in using <some other
shell> compared to both ash and bash, I'd be interested.
> > Compare "matches the SUSv3 spec with XSI and UP extensions" and
> > "works with bash and ash". Which do you think is easier to ensure
> > compliance with? Which can maintainers most easily ensure is met before
> > uploading? Which can be tested automatically?
> I imagine that "works with bash" if easiest of all. Why aren't you
> pushing for a mandatory /bin/sh -> bash?
Because we're already able to support /bin/sh -> ash,bash, and we're
doing okay at keeping that support.
> > Huh? Are you really having that much difficulty understanding what I'm
> > saying, let alone agreeing with it? You might've extrapolated the above to
> > "bashims in #!/bin/sh scripts shouldn't be filed as serious bugs either",
> > which I'd've completely agreed with, but I've no idea where you got the
> > above.
> You wouldn't say that a brace expansion bug is no more valid than a kill
> bug?
If it had security implications (allowing a remote/user initiated DoS
or similar, perhaps) I'd think it would warrant treatment as such. I'd
also expect its security implications to be spelt out in the bug report,
though.
> > You do realise that maintainers are expected to fix wishlist and minor
> > and normal bugs, right?
> Are they? I'll reopen 150405 at severity normal and expect you to fix
> it then.
I have no major gripe with that. (Uh, assuming that was the bug against
whichever of my packages it was) If you're in the mood to downgrade the
others to more sensible severities I'd even be happy.
> > We've already established that we do need this exception: plenty of our
> > scripts use it thanks to debhelper, so if you have a /bin/sh that doesn't
> > do it, plenty of stuff will break. Which means you can't set up such a
> > shell as /bin/sh, and the only question is whether we want to support
> > that in future.
> Well, recent versions of debhelper no longer use command -v, nor test
> statements with -a, -o, or parentheses, so after some recompiles,
> considerably less will break.
Seems like a lot of effort to go to for no practical benefit.
> > Do you see how there's a practical benefit to using a shell other than
> > ash or bash as /bin/sh?
> Yes.
Then what is it?
> > I'd hope you can tell that my answers to the above would be "yes", and
> > "no", respectively, and how the answer to the first implies my answer to
> > your question has to be "yes".
> Yes. However, I think the fact that _you_ see no practical benefits as
> being largely unimportant.
Well, considering you've already asked me to do something to help support
this particular fetish, you might want to reconsider the importance of
me seeing any reason whatsoever to help you out.
> I am confident that the vast majority of developers have left bash
> as /bin/sh.
Which seems to support the "no practical benefit" argument, no? There're
plenty of developers running different shells in places where it does
matter (particularly their login shell).
> > No, and I probably won't bother. The whole policy of giving this list
> > influence over release critical bugs was a mistake, because of, well,
> > people like you.
> I don't know why you keep going on and on about release-critical bugs.
Hello, release-manager.
You realise you filed most of those /bin/sh bugs as release-critical
bugs, right?
> > Non-release-critical bugs matter. Release-critical bugs get a lot more
> > press time and attention and get to dress up in fancy frocks and go to
> > awards nights, but they're not fundamentally more special, and they're
> > not the means by which we make Debian excellent. Release-critical bugs are
> > the way we make sure Debian doesn't completely and utterly suck. It's the
> > way we make sure you can install a Debian system, put it on the Internet,
> > and still have control over it five minutes later. They're not the way
> > we ensure that packages we install have useful documentation, or that
> > they're sensibly configured out of the box, or that window manager menus
> > are usefully setup to display all the interesting apps you have installed,
> > or all the other nice things Debian does.
> Do you think I waited until after the alleged date of woody's release to
> file serious bugs because I was confused?
Evidently. If you want to get them all fixed before the next release,
file them early, and check up on their progress in a couple of months. The
severity has *nothing* to do with that.
> > I'm all too well aware that everyone thinks their pet fetish needs to
> > be made a "must" in policy or it'll be "utterly pointless" to try to do
> > anything about it at all, but, well, you're wrong.
> I'll try to be presumptuous about the meaning of policy now:
> | The standard shell interpreter `/bin/sh' can be a symbolic link to any
> | POSIX compatible shell, if `echo -n' does not generate a newline.[1]
> This means that /bin/sh should be almost POSIX-compatible.
Yes. It's also wrong.
If you want to argue about what is the case, I'll take the way the archive
looks over policy's opinion any day.
If you want to argue about what should be the case, I'll take arguments
about practical utility and difficulty over policy's opinion any day.
For the former, the echo -n exemption isn't nearly enough: we also need
a fancier test, command -v, we don't support the funny \c characters in
echo, and probably various other things.
For the latter, you're yet to show *any* practical utility in using other
shells -- and indeed you've demonstrated some reasons why you would *not*
want to use other shsels, and you've already shown that we've got a fair
way to go before we do support them.
> | Thus, shell scripts specifying `/bin/sh' as interpreter should only
> | use POSIX features.
> This isn't a must because such shell scripts must be allowed to use
> non-POSIX features, such as start-stop-daemon and what-have-you.
Huh? Surely running scripts present on the filesystem is a POSIX feature?
Violations of "shoulds" are normal bugs; if the above indicates what
you seem to imply it does (ie, that calling start-stop-daemon breaks
that guideline), then we ought to be filing bugs for every package that
invokes start-stop-daemon from a script.
> | 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., `#!/bin/bash') and the package must depend on the package
> | providing the shell (unless the shell package is marked `Essential',
> | as in the case of `bash').
> If this were not a must, then anyone could make a #!/bin/sh script that
> would not run on bash, and it would not be a valid bug.
If it were a should, not a must, they would file a normal bug, and it'd
get fixed. I'm not seeing the problem. Please make sure you've read
section 1.1 of policy, particularly the paragraph beginning "In this
manual, the words _must_, _should_ and _may_, ...".
> Perhaps you'd
> think it was a bug. Nevertheless, I can imagine one or two maintainers
> telling you that bash isn't a supported #!/bin/sh for this package.
And I can imagine them getting a bug report from every user that runs
their package. I can also imagine there being a fairly quick consensus
on any list it was brought to that that was a stupid thing to do.
Policy isn't a stick to beat people with, even when they make the most
appalling idiocies. Stop pretending it is, or that -- if it isn't --
that we have no other possible recourse to ensure we produce a high
quality system.
If you can't justify a change without reference to policy, then you
shouldn't be suggesting it, let alone demanding it. Policy's a convenient
way to make sure you don't have to endlessly repeat yourself when filing
bugs, or explaining to new maintainers how things should be packaged, but
it's not a substitute for good sense.
Cheers,
aj
--
Anthony Towns <[EMAIL PROTECTED]> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``BAM! Science triumphs again!''
-- http://www.angryflower.com/vegeta.gif
pgpWrcEZ4GNE6.pgp
Description: PGP signature
