Re: RFD: Essential packages, /, and /usr
On Sun, 30 Jun 2002, Herbert Xu wrote: Adam Heath [EMAIL PROTECTED] wrote: There are minor non-posix issues. The biggest is the use of echo -n(don't say use printf, it's too slow for shoop's target audience). In the current Debian ash package, echo calls the printf builtin internally, and I'm yet to see a slow down. ash is but one shell. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
Adam Heath [EMAIL PROTECTED] wrote:
There are minor non-posix issues. The biggest is the use of echo -n(don't say
use printf, it's too slow for shoop's target audience).
In the current Debian ash package, echo calls the printf builtin
internally, and I'm yet to see a slow down.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
There are minor non-posix issues. The biggest is the use of echo -n(don't say use printf, it's too slow for shoop's target audience). It looks to me like the biggest is the use of 'local', actually. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
On Sat, 22 Jun 2002, Clint Adams wrote: Any chance of a rerun with posh (sources are in queue/new and readable) or pdksh? I don't think you'll be able to gauge posh that way; shoop isn't POSIX-compliant. There are minor non-posix issues. The biggest is the use of echo -n(don't say use printf, it's too slow for shoop's target audience). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
Anthony Towns aj@azure.humbug.org.au wrote:
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.
GNU has always adopted the BSD behaviour of not interpreting back
slashes. All SYSV shells behaved like
printf %b\n $*
This includes pdksh.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
aj If it's not to enable backwards and cross-Unix compatability, why aj do we care about POSIX at all? aj bash, /bin/echo and POSIXLY_CORRECT /bin/echo all treat \c as a aj literal, for reference. Herbert GNU has always adopted the BSD behaviour of not interpreting Herbert back slashes. All SYSV shells behaved like Herbert printf %b\n $* Herbert This includes pdksh. BTW, is the following of any import? Andrew Submitted-by: [EMAIL PROTECTED] (Andrew Josey) Andrew Austin Group Status Update Submitted by Andrew Josey, The Open Andrew Group. June 2002 [snip] Andrew The ninth meeting of the joint technical working group Andrew informally known as the Austin Group was held at The Open Andrew Group facility in Reading, UK on May 8-9 2002. The meeting had Andrew 20 attendees (nine of which via teleconference). Andrew 120 aardvark defect reports were reviewed during the meeting. Andrew It was agreed to form a subgroup to address the Regular Andrew Expressions issues and that this would be chaired by David Andrew Korn. It was agreed that the definition of the echo utility Andrew should revert to XCU5, thereby accomodating the historical Andrew practice of BSD, and that this be a candidate change for TC1. -- Ian Zimmerman, Oakland, California, U.S.A. GPG: 433BA087 9C0F 194F 203A 63F7 B1B8 6E5A 8CA3 27DB 433B A087 EngSoc adopts market economy: cheap is wasteful, efficient is expensive. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
On Fri, Jun 21, 2002 at 01:53:58PM -0400, Joey Hess wrote: Take shoop benchmarks (this is an old shoop tree I had lying around): bash: 1000 shoop 1st-stage resolver method calls : 0:05.51 ash : 1000 shoop 1st-stage resolver method calls : 0:01.33 bash: 1000 shoop 2nd-stage resolver method calls : 0:08.33 ash : 1000 shoop 2nd-stage resolver method calls : 0:02.23 bash: 1000 shoop 2nd-stage(nocache) resolver method calls : 0:08.19 ash : 1000 shoop 2nd-stage(nocache) resolver method calls : 0:02.27 (On a TM5800 with the cpu set to run at 333 to 533 mhz.) Any chance of a rerun with posh (sources are in queue/new and readable) or pdksh? 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
On Fri, Jun 21, 2002 at 06:05:39PM -0400, Clint Adams wrote: sake. I understand the alleged benefits of ash (small, loads faster on a slow/small memory machine). Why would I, Debian user, benefit from being able to run pdksh as /bin/sh? (Remembering that standards compliance, in and of itself, does not give me a sexual thrill.) I answered this explicitly already. It gives you a smaller, faster-loading shell and it supports brace expansions, which are the number one bug filed against #!/bin/sh scripts. As far as I can tell there are two possibilities here: (a) it is pdksh or posh, and it already works at least as well as ash on the various #!/bin/sh scripts in Debian, or (b) it is pdksh or posh or similar, and it doesn't yet work as well as ash on the various #!/bin/sh scripts in Debian, due to various POSIX extensions that we use and it doesn't support In (a)'s case, this means that we can just say Actually, as it turns out, we don't merely support ash and bash as /bin/sh at present, actually we lucked out and we already support ash, bash and pdksh! and have no more problems continuing to support pdksh as we're going to have continuing to support ash. If this is the case, then there's *still* no value in minimising /bin/sh: we can get the smaller-faster-loading-more-reliable-shell that you're talking about without having to fix all your various bugs. Whichever shell you're talking obviously already supports kill -9, type and command, and whatever other useful features that we currently use and you want us to stop using. If this is supposedly the case, it'd be helpful to know which shell this is, and if it does actually work as well as you're hypothesising. So, if someone needs to run a low-memory machine in production, [...] In (b)'s case, on the other hand, you _can't_ run whatever shell you're talking about on a production, because it _doesn't_ work as well as ash, and this entire line of argument's erroneous. Is this not an answer? Well, no, it really isn't. If some shell already works better with than some other supported shell in practice, then it's supported de facto -- continuing to support it doesn't require signficant changes to current practice, by definition. As such, it doesn't make sense to use that as an argument about why we should change current practice. 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 pgpgl01DfMsVr.pgp Description: PGP signature
Re: RFD: Essential packages, /, and /usr
Any chance of a rerun with posh (sources are in queue/new and readable) or pdksh? I don't think you'll be able to gauge posh that way; shoop isn't POSIX-compliant. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
As far as I can tell there are two possibilities here: (a) it is pdksh or posh, and it already works at least as well as ash on the various #!/bin/sh scripts in Debian, or It is pdksh. (b) it is pdksh or posh or similar, and it doesn't yet work as well as ash on the various #!/bin/sh scripts in Debian, due to various POSIX extensions that we use and it doesn't support It is posh. Well, no, it really isn't. If some shell already works better with than some other supported shell in practice, then it's supported de facto -- continuing to support it doesn't require signficant changes to current practice, by definition. As such, it doesn't make sense to use that as an argument about why we should change current practice. So now the arbitrary criterion is breaks on less scripts than ash? gnumail won't run if /bin/sh is ash. The gnumail maintainer should a) make the script POSIX-compliant b) make the script a #!/bin/bash script c) do neither and complain ? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
Branden == Branden Robinson [EMAIL PROTECTED] writes: Branden If: Branden * Release critical bugs are _very_ rare.; and Branden * Release critical bugs should be the domain of the Release Manager, Branden Then we really don't need a tight connection between the Branden serious severity and release-criticality at all. Branden Release-criticality can be a tag -- whether that is Branden expressed in debbugs along with security, moreinfo, Branden patch and so forth or in a webpage like bugscan is Branden immaterial. Branden This tag -- no matter how it is expressed -- is the Release Branden Manager's domain. People can propose that a bug be treated Branden as release-critical and, perhaps, if it seems warranted, we Branden can make this a debbugs tag and possibly automatically set Branden it for all critical, grave, and serious bugs. Branden The Release Manager can strip the release-critical tag off Branden of any bug he wants. This is how things have *always* Branden worked in reality. If a bug is truly a showstopper for a Branden release, we don't release with it. We either wait, fix the Branden bug, or drop the package. I find myself in strong and vehement agrement with Branden on this point. manoj -- I think the sky is blue because it's a shift from black through purple to blue, and it has to do with where the light is. You know, the farther we get into darkness, and there's a shifting of color of light into the blueness, and I think as you go farther and farther away from the reflected light we have from the sun or the light that's bouncing off this earth, uh, the darker it gets ... I think if you look at the color scale, you start at black, move it through purple, move it on out, it's the shifting of color. We mentioned before about the stars singing, and that's one of the effects of the shifting of colors. Pat Robertson, The 700 Club Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#97671: RFD: Essential packages, /, and /usr
On Sat, Jun 22, 2002 at 02:02:00AM -0500, Manoj Srivastava wrote: Branden == Branden Robinson [EMAIL PROTECTED] writes: Branden * Release critical bugs are _very_ rare.; and Branden * Release critical bugs should be the domain of the Release Manager, Branden Then we really don't need a tight connection between the Branden serious severity and release-criticality at all. Sorry, but this doesn't follow. Treating serious as a severity or a tag is largely immaterial, and the fundamental point of the serious severity or tag is as an aid to release management. Branden The Release Manager can strip the release-critical tag off Branden of any bug he wants. This is how things have *always* Branden worked in reality. No, it's not. In reality, things have always just been ignored, rather than being formally stripped of release-criticality. I find myself in strong and vehement agrement with Branden on this point. Branden brought up a number of interesting and good points (and, even better, simple) in the discussion he's referencing, but it was at the end of a pretty long winded and vicious argument about the referenced bug, and there was too much of an agree to anything just to get this over with on my behalf. Which isn't to say I don't agree with much of it, but I need some time to sit and look at this calmly before I can have a considered opinion on it. OTOH, there is one part that I have had plenty of opportunity to think about: and personally I don't believe debian-policy should have _any_ influence over the severity of a bug. If there're already good reasons for increasing the severity of a bug without policy, then that's good enough. If there aren't, policy shouldn't be forcing them on people. There're plenty of ways we can improve Debian without raising the members of the policy list as being better or more powerful than other developers. Beyond _all_ other things, this is the major problem with the serious severity and release-critical bugs (and debian-policy@) at the moment. And as much as I'd like to be able to say it's better to have -policy be better and more powerful than the release manager for general democratic and consensus principles, I'm sorry, but it simply hasn't worked, and I'm yet to see *anyone* even remotely interested in making it work. 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 pgpweSghV8iHS.pgp Description: PGP signature
Re: Bug#97671: RFD: Essential packages, /, and /usr
On Sat, Jun 22, 2002 at 09:29:42PM +1000, Anthony Towns wrote: Sorry, but this doesn't follow. Treating serious as a severity or a tag is largely immaterial, and the fundamental point of the serious severity or tag is as an aid to release management. That may be its intent, but apparently that's not how it's being used a large proportion of the time. Branden The Release Manager can strip the release-critical tag off Branden of any bug he wants. This is how things have *always* Branden worked in reality. No, it's not. In reality, things have always just been ignored, rather than being formally stripped of release-criticality. My statement does not assert that the Release Manager has undertaken any formal procedure. I'm saying that it is the case that a bug isn't de facto release critical if the Release Manager doesn't treat it thus. And as much as I'd like to be able to say it's better to have -policy be better and more powerful than the release manager for general democratic and consensus principles, I'm sorry, but it simply hasn't worked, and I'm yet to see *anyone* even remotely interested in making it work. I think these are largely orthogonal issues. Debian Policy is a great tool, but ill-suited to determining release viability for an individual package or for the distribution as a whole. In my opinion and experience, a Debian Policy is better suited to establishing and enforcing objective criteria that ultimately serve to improve the quality of Debian packages, and of the distribution as a whole. Due to the objectivity and specificity of the criteria it establishes, it is easy for a large number of people to participate in the process of crafting Policy in a democratical and consensus-driven manner. Release management is a highly subjective process -- at least the way Debian does it -- because we always settle for something significantly less than perfection (IMO that's a good thing). The establishment of subjective criteria for good enough is often influenced by external factors like upstream releases, security issues, Debian's non-package infrastructure (automated security builds, the mirror network, etc.) and the date on the calendar. Due to that, I think it makes more sense for release management by an individual or a small team of people who work together well. The bottom line for me is that it's difficult to achieve consensus on subjective issues. I think our approach to the twin nemeses of policy and release management need to reflect this fact better than they do at present. -- G. Branden Robinson| Debian GNU/Linux | If encryption is outlawed, only [EMAIL PROTECTED] | outlaws will @goH7Ok=q4fDj]Kz?. http://people.debian.org/~branden/ | pgpV6Xktse9NC.pgp Description: PGP signature
Re: RFD: Essential packages, /, and /usr
9989 * An alias shall be written as a command line that represents its alias definition. cf. alias: | The following operands shall be supported: | | alias-name | Write the alias definition to standard output. [...] | The format for displaying aliases (when no operands or only name | operands are specified) shall be: | | %s=%s\n, name, value | The value string shall be written with appropriate quoting so that it is | suitable for reinput to the shell. See the description of shell quoting | in Quoting . I read that to mean that the output of alias history, for example, should be something like history=fc -l So, if that's the alias definition, then what's the value of %s, pathname or command when pathname or command is a command line that represents its alias definition. I was assuming that fc -l was the command line representing the alias definition, but if POSIX is documenting current practice, I am in the minority. Still, it seems as though fc -l is more useful in command substitution than alias history='fc -l'. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
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 policyprocedure for /bin/sh. Since neither are true, [...] I suspect this is just talking at cross-purposes, but we do have a certification policyprocedure 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
Re: RFD: Essential packages, /, and /usr
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? No, it's specifically compatible with SysV echo. If it's not to enable backwards and cross-Unix compatability, why do we care about POSIX at all? I don't know. Do we care about POSIX at all? bash, /bin/echo and POSIXLY_CORRECT /bin/echo all treat \c as a literal, for reference. You can file bugs against bash and shellutils if you think they should comply. I suspect this is just talking at cross-purposes, but we do have a certification policyprocedure 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. Isn't that what we're doing? 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. But they don't all work with ash. 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*. Calling it a mass-filing is a stretch, especially since I did them all manually. 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. Well, if it'll help, I'll try. bash is large, and is slightly POSIX-incompatible. ash is slightly POSIX-incompatible. pdksh seems to be more POSIX-compatible than both right now. But let's skip that right now, since POSIX compatibility is in question, and I'm confident that Herbert will have ash up to snuff shortly. I would estimate that the vast majority of severity:serious justification:11.4 bugs being filed on packages contain bashism in the subject and cite brace expansions being used in #!/bin/sh scripts. While it's called a bashism and is definitely not POSIX-compliant, all the other Bourne shells currently in the archive support brace expressions. That includes pdksh. In summary, pdksh vs. bash gives you some of the size and speed advantage and more bashism compatibility than ash vs. bash. Perhaps it's a compromise solution for those who want a smaller /bin/sh but don't want the breakage. 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? That's a great question. 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. Well, no one's forcing you to comply with policy. 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. Fine. Fix all the DFSG-freeness and security problems in your packages, then change those daunting 6 octets. Well, whether Linux 2.5 is nice or not seems pretty irrelevant. Of course it does. If it seems so bizarre, perhaps it's an indication that you're not grokking what I'm saying. I'm not even close to grokking it. 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), More compatible with the Linux 2.5 kernel build system. More compatible with Debian #!/bin/sh scripts right now. Less compatible with certain ATT shell scripts, which special-case bash's allegedly buggy behavior. Obviously no users running the latter really need something other than bash as /bin/sh, so I can see that as being unimportant. 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. No, the previous specifications haven't done much for compatibility. They said we don't have a clue what echo will do when you give it crazy things like arguments, so use printf instead. Only nobody used printf. Why? Because echo is typically a builtin, and printf is a builtin in only a few shells. Now, if echo doesn't behave the way they say, it's buggy. This makes it suddenly useful for POSIX script writers. I imagine that it might be useful for people importing scripts from SysV too, but who really cares about that? I
Re: RFD: Essential packages, /, and /usr
On Fri, Jun 21, 2002 at 12:05:38AM -0400, Clint Adams wrote:
9989 * An alias shall be written as a
command line that represents its alias definition.
cf. alias:
| The following operands shall be supported:
|
| alias-name
| Write the alias definition to standard output.
[...]
ls=foo
is an alias definition.
alias ls=foo
is a command line that represents the alias definition.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
On Fri, Jun 21, 2002 at 03:09:17AM -0400, Clint Adams wrote: 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. Well, no one's forcing you to comply with policy. Yeesh. I don't know what so hard about this. The following statements are true. I am not an idiot. I do not need to be forced to follow good advice. Policy is by and large good advice. You don't have to force me to follow policy, as long as you make it sensible. If you've got a good reason to allow any POSIX compatible shell as /bin/sh then *tell* me it, and I'll happily support you all the way. 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. Fine. Fix all the DFSG-freeness and security problems in your packages, then change those daunting 6 octets. See the problem is that right from the start you've tried prioritising them at the exact same level as DFSG-freeness and security problems. That's what the release critical severities are there for. If it seems so bizarre, perhaps it's an indication that you're not grokking what I'm saying. I'm not even close to grokking it. Then please, pay attention. I've explained this a dozen times on this list already, so if you need a different wording surely there's someone out there how can provide it. Release critical bugs are _very_ rare. They're not for problems that we're annoyed or embarrased about having, they're not for policy violations in general, they're not for setting goals that need to be done in lots of packages. They are *purely* for those issues which are so severe that they're worth removing packages because of, or saying I'm sorry, we can't release on the day I said, because these issues are unresolved. I had hoped that letting policy have some influence on which policy issues should be considered release-critical would help ensure consistency and a deeper analysis of potential release-critical issues. Instead it seems to be an excuse for people to raise every other policy issue to release-critical status, and I have to either repeatedly argue against it and live with all the mistakes made anyway (like the must idiocy related to /bin/sh). And yes, after eighteen months to two years of having to explain this again and again and again and again -- in spite of it being pretty clearly written in policy itself -- my patience is pretty short on the whole issue. 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. No, the previous specifications haven't done much for compatibility. They said we don't have a clue what echo will do when you give it crazy things like arguments, so use printf instead. Only nobody used printf. Why? Because echo is typically a builtin, and printf is a builtin in only a few shells. Now, if echo doesn't behave the way they say, it's buggy. ...and very few shells implement it the way POSIX says, so scripts that want to be portable can't rely on what POSIX says. Because we're already able to support /bin/sh - ash,bash, and we're doing okay at keeping that support. A quick scan of the BTS suggests that at least 824 bugs are about ash not working with #!/bin/sh scripts. How many of them are marked serious, exactly? For that matter, how many of them are in base or standard packages? 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). If it didn't matter, why did people fight for ash? There was a fight, remember? I don't really see why you need me to make your arguments for you, but whatever. The argument for ash's utility is its self-evident smallness and claims that it's (therefore) faster to use. I haven't actually seen any benchmarks to back up the latter, but the theory certainly seems reasonable. Further, some developers actually do run ash as there /bin/sh, no matter what the majority of developers do. Hello, release-manager. You realise you filed most of those /bin/sh bugs as release-critical bugs, right? I filed them as severity serious. I did not make 'serious' bugs RC. I did not associate 'serious' with policy violation. That being said, my conception was that RC bugs were those of priority serious or higher which hadn't been specifically excepted by the release manager for arbitrary reasons. Now, seeing as how woody is frozen, and testing is not running, I don't see how this has any practical impact anyway. Yeesh. Testing's going to run again sooner or
Re: RFD: Essential packages, /, and /usr
On Thu, Jun 20, 2002 at 11:31:42PM -0400, Clint Adams wrote: Unless policy is changed, indications are that the only packages using command -v by the time of woody+1's release will be XFree86. Easy now. I don't *like* the construction if command -v foo /dev/null 21; then foo fi I hate that nasty redirection that is imposed on me. The only reason I am waiting to change it is because I think there's a good chance a knucklehead POSIX or Policy lawyer is going to keep filing or reopening bugs against my packages no matter what I do.[1] If I change it to use type, one person will complain. If I change it to use which, another person will complain. You won't catch me doing test -x /usr/bin/foo. I refuse to precariously balance my scripts on my confidence that the package maintainer of the package containing foo won't move it to /bin, /sbin, or /usr/sbin. So, although the status quo got a bug filed against my package, I'm sticking with it because the only reasonable alternatives also seem objectionable to one or another of the various POSIX and Policy lawyers in this discussion. If you guys can broker a mutual peace by the time of woody+1's release, you'll likely find me accomodating to the policy you come up with...as long as you don't force me to hard-code paths to other packages' executables. [1] Unlike some folks in this Project, I don't enjoy the privilege of being able to arbitrarily close, reassign, or downgrade actual, valid bug reports against my package. -- G. Branden Robinson| Q: How does a Unix guru have sex? Debian GNU/Linux | A: unzip;strip;touch;finger;mount; [EMAIL PROTECTED] |fsck;more;yes;fsck;fsck;fsck; http://people.debian.org/~branden/ |umount;sleep pgpxUPhIIDQd0.pgp Description: PGP signature
Re: RFD: Essential packages, /, and /usr
On Fri, Jun 21, 2002 at 02:49:00PM +1000, Anthony Towns wrote: If you can't justify a change without reference to policy, then you shouldn't be suggesting it, !? No more wishlist bugs? -- G. Branden Robinson|I've made up my mind. Don't try to Debian GNU/Linux |confuse me with the facts. [EMAIL PROTECTED] |-- Indiana Senator Earl Landgrebe http://people.debian.org/~branden/ | pgpjTV2tq7fY7.pgp Description: PGP signature
Re: RFD: Essential packages, /, and /usr
On Fri, Jun 21, 2002 at 03:09:17AM -0400, Clint Adams wrote: I didn't realize that policy compliance was some sort of buddy-boy system. /me watches comprehension slowly, slowly wash over Clint's countenance... -- G. Branden Robinson| It doesn't matter what you are Debian GNU/Linux | doing, emacs is always overkill. [EMAIL PROTECTED] | -- Stephen J. Carpenter http://people.debian.org/~branden/ | pgpy7wo8IRzzO.pgp Description: PGP signature
Re: RFD: Essential packages, /, and /usr
Branden Robinson [EMAIL PROTECTED] writes: On Fri, Jun 21, 2002 at 02:49:00PM +1000, Anthony Towns wrote: If you can't justify a change without reference to policy, then you shouldn't be suggesting it, !? No more wishlist bugs? Perhaps a rephrase would help? If the _only_ justification for a change is policy, then you shouldn't be suggesting it. -- James -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
On Sat, Jun 22, 2002 at 01:13:47AM +1000, Anthony Towns wrote: Then please, pay attention. I've explained this a dozen times on this list already, so if you need a different wording surely there's someone out there how can provide it. Release critical bugs are _very_ rare. They're not for problems that we're annoyed or embarrased about having, they're not for policy violations in general, they're not for setting goals that need to be done in lots of packages. They are *purely* for those issues which are so severe that they're worth removing packages because of, or saying I'm sorry, we can't release on the day I said, because these issues are unresolved. I had hoped that letting policy have some influence on which policy issues should be considered release-critical would help ensure consistency and a deeper analysis of potential release-critical issues. Instead it seems to be an excuse for people to raise every other policy issue to release-critical status, and I have to either repeatedly argue against it and live with all the mistakes made anyway (like the must idiocy related to /bin/sh). And yes, after eighteen months to two years of having to explain this again and again and again and again -- in spite of it being pretty clearly written in policy itself -- my patience is pretty short on the whole issue. If Mohammed cannot go to the mountain, perhaps the mountain must come to Mohammed. We discussed this on IRC a month or so ago. For the benefit of everyone else here, I'll re-hash it as I remember it. Feel free to correct me if I've misremembered. If: * Release critical bugs are _very_ rare.; and * Release critical bugs should be the domain of the Release Manager, Then we really don't need a tight connection between the serious severity and release-criticality at all. Release-criticality can be a tag -- whether that is expressed in debbugs along with security, moreinfo, patch and so forth or in a webpage like bugscan is immaterial. This tag -- no matter how it is expressed -- is the Release Manager's domain. People can propose that a bug be treated as release-critical and, perhaps, if it seems warranted, we can make this a debbugs tag and possibly automatically set it for all critical, grave, and serious bugs. The Release Manager can strip the release-critical tag off of any bug he wants. This is how things have *always* worked in reality. If a bug is truly a showstopper for a release, we don't release with it. We either wait, fix the bug, or drop the package. I honestly believe this mechanism would head off most of these catfights at the pass. Proper usage of must vs. should in the Policy manual? Immaterial. Mass-filing of serious bugs as public service or masturbatory frenzy? Immaterial. Release-critical? Release Manager's call, period (unless someone bothers to appeal to the Technical Committee -- not a process that is likely to get one a speedy remedy :). And, while we're at it, this would enable us to re-establish a maintainer's discretionary power over bug severities, even serious ones. As Josip Rodin noted in debian-devel, sometimes even a violation of a must directive really isn't a big deal. Sometimes it just doesn't make that much difference. Whether that's due to policy inflating the importance of compliance with a certain detail, or due to unusual circumstances doesn't matter. The Release Manager gets to attach the release-critical tag to any bug he wants, and the package maintainer is expected to act on that bug if he wants his package to release with Debian. If he doesn't, he can alter the severities of his bugs pretty much at his discretion. There is a lot more discussion of this issue in the logs of Bug #97671. http://bugs.debian.org/97671 N.B.: the above is my recollection of a conversation, and should not be construed as representing the opinions of anyone else unless they say so. -- G. Branden Robinson|I've made up my mind. Don't try to Debian GNU/Linux |confuse me with the facts. [EMAIL PROTECTED] |-- Indiana Senator Earl Landgrebe http://people.debian.org/~branden/ | pgpOAqBhELoIR.pgp Description: PGP signature
Re: RFD: Essential packages, /, and /usr
Anthony Towns wrote: 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. Take shoop benchmarks (this is an old shoop tree I had lying around): bash: 1000 shoop 1st-stage resolver method calls : 0:05.51 ash : 1000 shoop 1st-stage resolver method calls : 0:01.33 bash: 1000 shoop 2nd-stage resolver method calls : 0:08.33 ash : 1000 shoop 2nd-stage resolver method calls : 0:02.23 bash: 1000 shoop 2nd-stage(nocache) resolver method calls : 0:08.19 ash : 1000 shoop 2nd-stage(nocache) resolver method calls : 0:02.27 (On a TM5800 with the cpu set to run at 333 to 533 mhz.) -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
Easy now. I don't *like* the construction if command -v foo /dev/null 21; then foo fi I hate that nasty redirection that is imposed on me. Well, the popular proposal (which seems to be SUSv3+UP+XSI), will give you type, and you'll need to redirect that as well. If you want some sort of -q option, you'll need something else entirely. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
If this is regarding the [ -a -o ] stuff, then sorry, but debhelper is just the tip of the iceberg, or at least of my personal iceberg. Hmm.. I must have grepped badly. There will be tens of thousands in all of debian, if this sample of 100 packages is representative. I even find them in autoconf install-sh, which I'd expect to be portable. I've emailed automake about this. Perhaps they'll change it. Perhaps not. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
I know I'm going to hate getting into this one, but: On 21-Jun-02, 14:31 (CDT), Clint Adams [EMAIL PROTECTED] wrote: (2) There's no benefit to anyone using a shell other than ash or bash as /bin/sh on a Debian system. No, you're being deliberately obtuse on this one. Clint, Anthony has asked several times on this thread for you to state the benefit of being able to use shells other than bash and ash as /bin/sh. The only answer I've seen is the continued chanting of POSIX is good, and I don't buy the idea of standards compliance for it's own sake. I understand the alleged benefits of ash (small, loads faster on a slow/small memory machine). Why would I, Debian user, benefit from being able to run pdksh as /bin/sh? (Remembering that standards compliance, in and of itself, does not give me a sexual thrill.) Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
sake. I understand the alleged benefits of ash (small, loads faster on a slow/small memory machine). Why would I, Debian user, benefit from being able to run pdksh as /bin/sh? (Remembering that standards compliance, in and of itself, does not give me a sexual thrill.) I answered this explicitly already. It gives you a smaller, faster-loading shell and it supports brace expansions, which are the number one bug filed against #!/bin/sh scripts. So, if someone needs to run a low-memory machine in production, and is not interested in finding brace expansions in #!/bin/sh the hard way, it's safer to use pdksh as /bin/sh than it is to use current ash, and you will still get a memory benefit. Is this not an answer? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
On Wed, Jun 19, 2002 at 02:34:30AM -0400, Clint Adams wrote:
The exact output of command -v is not given by POSIX.
I believe it says
When the -v option is specified, standard output shall be formatted as:
%s\n, pathname or command
Are you referring to the extra new line that ash outputs after an alias?
If so that is indeed incorrect and will be fixed.
More details please.
%s=%s\n, name, value
Will fix.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
On Wed, Jun 19, 2002 at 02:05:01PM -0400, Clint Adams wrote: Scenario A: Script works on bash and ash, which are the two main shells anyone has a reason to use as /bin/sh on Debian. Scenario B: Script works on bash and ash, which are the two main shells anyone has a reason to use as /bin/sh on Debian. Why on earth should this be so? I don't really care whether it should or shouldn't be so, but it certainly seems like it *is* so. Using bash minimises the disk space used by shells and is the most reliable, and using ash is faster. Are there any other benefits to be had by using different shells? Is saying The standard shell interpreter `/bin/sh' can be a symbolic link to any POSIX compatible shell, if `echo -n' does not generate a newline. yet another of Policy's arrogant lies? I'm not really sure why you're being quite so emotive as to call it an arrogant lie. I'd've called it a bug or an underspecification. Potato, potatoe, I guess... And in any event that's my point: if you find a case where packages don't match what policy says, you need to bring it up on -devel to make sure it really is policy -- well, your reading of policy -- that's right. When I joined Debian, bash was the only choice for /bin/sh. Back then, one would have said, Script works on bash, which is the only shell anyone as a reason to use as /bin/sh on Debian, and we don't support anything else. And it worked pretty well, don't you think? Allowing people to use ash as well wasn't too huge a step, so we made that. We overreached and thought what we were doing would let people use random other shells as well, but obviously we were wrong. Whether we want to go further is something that we may wish to do, or we may not. Now, those poor people who read Policy or debconf messages might come to the silly conclusion that they could make pdksh or zsh their /bin/sh. Or perhaps they will obtain a copy of ksh93 and make that their /bin/sh. Perhaps that are even forced to do that to support some horribly-behaved commercial software. Uh, are there any examples at all of the latter? If not, please don't waste everyone's time by making up problems that don't exist. (Considering that Linux systems tend not to run non-Linux binaries, that commercial apps tend to not come as shell scripts, and that most Linux distributions come with bash as /bin/sh, I can't say it's a very credible problem) Some developers want our users to have this choice. Others don't have this as a priority. Imagine that. You realise there's not a problem with this, right? People aren't meant to have to cede their priorities when they join Debian (well, beyond Our users and free software perhaps). Filing release-critical bugs is exactly that, though: forcing everyone to accept your priorities as the most crucial things affecting their package. Sometimes that's completely reasonable: for Debian's purposes, DFSG problems and security bugs have to be considered to be the most important things to fix no matter what the maintainers personal priorities might be; at other times it can be questionable: take the FHS violation in #97671 / #143825, which policy would say should be treated more importantly than (eg) all the random segfaults in the X server -- which the X maintainer disagrees with. At other times it's just ridiculous: being able to use zsh instead of bash as your /bin/sh might be a neat trick if you're a zsh fanatic, but it isn't any sort of significant practical win to anyone. It happens to be a lot of work to make something comply with the letter of POSIX's minimal specification for /bin/sh, especially since it seems to Then you'll appreciate that I did the work for you and gave you a POSIX-compliant alternative in the bug report. No, I won't: what you've done for me is given my a little patch which affects essentially no one, and given me a dozen new bugs in the RC bug list that I'm going to have to go through and downgrade or close. Sorry, but the plusses don't cancel out the minuses. be intent on becoming more minimal as time passes, and since it doesn't seem to worry itself too much with existing BSD or Linux systems. I don't get that impression. POSIX actually seems to be improving with time. With the new POSIX / SUSv3, we've found we need to add another exception along with echo -n -- that we need the (non-interactive part of the) UP featureset in order to ensure the type command is available. It's also a lot of work to do heaps of other useful things in Debian: make it release faster, improve it's security, have all the neat new GUI apps get a similar degree of reliability as our server programs tend to have, I'm sorry; is woody not released because I'm not spending my time working on GUI apps? Huh? Why would you think that? Debian will be better if it releases faster. Debian will be better if it's security improves. Debian will be better if all the neat new GUI apps blahblahblah. Does it make more
Re: RFD: Essential packages, /, and /usr
Are you referring to the extra new line that ash outputs after an alias? If so that is indeed incorrect and will be fixed. I also interpret the leading literal alias to be incorrect. It's less useful, at any rate. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
I don't really care whether it should or shouldn't be so, but it certainly seems like it *is* so. Using bash minimises the disk space used by shells and is the most reliable, and using ash is faster. Are there any other benefits to be had by using different shells? Using pdksh will give you better POSIX compliance, though it looks as though Herbert is working to solve this as we speak. Using posh will give you better POSIX compliance and facilitate system breakage. Using zsh, well, I don't know why anyone would want to do that. Same goes for ksh93. I'm not really sure why you're being quite so emotive as to call it an arrogant lie. I'd've called it a bug or an underspecification. Potato, potatoe, I guess... So you maintain that policy really says that /bin/sh may be either bash or ash, and nothing else. And in any event that's my point: if you find a case where packages don't match what policy says, you need to bring it up on -devel to make sure it really is policy -- well, your reading of policy -- that's right. I brought up command -v on -devel. What was the outcome of that? And it worked pretty well, don't you think? Allowing people to use ash as well wasn't too huge a step, so we made that. We overreached and thought what we were doing would let people use random other shells as well, but obviously we were wrong. Whether we want to go further is something that we may wish to do, or we may not. As I recall, the ash-blessing was not as pleasant as you imply. (Considering that Linux systems tend not to run non-Linux binaries, that commercial apps tend to not come as shell scripts, and that most Linux distributions come with bash as /bin/sh, I can't say it's a very credible problem) Most commercial apps that I've seen come with shell scripts, yes. Some Linux 2.5 kernels won't compile if /bin/sh is ash. Is the bug in ash? beyond Our users and free software perhaps). Filing release-critical bugs is exactly that, though: forcing everyone to accept your priorities as the most crucial things affecting their package. Sometimes that's You do realize that there's precedent for filing policy violations as serious bugs, right? with. At other times it's just ridiculous: being able to use zsh instead of bash as your /bin/sh might be a neat trick if you're a zsh fanatic, but it isn't any sort of significant practical win to anyone. No, being able to use a POSIX shell instead of bash as your /bin/sh is a significant win. One way you have a clearly defined interface. The other way you have aj saying that really just means bash or ash. No, I won't: what you've done for me is given my a little patch which affects essentially no one, and given me a dozen new bugs in the RC bug list that I'm going to have to go through and downgrade or close. Sorry, but the plusses don't cancel out the minuses. So, in other words, maintainers shouldn't fix bashisms in #!/bin/sh scripts either. With the new POSIX / SUSv3, we've found we need to add another exception along with echo -n -- that we need the (non-interactive part of the) UP featureset in order to ensure the type command is available. We have? type isn't part of UP; type is XSI. Furthermore, if, in fact, we need this exception, it should be added. If, on the other hand, we need policy to say scripts must be compatible with both ash and bash, then the UP and XSI stuff is irrelevant. Huh? Why would you think that? Debian will be better if it releases faster. Debian will be better if it's security improves. Debian will be better if all the neat new GUI apps blahblahblah. Does it make more sense if I spell it out as separate sentences? And really, none of the above have much to do with getting woody out at this point in time, either. This entire paragraph makes even less sense to me. Well, you're welcome to enlighten me at any time. Do you see a problem with a policy of packages only need to work for the maintainer? It also violates a should directive in the previous sentence, and considering the second sentence is just a restatement of the first, that means policy's buggy. The correct resolution, the one that leads to the better distribution, is the one that resolves both those directives to being should. Why haven't you filed such a bug against policy? I think you should not, actually, since changing both to should would make the whole concept utterly pointless. Perhaps you see value in the following scenario: aj uses bashisms which don't work in ash in all his #!/bin/sh scripts. Clint uses ashisms which don't work in ash in all his #!/bin/sh scripts. Apparently, now, neither shell can be used as /bin/sh. Both file bugs, and are told to fuck off. Everybody wins. Sure, and you can do that with ash already, which is 82kB compared to 394kB for zsh. You can't do it incredibly reliably because scripts are allowed to randomly use bash wherever they want to. Occasionally, citizens of certain countries
Re: RFD: Essential packages, /, and /usr
On Thu, Jun 20, 2002 at 08:24:21AM -0400, Clint Adams wrote:
Are you referring to the extra new line that ash outputs after an alias?
If so that is indeed incorrect and will be fixed.
I also interpret the leading literal alias to be incorrect. It's
less useful, at any rate.
In the case of command -v, the alias prefix is required.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
In the case of command -v, the alias prefix is required. Reference? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
On Thu, Jun 20, 2002 at 11:32:34PM -0400, Clint Adams wrote:
In the case of command -v, the alias prefix is required.
Reference?
9989 * An alias shall be written as a
command line that represents its alias definition.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
On Tue, Jun 18, 2002 at 03:56:12AM -0400, Clint Adams wrote:
I'd be happy with SUSv3, UP relevant to non-interactive use, and the
appropriate subset of XSI. Of course, you realize that this reverses
the 'echo -n' exception and that people will cry.
I have nothing against keeping the echo -n clause.
The other problem, then, is that we will have a situation wherein no shell
in Debian would be suitable as /bin/sh (unless I'm assuming incorrectly
about pdksh).
Please be more specific.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
Clint Adams [EMAIL PROTECTED] wrote:
Apparently due to sleep-deprivation, I confused Herbert's assertion with
fact. It's set -h that's forbidden. Debian does not need XSI for set -e.
I appologise for this incorrect assertion. I had misread the canonical
form of set. set -e is indeed specified by POSIX.
However, I still maintain that XSI extensions should be specified when it
comes to Debian's /bin/sh:
1. All the existing shells are already compliant AFAIK.
2. There are some features which are regularly used in maintainer
and other scripts which depend on them, e.g.,
the options -a and -o, as well as parentheses for the
test command or [.
the obsolescent forms of kill and trap: kill -INT or kill -9.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
On Wed, Jun 19, 2002 at 02:00:36AM -0400, Clint Adams wrote:
Please be more specific.
ash:
does not handle multiple heredocs
Thanks, this will be fixed.
read-write fd's do not behave usefully[1]
Not specified by POSIX.
treats $10 as ${1}0
Forbidden by POSIX:
1358 interpreted as a decimal value, even if there is a leading ze
ro. When a positional parameter with
1359 more than one digit is specified, the application shall enclo
se the digits in braces (see Section
1360 2.6.2 (on page 2239)).
does not support cd -L
does not support cd -P
It's on my todo list.
echo -n
Required by the current Debian Policy. Trivial to change should we
ever head in that direction.
incorrect output for command -v
The exact output of command -v is not given by POSIX.
incorrect output for alias
More details please.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
2. There are some features which are regularly used in maintainer and other scripts which depend on them, e.g., the options -a and -o, as well as parentheses for the test command or [. the obsolescent forms of kill and trap: kill -INT or kill -9. I've already filed some bugs on 'trap'-misusing packages. test -a, -o, and parentheses could easily be replaced by and-or listse -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
On Wed, Jun 19, 2002 at 02:26:35AM -0400, Clint Adams wrote:
I've already filed some bugs on 'trap'-misusing packages.
test -a, -o, and parentheses could easily be replaced by and-or listse
Sure, so could command -v. The problem is with the amount of scripts
that use them.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
Forbidden by POSIX: I see. I'll correct the test. The exact output of command -v is not given by POSIX. I believe it says When the -v option is specified, standard output shall be formatted as: %s\n, pathname or command Am I looking in the wrong place? More details please. %s=%s\n, name, value -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
I'm surprised by how many package scripts use kill, but the number is not excessive. On the other hand, no one seems to want to fix these. Instead of a one-line fix, histrionics, bug-closings, and references to Solaris seem to be in order. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
On Wed, Jun 19, 2002 at 05:20:19AM -0400, Clint Adams wrote: I'm surprised by how many package scripts use kill, but the number is not excessive. On the other hand, no one seems to want to fix these. Imagine, people actually wanting a justification beyond random document X says so for bugs filed at a serious severity. Instead of a one-line fix, histrionics, bug-closings, and references to Solaris seem to be in order. See, this would be an example of using policy as a stick to beat people with. That some document somewhere -- be it POSIX, SUS, the LSB spec, or debian-policy -- says you should do something one way means *absolutely nothing*. The *only* reason to do things one way instead of another is because doing them that way is *more effective*. debian-policy is *only* useful in that almost all of its comments are time-tested instructions on how to do things in the most effective way. If you really want a document that says what features of the shell we rely on, that's fine: write one. Base it on SUS, or POSIX as necessary, but don't pretend POSIX or SUS is correct as it stands, least of all when you find evidence that *directly contradicts* such an assumption. Perhaps policy isn't a stick isn't the best way of phrasing these things, maybe a better way of phrasing it is policy isn't the law. Every time we find a contradiction between what we think is the right way of doing things and what policy, POSIX, or whatever says, policy should be put on trial just as much as any given developer. Surely we're all here looking for the *right* way to do things, not merely the documented way. Cheers, aj, getting sick of regretting anew the link between policy and release-criticalness everytime there's any sort of thread on -policy -- 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 pgpf27aWzNWPw.pgp Description: PGP signature
Re: RFD: Essential packages, /, and /usr
Imagine, people actually wanting a justification beyond random document X says so for bugs filed at a serious severity. How about I litter all my #!/bin/sh postinsts with useless zshisms? Then when people file bugs, I say Haha, fuck you; it works for me. debian-policy -- says you should do something one way means *absolutely nothing*. The *only* reason to do things one way instead of another is because doing them that way is *more effective*. I see. You don't see adhering to standards as being effective. Let's see. Scenario A: Anthony Towns puts kill -s KILL $pid in preinst of netkit-inetd. Script works on all POSIX-compliant shells. Scenario B: Anthony Towns puts kill -9 $pid in preinst of netkit-inetd. Script BREAKS on some POSIX-compliant shells. Why is one choice not obviously preferable to the other? debian-policy is *only* useful in that almost all of its comments are time-tested instructions on how to do things in the most effective way. No. That would be a best practices document. Policy is useful in that it ensures consistency and interoperability. Or are you suggesting that the policy document is really just a shadow of some real policy that exists only in the minds of the developers? If you really want a document that says what features of the shell we rely on, that's fine: write one. Base it on SUS, or POSIX as necessary, but don't pretend POSIX or SUS is correct as it stands, least of all when you find evidence that *directly contradicts* such an assumption. The only evidence I see that directly contradicts such an assumption is the dearth of shell features mandated. Perhaps policy isn't a stick isn't the best way of phrasing these things, maybe a better way of phrasing it is policy isn't the law. Every time we find a contradiction between what we think is the right way of doing things and what policy, POSIX, or whatever says, policy should be put on trial just as much as any given developer. Fine. That doesn't mean you should go around pretending that there's an exemption for 'kill -9' in Policy. Surely we're all here looking for the *right* way to do things, not merely the documented way. Of course. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
On Wed, Jun 19, 2002 at 07:59:33AM -0400, Clint Adams wrote: Imagine, people actually wanting a justification beyond random document X says so for bugs filed at a serious severity. How about I litter all my #!/bin/sh postinsts with useless zshisms? How about we add I'm not such an idiot to break my packages just because I get in an argument with aj? to the new-maintainer PP check? Scenario A: Anthony Towns puts kill -s KILL $pid in preinst of netkit-inetd. Script works on all POSIX-compliant shells. Scenario B: Anthony Towns puts kill -9 $pid in preinst of netkit-inetd. Script BREAKS on some POSIX-compliant shells. Scenario A: Script works on bash and ash, which are the two main shells anyone has a reason to use as /bin/sh on Debian. Scenario B: Script works on bash and ash, which are the two main shells anyone has a reason to use as /bin/sh on Debian. Why is one choice not obviously preferable to the other? Because you're biasses don't happen to be mine. It happens to be a lot of work to make something comply with the letter of POSIX's minimal specification for /bin/sh, especially since it seems to be intent on becoming more minimal as time passes, and since it doesn't seem to worry itself too much with existing BSD or Linux systems. It's also a lot of work to do heaps of other useful things in Debian: make it release faster, improve it's security, have all the neat new GUI apps get a similar degree of reliability as our server programs tend to have, and a bunch of other things. I can see obvious benefits from the latter, I can't see *any* benefits from being as obsessive as you're being with the former. Well, no, that's not really true. I don't mind having random scripts work on random other Unices, that's neat. And I wouldn't overly mind if you'd taken the time to do a little polite write up of why kill -9 isn't something we should do, post it to -devel along with citations people can easily check to the appropriate standards, and then file minor or wishlist bugs about it. Because, to be blunt, there are a million things that're a million times more important than whether you can use something other than bash as /bin/sh. debian-policy is *only* useful in that almost all of its comments are time-tested instructions on how to do things in the most effective way. No. That would be a best practices document. Which is what policy is, if you ask me. Policy is useful in that it ensures consistency and interoperability. No, the professionalism and commitment to excellence of Debian maintainers is what ensures that. If you really want a document that says what features of the shell we rely on, that's fine: write one. Base it on SUS, or POSIX as necessary, but don't pretend POSIX or SUS is correct as it stands, least of all when you find evidence that *directly contradicts* such an assumption. The only evidence I see that directly contradicts such an assumption is the dearth of shell features mandated. Perhaps you should look again at all the packages you've been filing bugs against. If you make /bin/sh something else, and lots of stuff breaks, that's evidence that you're missing a needed feature. You do realise we use policy as an aid to developing a distribution, not develop a distribution as an aid to writing policy, right? Perhaps policy isn't a stick isn't the best way of phrasing these things, maybe a better way of phrasing it is policy isn't the law. Every time we find a contradiction between what we think is the right way of doing things and what policy, POSIX, or whatever says, policy should be put on trial just as much as any given developer. Fine. That doesn't mean you should go around pretending that there's an exemption for 'kill -9' in Policy. That's nice. In future, before filing bugs against a bunch of packages for something you think's a policy violation, gain a consensus on -devel about it first. It's a simple rule, and it prevents a lot of annoyance. You'd think the people who insist on rules being followed to the letter would bother to read and follow them themselves, no? 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 pgpQoKxZNQ1aC.pgp Description: PGP signature
Re: RFD: Essential packages, /, and /usr
Scenario A: Script works on bash and ash, which are the two main shells anyone has a reason to use as /bin/sh on Debian. Scenario B: Script works on bash and ash, which are the two main shells anyone has a reason to use as /bin/sh on Debian. Why on earth should this be so? Is saying The standard shell interpreter `/bin/sh' can be a symbolic link to any POSIX compatible shell, if `echo -n' does not generate a newline. yet another of Policy's arrogant lies? How are users to know that this is a farce? It's only a farce, mind you, because of people who think compliance is a bore. When I joined Debian, bash was the only choice for /bin/sh. Back then, one would have said, Script works on bash, which is the only shell anyone as a reason to use as /bin/sh on Debian, and we don't support anything else. Now, those poor people who read Policy or debconf messages might come to the silly conclusion that they could make pdksh or zsh their /bin/sh. Or perhaps they will obtain a copy of ksh93 and make that their /bin/sh. Perhaps that are even forced to do that to support some horribly-behaved commercial software. Some developers want our users to have this choice. Others don't have this as a priority. It happens to be a lot of work to make something comply with the letter of POSIX's minimal specification for /bin/sh, especially since it seems to Then you'll appreciate that I did the work for you and gave you a POSIX-compliant alternative in the bug report. be intent on becoming more minimal as time passes, and since it doesn't seem to worry itself too much with existing BSD or Linux systems. I don't get that impression. POSIX actually seems to be improving with time. It's also a lot of work to do heaps of other useful things in Debian: make it release faster, improve it's security, have all the neat new GUI apps get a similar degree of reliability as our server programs tend to have, I'm sorry; is woody not released because I'm not spending my time working on GUI apps? and a bunch of other things. I can see obvious benefits from the latter, I can't see *any* benefits from being as obsessive as you're being with the former. Mind-boggling, that. Well, no, that's not really true. I don't mind having random scripts work on random other Unices, that's neat. And I wouldn't overly mind if you'd taken the time to do a little polite write up of why kill -9 isn't something we should do, post it to -devel along with citations people can easily check to the appropriate standards, and then file minor or wishlist bugs about it. Why do you think the bug severity levels are lies too? It violates a must directive. If you really believe that the 'must' is a typo, why don't you reopen the bug and reassign it to debian-policy where that typo can be corrected? Because, to be blunt, there are a million things that're a million times more important than whether you can use something other than bash as /bin/sh. No, it's the absolute most important thing in the two universes. Have you ever had need to put Debian on a small amount of flash, and wanted to be as space-efficient as possible? If you have only packages that use #!/bin/sh scripts, you can get rid of the Essential bash, and save over 400K. If you have inside knowledge that these scripts have ashisms, you can avoid the headaches which would plague you had you believed Debian's policy document. Which is what policy is, if you ask me. This is also probably why you think violations of 'must' directives should get priority 'wishlist' bugs. No, the professionalism and commitment to excellence of Debian maintainers is what ensures that. Well, since we can't get that, perhaps we should set some sort of policy. Perhaps you should look again at all the packages you've been filing bugs against. If you make /bin/sh something else, and lots of stuff breaks, that's evidence that you're missing a needed feature. No, it's evidence that stuff isn't POSIX-compliant like it claims to be. A feature is needed just because someone uses it? kill -9 is needed because you don't want to type -s ? That's nice. In future, before filing bugs against a bunch of packages for something you think's a policy violation, gain a consensus on -devel about it first. It's a simple rule, and it prevents a lot of annoyance. I think that you're the only one who has bothered to claim that it's not a policy violation to violate policy. You'd think the people who insist on rules being followed to the letter would bother to read and follow them themselves, no? Manoj told me to file bugs; I didn't get the impression that he thought must was a typo. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
Steve == Steve Greenland [EMAIL PROTECTED] writes: Steve I wasn't discussing any particular command, and Manoj didn't Steve mention the FHS. I think if we (Debian) said Early running Steve init scripts can count on the FHS required commands being in Steve /bin:/sbin, and anything else might be in /usr/bin:/usr/sbin, Steve then Branden and I would be satisfied: at least we would know Steve where we stand. Manoj and Anthony have argued (to my Steve understanding) that the current situation of Early running Steve init scripts can on on whatever the maintainers feel like Steve putting in /bin:/sbin is acceptable. To me, it seems sloppy. Since when have we stopped depending on the competence and common sense of our fellow developers, and ossifying into a bureaucracy limited by, and drawing its power from, words writ in stone? Branden, of all people, is a strange bed fellow for such arguments. Are we not all agreed that additions to / need be made with a great deal of thought and care, and perhaps we can expect our fellow developers to exercise a modicum of care? manoj -- A beginning is the time for taking the most delicate care that balances are correct. Princess Irulan, Manual of Maud'Dib Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
Moshe == Moshe Zadka [EMAIL PROTECTED] writes: Moshe I may be just stupid, ;-) Moshe but what does /usrness[1] have to do with embedded systems? Moshe After all, if the embedded system has no disk space for (say) If you disallow things like this by axiom, you can prove whatever you wish to. Moshe X, it has no space for X on either / or /usr. Or is it a Moshe common case in embedded systems to mount /usr/ on a much Moshe larger medium? Consider the ipaq: smallish built in ram, has expansion packs to add /usr on. Moshe The embedded systems argument sounds *extremely* relevant Moshe for Essentiality (we've talked about this), but completely Moshe *irrelevant* for /usrness? I think not. Just because it is an embedded system does not preclude extensibility. Adding unnecessary limitations to what you imagine merely limits what you can do. manoj -- If you can't be good, be careful. If you can't be careful, give me a call. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
Steve == Steve Greenland [EMAIL PROTECTED] writes: Steve On 16-Jun-02, 22:04 (CDT), Manoj Srivastava [EMAIL PROTECTED] wrote: Having an explicit, separate documentation of technical things that has to be maintained, or else it slips out of synchronization with reality, is certainly not to be preferred to haveing a deterministic way of inferring such information. Steve But it's not a reliable prediction. It's simply a repoort on Steve the present situation. There's nothing to prevent things from Steve being moved out of /bin (except those subject to the Steve FHS). Except to break compatibility, and to change a public interface to the system. Such changes are never made lightly, and if it is expected that debian developers exercise such piss poor judgment we may as well give up and migrate to another OS. Steve Additionally, a list of these tools are guaranteed to Steve be available before /usr is mounted is not the same as a list Steve of these are the tools from Essential packages that are in Steve /bin:/sbin, and need not be particularly fluid. I fail to see a technical reason behind this statement of opinion. Any canonical list would require maintainence and perhaps central control, I see no reason why such ossification gains us anything. If I have an early running package, I look at what I need in /bin and /sbin; and depend on the non-essential packages providing the tools. I also trust, and depend on, the competence of my felloow developers not to move things out. Steve Because it's not reliable. At least some portion of it is Steve subject to the random whims of the package maintainers (or, Steve far more likely, the random whims of bug reporters and a Steve package maintainer who is (understandably) unaware that a few Steve of Debian's umpteen thousand packages rely on that particular Steve binary being in /bin). If we have become the cess pit of such incompetence, we may as well give up, and no set of rules would stave off the mould and decay that shall inhabit the misasma that the OS would have become. manoj -- You can't get very far in this world without your dossier being there first. Arthur Miller Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
I do not see why we should use which. As I have stated previously, we already require feature sets (set -e in particular) in the new POSIX document which imply the existence of type(1). So type should be Can we codify this better? the preferred utility for this task. Besides, as an external utility, which(1) does not know about shell builtins, which is actually bad. This depends on the user's perspective. I can't imagine ever wanting to do anything other than 'test -x /absolute/path' in a postinst. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
On Tue, Jun 18, 2002 at 01:00:25AM -0400, Clint Adams wrote: This depends on the user's perspective. I can't imagine ever wanting to do anything other than 'test -x /absolute/path' in a postinst. I can. I just want to know if the command is available for my script to use; I don't care about the latest flamewar that moved it in or out of /usr or */sbin. -- G. Branden Robinson| Mob rule isn't any prettier just Debian GNU/Linux | because you call your mob a [EMAIL PROTECTED] | government. http://people.debian.org/~branden/ | pgpXl4ubDG2uE.pgp Description: PGP signature
Re: RFD: Essential packages, /, and /usr
On Tue, Jun 18, 2002 at 01:00:25AM -0400, Clint Adams wrote:
I do not see why we should use which. As I have stated previously, we
already require feature sets (set -e in particular) in the new POSIX
document which imply the existence of type(1). So type should be
Can we codify this better?
Certainly,
SUSv3
+
XSI (needed for set -e and other features)
The latter specifies type.
I would also support the addition of UP since all the POSIX shells in
Debian support it with the exception of ash which does not currently
support history. Since history support is unlikely to affect scripting,
it would be acceptable for us to specify UP as well as XSI.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
Clint == Clint Adams [EMAIL PROTECTED] writes: I do not see why we should use which. As I have stated previously, we already require feature sets (set -e in particular) in the new POSIX document which imply the existence of type(1). So type should be Clint Can we codify this better? Codify what, please? I personally use which, since it is provided by am essential package, and I can live with it eing an external program, and missing aliases. People can also use POSIX type (umm, does zsh have type?). Why does this have to be codified? When do we want to stop codifying every little thing? Clint This depends on the user's perspective. I can't imagine ever Clint wanting to do anything other than 'test -x /absolute/path' in Clint a postinst. I would possibly classify hard coded paths a bug in the package, since I may well be experimenting with PATH's. But hard coding paths is just asking for breakage, in case the FHS or the LSB or someone decrees the binary move. Since there is no need for such hard coded paths, doing so is bad design. manoj -- What is wanted is not the will to believe, but the will to find out, which is the exact opposite. Bertrand Russell, Skeptical Essays, 1928 Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
I can. I just want to know if the command is available for my script to use; I don't care about the latest flamewar that moved it in or out of /usr or */sbin. You are searching for a particular word, and that word may represent a binary/script, a shell function, a shell alias, a shell builtin. There may be many of the aforementioned things with the same name. No mechanism exists to determine whether or not these things perform similar actions or have similar interfaces. Let's say that I want to run deathrampage in my postinst. deathrampage is a binary in a package of the same name, and this is the deathrampage that I wish to have executed. There are many ways for me to check for it: (A) deathrampage || echo uh-oh, continuing without it Advantages: portable Disadvantages: requires running the program in question (B) test -x /usr/sbin/deathrampage /usr/sbin/deathrampage Advantages: portable, will not execute the wrong deathrampage unless someone has placed an impostor in /usr/sbin Disadvantages: will fail silently if deathrampage is moved to /usr/bin (C) multiple tests, or loop of tests Advantages: portable, will handle multiple finite locations Disadvantages: will fail silently if deathrampage is moved beyond the finite list of locations (D) command -v deathrampage 2/dev/null deathrampage OR type deathrampage 2/dev/null deathrampage Advantages: will find and execute deathrampage anywhere Disadvantages: will find and execute deathrampage anywhere, no matter if it is an alias to 'rm -rf /', a shell function that initiates immediate reboot, or some other bizarre and unexpected thing. Not POSIX-compliant. (E) which deathrampage 2/dev/null command deathrampage Advantages: will find and execute deathrampage on the command search path. Disadvantages: not standardized at all. builtin which's will not likely have the same interface. (F) /usr/bin/which deathrampage 2/dev/null command deathrampage Advantages: will find and execute deathrampage on the command search path. Disadvantages: requires faith in /usr/bin/which not moving or changing (G) dpkg -S deathrampage some other stuff Advantages: will only find deathrampages tracked by the Debian packaging system. Disadvantages: slow and cumbersome (H) #!/bin/specific shell, and use known whence, which, type commands Advantages: no portability problems, and you might get exactly what you want Disadvantages: annoying to users everywhere (I) invent a Debian-specific solution to this problem Advantages: less confusion Disadvantages: requires cognition, and people seem to feel differently about whether or not they want random shell aliases, functions, and binaries in /usr/local being executed by package scripts. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
I would also support the addition of UP since all the POSIX shells in Debian support it with the exception of ash which does not currently support history. Since history support is unlikely to affect scripting, it would be acceptable for us to specify UP as well as XSI. I'd be happy with SUSv3, UP relevant to non-interactive use, and the appropriate subset of XSI. Of course, you realize that this reverses the 'echo -n' exception and that people will cry. The other problem, then, is that we will have a situation wherein no shell in Debian would be suitable as /bin/sh (unless I'm assuming incorrectly about pdksh). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
On Tue, Jun 18, 2002 at 03:50:23AM -0400, Clint Adams wrote: (F) /usr/bin/which deathrampage 2/dev/null command deathrampage Advantages: will find and execute deathrampage on the command search path. Disadvantages: requires faith in /usr/bin/which not moving or changing (H) #!/bin/specific shell, and use known whence, which, type commands Advantages: no portability problems, and you might get exactly what you want Disadvantages: annoying to users everywhere Since /usr/bin/which is a /bin/bash script, it shares the disadvantage of (H). More so, because now you're running *two* shells whereas a #!/bin/bash script would only need one :) The irony is that the only reason to use which is to accomodate speed freaks who want to be able to use non-bash shells. Now they get hit by the bash startup time anyway. And those same speed freaks are likely to be using ash, which has both type and command -v. I once again recommend a deathmatch between ash and zsh fans. Let the best shell win. Richard Braakman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
Codify what, please? I personally use which, since it is provided by am essential package, and I can live with it eing an external program, and missing aliases. People can also use POSIX type You don't have that with zsh, since which is a builtin. (umm, does zsh have type?). Why does this have to be codified? When zsh has type as a builtin, though it isn't POSIX either. do we want to stop codifying every little thing? When there are no more problems? There are numerous #!/bin/sh scripts in Debian that are not POSIX-compliant. One might get the idea, if one were to read Debian's policy documents, that these scripts violate Policy. One might also get the idea, if one were to read the same section, that one could install a POSIX-compliant shell as /bin/sh on one's Debian system, and that one would experience no difficulties in doing so. Of course, this is a fallacy. What is the common sense thing to do? I would say that it's to have bash as /bin/sh, since that's what most maintainers are using, and that's what's most likely to work with the most scripts. I, on the other hand, would rather have ash as /bin/sh. What makes this possible? That policy has codified the requirement for /bin/sh scripts to be POSIX-compliant, and ash, for the most part, does a good job executing POSIX-compliant scripts. If this were not codified, and we were still living in the dark ages when someone would be lynched for using ash as /bin/sh and having the gall to expect sympathy, then well, lynching would be the least of problems. I would possibly classify hard coded paths a bug in the package, since I may well be experimenting with PATH's. But hard coding paths is just asking for breakage, in case the FHS or the LSB or someone decrees the binary move. Since there is no need for such hard coded paths, doing so is bad design. And not doing so invites unexpected behaviors. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
The irony is that the only reason to use which is to accomodate speed freaks who want to be able to use non-bash shells. Now they get hit by the bash startup time anyway. And those same speed freaks are likely to be using ash, which has both type and command -v. I believe that Herbert's proposal solves this. I once again recommend a deathmatch between ash and zsh fans. Let the best shell win. bash doesn't even get to compete? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
Clint == Clint Adams [EMAIL PROTECTED] writes: Clint (A) deathrampage || echo uh-oh, continuing without it Clint Advantages: portable Clint Disadvantages: requires running the program in question But if you doi want to run it, this is it,, end of story. So, now for when we want to merely test for presence. Clint (B) test -x /usr/sbin/deathrampage /usr/sbin/deathrampage Clint Advantages: portable, will not execute the wrong deathrampage unless Clint someone has placed an impostor in /usr/sbin Clint Disadvantages: will fail silently if deathrampage is moved to /usr/bin Disadvantage: prevents the local sysadmin from using the common UNIX practice of modifying the environment by rearrranging the path, is not needed anyway since A would have worked, redundant. Clint (C) multiple tests, or loop of tests Clint Advantages: portable, will handle multiple finite locations Clint Disadvantages: will fail silently if deathrampage is moved beyond the Clint finite list of locations Also silly, since A would work. Clint (D) command -v deathrampage 2/dev/null deathrampage Clint OR type deathrampage 2/dev/null deathrampage Clint Advantages: will find and execute deathrampage anywhere Clint Disadvantages: will find and execute deathrampage anywhere, no matter if Clint it is an alias to 'rm -rf /', a shell function that Clint initiates immediate reboot, or some other bizarre and Clint unexpected thing. Not POSIX-compliant. So what? Who the hell is the postinst to tell me what I should or should not be doing with my machine? When I change the command on my machines, by gar, stupid postsinst should follow suit. Where does this overweening sense of the postinst always being right, the human who has changed the environment always is wrong coming from? This is certainly not the UNIX philosophy. Silly, since A would have worked. Clint (E) which deathrampage 2/dev/null command deathrampage Clint Advantages: will find and execute deathrampage on the command Clint search path. Clint Disadvantages: not standardized at all. builtin which's will not Clint likely have the same interface. Silly, since A is the correct answer, but what the heck do you mean it is not standardized? POSIX is a standard, you know, and it has indeed standardized this. If we do not need to run the command, this is the answer. which is provided by an essential package. which has a well known standard behaviour. If builtin which does not follow POSIX, file a bug. Clint (F) /usr/bin/which deathrampage 2/dev/null command deathrampage Clint Advantages: will find and execute deathrampage on the command Clint search path. Disadvantages: requires faith in /usr/bin/which Clint not moving or changing Silly, since either A or E would do the trick. Clint (G) dpkg -S deathrampage some other stuff Clint Advantages: will only find deathrampages tracked by the Debian Clint packaging system. Clint Disadvantages: slow and cumbersome This is not just silly, this is moronic, and wrong. Clint (H) #!/bin/specific shell, and use known whence, whwich, type Clint #commands Clint Advantages: no portability problems, and you might get exactly Clint what youwant Clint Disadvantages: annoying to users everywhere SIlly, since A or would work. Clint (I) invent a Debian-specific solution to this problem Clint Advantages: less confusion Clint Disadvantages: requires cognition, and people seem to feel differently Clint about whether or not they want random shell aliases, functions, and Clint binaries in /usr/local being executed by package scripts. Oh yeah, the Not Invented Here syndrome. POSIX exists, and works for everyone else except Debian. Can we please take this silly thread off policy now? manoj -- Perhaps the best way to characterize the relationship between DNA and meaning is to say that DNA is the source of meaning. It takes information about the environment and turns it into behaviour - thus realizing meaning in the pragmatic sense of the word. DNA is the place where the two sides of meaning meet, the place where reports become instructions. DNA is thus what first gave meaning to life; or, perhaps, what first created meaning, and therefore life, or what first created life, and therefore meaning. In any event, it is very impressive stuff. Robert Wright, Three Scientists and Their Gods Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
But if you doi want to run it, this is it,, end of story. So, now for when we want to merely test for presence. Perhaps if you want to test for multiple commands before executing them? So what? Who the hell is the postinst to tell me what I should or should not be doing with my machine? When I change the command on Apparently if you have zsh as /bin/sh and try to install xdm, the postinst will happily tell you what version of debianutils to install to get readlink. my machines, by gar, stupid postsinst should follow suit. Where does this overweening sense of the postinst always being right, the human who has changed the environment always is wrong coming from? This is certainly not the UNIX philosophy. If you wanted to replace the update-menus command, you would have much more success by dpkg-diverting it rather than putting your replacement in /usr/local/bin. I don't believe anything guarantees that the latter will work, whereas the former is a good bet. Silly, since A is the correct answer, but what the heck do you mean it is not standardized? POSIX is a standard, you know, and it has indeed standardized this. It has not. The closest POSIX comes to which is to mention that it came from csh. If we do not need to run the command, this is the answer. which is provided by an essential package. which has a well known standard behaviour. Does it? Last I checked the manpage did not accurately reflect the actual behavior. If builtin which does not follow POSIX, file a bug. First you'll need to get it into POSIX. Silly, since either A or E would do the trick. For all Bournish shells in Debian of which I am aware, yes. Oh yeah, the Not Invented Here syndrome. POSIX exists, and works for everyone else except Debian. Branden, for example, does not appear to be pleased with the options POSIX provides him. Can we please take this silly thread off policy now? I imagine that amending policy would help that end. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
Clint == Clint Adams [EMAIL PROTECTED] writes: Codify what, please? I personally use which, since it is provided by am essential package, and I can live with it eing an external program, and missing aliases. People can also use POSIX type Clint You don't have that with zsh, since which is a builtin. I don't have what? which is present, either as a builtin, or provided by an essential package. What exactly do I not have? (umm, does zsh have type?). Why does this have to be codified? When Clint zsh has type as a builtin, though it isn't POSIX either. Oh? How is it not POSIX? do we want to stop codifying every little thing? Clint When there are no more problems? Then we should stop right here, since that is an impossible goal. Clint There are numerous #!/bin/sh scripts in Debian that are not Clint POSIX-compliant. One might get the idea, if one were to read Clint Debian's policy documents, that these scripts violate Policy. Yes. File bugs. Clint One might also get the idea, if one were to read the same Clint section, that one could install a POSIX-compliant shell as Clint /bin/sh on one's Debian system, and that one would experience Clint no difficulties in doing so. Of course, this is a fallacy. File bugs. fix things. More documents saying this is wrong does not fix any bugs. Policy already talks about POSIX /bin/sh, yet another document just adds to the ossification, and solves nothing. Clint And not doing so invites unexpected behaviors. Yeah, lefe sucvks, doesn't it? And damn Heisenburg. manoj -- You shouldn't make my toaster angry. Household security explained in Johnny Quest Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
I don't have what? which is present, either as a builtin, or provided by an essential package. What exactly do I not have? You don't have a standard interface. Any POSIX-compliant shell could easily implement a 'which' builtin that returns success no matter what. This would not violate POSIX. This would not violate Debian policy. Some postinsts might stop working properly. Common sense might save you on this one. Oh? How is it not POSIX? type is X/Open. Then we should stop right here, since that is an impossible goal. That doesn't necessarily follow. Yes. File bugs. It would be silly to mass-file bugs if there's going to be a modification of policy in the near future. File bugs. fix things. More documents saying this is wrong does not fix any bugs. Policy already talks about POSIX /bin/sh, yet another document just adds to the ossification, and solves nothing. You seem to be happily ignoring the fact that certain people object to the dearth of features in POSIX sh. Yeah, lefe sucvks, doesn't it? And damn Heisenburg. Lefe certainly does sucvk. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
Clint == Clint Adams [EMAIL PROTECTED] writes: But if you doi want to run it, this is it,, end of story. So, now for when we want to merely test for presence. Clint Perhaps if you want to test for multiple commands before Clint executing them? Umm, say what? You mean you want to test for presence of multiple commands and execute one or more? (not something you covered origiannly, but in that case go to case H So what? Who the hell is the postinst to tell me what I should or should not be doing with my machine? When I change the command on Clint Apparently if you have zsh as /bin/sh and try to install xdm, Clint the postinst will happily tell you what version of debianutils Clint to install to get readlink. And what is the root cause of this problem? Seems like this is a bug somewhere, and should be fixed. my machines, by gar, stupid postsinst should follow suit. Where does this overweening sense of the postinst always being right, the human who has changed the environment always is wrong coming from? This is certainly not the UNIX philosophy. Clint If you wanted to replace the update-menus command, you would have much Clint more success by dpkg-diverting it rather than putting your replacement Clint in /usr/local/bin. Yes, if proposals like yours take effect. Stuff that has worked for 30 years in UNIX is just to be tossed aside. NIH. Clint I don't believe anything guarantees that the latter will work, whereas Clint the former is a good bet. Silly, since A is the correct answer, but what the heck do you mean it is not standardized? POSIX is a standard, you know, and it has indeed standardized this. Clint It has not. The closest POSIX comes to which is to mention Clint that it came from csh. Fair enough. It is an utility provided by an essential package, and has a man page. If that is not good enough, use type. Surely people can manage their packages without having everything in policy? Clint I imagine that amending policy would help that end. I am not sure this is likely to happen. I certainly do not see a consensus emerging. You may have better luck getting it into the Best Practices book. manoj -- I believe that if people would learn to use LSD's vision-inducing capability more wisely, under suitable conditions, in medical practice and in conjunction with meditation, then in the future this problem child could become a wonder child. Dr. Albert Hoffman, the discoverer of LSD Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
Umm, say what? You mean you want to test for presence of multiple commands and execute one or more? (not something you covered origiannly, but in that case go to case H I'm hypothesizing. I can think of no real-world examples where I'd need to do anything fancy here. And what is the root cause of this problem? Seems like this is a bug somewhere, and should be fixed. The root cause is POSIX-incompliance in the postinst. 'command -v', in particular. Yes, if proposals like yours take effect. Stuff that has worked for 30 years in UNIX is just to be tossed aside. NIH. No, not if. Now. Try it. You'll get very inconsistent results. Fair enough. It is an utility provided by an essential package, and has a man page. If that is not good enough, use type. Surely people can manage their packages without having everything in policy? If I am filing bugs against scripts that use 'command -v', I'm certainly going to file bugs against those that use 'type'. I am not sure this is likely to happen. I certainly do not see a consensus emerging. You may have better luck getting it into the Best Practices book. I have no interest in getting these extensions mandated. I would prefer that either the scripts or policy move toward the other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
On Tue, Jun 18, 2002 at 04:18:58AM -0400, Clint Adams wrote: I once again recommend a deathmatch between ash and zsh fans. Let the best shell win. bash doesn't even get to compete? bash is sitting contentedly in a corner, with a smug smile that says I am the default /bin/sh and you know it. :-) Richard Braakman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
On Tue, Jun 18, 2002 at 03:50:23AM -0400, Clint Adams wrote: (D) command -v deathrampage 2/dev/null deathrampage OR type deathrampage 2/dev/null deathrampage Advantages: will find and execute deathrampage anywhere Disadvantages: will find and execute deathrampage anywhere, no matter if it is an alias to 'rm -rf /', a shell function that initiates immediate reboot, or some other bizarre and unexpected thing. How are we to prevent this anyway? Who says any of the other solutions can't be botched like this? -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
How are we to prevent this anyway? Who says any of the other solutions can't be botched like this? The difference is that I, as a user, would never expect for a postinst to look for something called deathrampage, and by extension, would never expect for a postinst to suddenly be running the 'deathrampage' script I put in /usr/local/bin for later carnage. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
On Tue, Jun 18, 2002 at 06:02:08AM -0400, Clint Adams wrote: How are we to prevent this anyway? Who says any of the other solutions can't be botched like this? The difference is that I, as a user, would never expect for a postinst to look for something called deathrampage, and by extension, would never expect for a postinst to suddenly be running the 'deathrampage' script I put in /usr/local/bin for later carnage. What if the user puts tripwire or some other nice English word in the path, not knowing this is also a command in Debian? It's really hard to account for any of these weird scenarios... -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
On Tue, Jun 18, 2002 at 06:11:00AM -0400, Clint Adams wrote: What if the user puts tripwire or some other nice English word in the path, not knowing this is also a command in Debian? It's really hard to account for any of these weird scenarios... What if? I also wouldn't expect, nor want, to have Debian package scripts trying to execute some random tripwire program. Notice or some other nice English word... when the admin puts binaries in a $PATH, they need to be aware of the consequences. If they put something in a place where it can replace a Debian binary, how do we know it's intentional or not? If we assume it's unintentional, our scripts need to hardcode paths, which makes moving stuff tedious. If we assume it's intentional, we risk admins having a taste of their own medicine. I'd pick the former. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
Josip == Josip Rodin [EMAIL PROTECTED] writes:
Josip What if the user puts tripwire or some other nice English word in the
Josip path, not knowing this is also a command in Debian? It's really hard to
Josip account for any of these weird scenarios...
If the user has put soemthing in ***ROOT's*** path, they
deserve what hey get -- and they may actually want this to happen.
manoj
--
Date: 19 Apr 90 17:18:27 GMT From: [EMAIL PROTECTED] (Randal
Schwartz) print ('Just ','anoth','er Pe','rl ha','cker,')[0..4]
Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
Clint == Clint Adams [EMAIL PROTECTED] writes: I don't have what? which is present, either as a builtin, or provided by an essential package. What exactly do I not have? Clint You don't have a standard interface. Any POSIX-compliant Clint shell could easily implement a 'which' builtin that returns Clint success no matter what. This would not violate POSIX. This Clint would not violate Debian policy. Some postinsts might stop Clint working properly. Common sense might save you on this one. And heaven forbid we have any in Debian. Oh? How is it not POSIX? Clint type is X/Open. Is POSIX + extention. Then we should stop right here, since that is an impossible goal. Clint That doesn't necessarily follow. Yes, it does. There are never going to be no problems. Yes. File bugs. Clint It would be silly to mass-file bugs if there's going to be a Clint modification of policy in the near future. Unlikely. The best you'll get it POSIX+extention, and that still means command -v is a bashism. File bugs. fix things. More documents saying this is wrong does not fix any bugs. Policy already talks about POSIX /bin/sh, yet another document just adds to the ossification, and solves nothing. Clint You seem to be happily ignoring the fact that certain people object to Clint the dearth of features in POSIX sh. I have no interest in what certain people find pleasing, unless these certain people are identified, and then only after consideration. manoj -- So many men, so many opinions; every one his own way. Publius Terentius Afer (Terence) Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
Clint == Clint Adams [EMAIL PROTECTED] writes: How are we to prevent this anyway? Who says any of the other solutions can't be botched like this? Clint The difference is that I, as a user, would never expect for a Clint postinst to look for something called deathrampage, and by Clint extension, would never expect for a postinst to suddenly be Clint running the 'deathrampage' script I put in /usr/local/bin for Clint later carnage. And I would prefer the command I prefer to be run, as decided by the path argument. When I put something that comes in root's path ahead of the standard path, it is thre for a reason, and I would be extremely irked by some script pretending to know better than I. In other words, if the human has gone out of their way to put a command that precedes the default for root, they should get what they want. period. manoj -- The only solution is ... a balance of power. We arm our side with exactly that much more. A balance of power -- the trickiest, most difficult, dirtiest game of them all. But the only one that preserves both sides. Kirk, A Private Little War, stardate 4211.8 Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
Clint == Clint Adams [EMAIL PROTECTED] writes: What if the user puts tripwire or some other nice English word in the path, not knowing this is also a command in Debian? It's really hard to account for any of these weird scenarios... Clint What if? I also wouldn't expect, nor want, to have Debian Clint package scripts trying to execute some random tripwire Clint program. So why are you putting something in roots path ahead of the standard path unless you want it to be run? Clint I can only imagine the tripwire package running tripwire in its Clint postinst, and I should hope it knows the absolute path. I think that is a bug. manoj -- Q: What's the difference between a car salesman and a computer salesman? A: The car salesman can probably drive! Joan McGalliard ([EMAIL PROTECTED]) Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
Notice or some other nice English word... when the admin puts binaries in a $PATH, they need to be aware of the consequences. If they put something in a place where it can replace a Debian binary, how do we know it's Why would someone, being told that '/usr/local is for the administrator; Debian doesn't touch it' assume that package scripts will go around running things in /usr/local? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
Is POSIX + extention. How is this relevant? Yes, it does. There are never going to be no problems. Oh, I see your logic. Therefore, we should never solve any problems. Unlikely. The best you'll get it POSIX+extention, and that still means command -v is a bashism. Depends on the extensions. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
So why are you putting something in roots path ahead of the standard path unless you want it to be run? Under what circumstances? In which context? root has different paths at different times. I think that is a bug. I think that is a feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
On 17-Jun-02, 21:51 (CDT), Anthony Towns aj@azure.humbug.org.au wrote: It seems sloppy is a pretty poor argument for moving every binary not specifically mentioned in the FHS into /usr and gratuitously breaking any scripts that needed them where they are. Yes, that would be a pretty poor argument, if I had indeed suggested doing that. But I didn't. I haven't made any suggestions about moving anything. All I've suggested is that we list what early running code can rely on, and a couple of different ways to get there. Are you sloppy when you exercise your judgement about your packages? Why would you expect everyone else to be? I don't. However, we already have cases of specific developers being, shall we say, difficult. Not sloppy, but having very strong opinions about how a particular thing should be done, despite a large number of other experienced developers disagreeing. What is the purpose of Debian Policy? I always thought it was a way to decide/document choices, when more than one choice was reasonable, and when that choice affected other developers and our users. This subject falls into that definition, in my opinion. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
On Tue, Jun 18, 2002 at 07:58:21AM -0400, Clint Adams wrote: Notice or some other nice English word... when the admin puts binaries in a $PATH, they need to be aware of the consequences. If they put something in a place where it can replace a Debian binary, how do we know it's Why would someone, being told that '/usr/local is for the administrator; Debian doesn't touch it' assume that package scripts will go around running things in /usr/local? Doesn't touch doesn't imply that the software will be impossible to be run by the system scripts... -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
On Tue, Jun 18, 2002 at 07:58:21AM -0400, Clint Adams wrote:
Notice or some other nice English word... when the admin puts binaries in
a $PATH, they need to be aware of the consequences. If they put something in
a place where it can replace a Debian binary, how do we know it's
Why would someone, being told that '/usr/local is for the administrator;
Debian doesn't touch it' assume that package scripts will go around
running things in /usr/local?
Just because they've been told Debian won't put things in there, that
doesn't mean the things in there won't be run if they're in the PATH.
I don't think anyone would be surprised or dismayed for particularly long
at having, say, /usr/local/bin/dpkg executed instead of /usr/bin/dpkg if
/usr/local/bin happens to be earlier in their PATH. If, as a sysadmin, you
don't ever want that to happen, you should remove /usr/local/{bin,sbin}
(and /opt/bin and whatever else) from your PATH before running
dpkg. That's not overly onerous.
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
pgpBhpzaTtNCR.pgp
Description: PGP signature
Re: RFD: Essential packages, /, and /usr
On Tue, Jun 18, 2002 at 03:56:12AM -0400, Clint Adams wrote: I would also support the addition of UP since all the POSIX shells in Debian support it with the exception of ash which does not currently support history. Since history support is unlikely to affect scripting, it would be acceptable for us to specify UP as well as XSI. I'd be happy with SUSv3, UP relevant to non-interactive use, and the appropriate subset of XSI. Of course, you realize that this reverses the 'echo -n' exception and that [...] ...you therefore have to say SUSv3, UP-noninteractive, XSI-something, and a BSD echo (ie, with a functioning -n). There're probably other exceptions too. Compatability with what we're distributing, compatability with other distributions, compatability with other free Unices are all more important than blind adherance to the standard du jour. 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 pgpDpz4GFr3Wh.pgp Description: PGP signature
Re: RFD: Essential packages, /, and /usr
Richard Braakman wrote: The irony is that the only reason to use which is to accomodate speed freaks who want to be able to use non-bash shells. Now they get hit Or wackos who code using tcsh. :) (yes, i know about the csh programming considered harmful. I guess I'll just use perl instead.) -- Scott Dier [EMAIL PROTECTED] http://www.ringworld.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
Clint == Clint Adams [EMAIL PROTECTED] writes: Clint Why would someone, being told that '/usr/local is for the Clint administrator; Debian doesn't touch it' assume that package Clint scripts will go around running things in /usr/local? The scripts should not, and this is why hard codiong paths is a bug. manoj -- Bushydo -- the way of the shrub. Bonsai! Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
Josip == Josip Rodin [EMAIL PROTECTED] writes: Josip Notice or some other nice English word... when the admin Josip puts binaries in a $PATH, they need to be aware of the Josip consequences. If they put something in a place where it can Josip replace a Debian binary, how do we know it's intentional or Josip not? If we assume it's unintentional, our scripts need to Josip hardcode paths, which makes moving stuff tedious. If we assume Josip it's intentional, we risk admins having a taste of their own Josip medicine. I'd pick the former. You reversed the order from the sentence: how do we know it's intentional or not? and the rest of the explanation, so it is hard to know which one option you prefer (at least, I am fairly unclear). I, for one, prefer not to think of my admin as incompetent bozos, and I would prefer to give them the benefit of doubt, and assume they know the situation better than a script does. I prefer to let the sysadmin be empowered to modify what happens on their machine the traditional UNIX way, by placing binaries in paths. manoj -- SHOP OR DIE, people of Earth! [offer void where prohibited] Capitalists from outer space, from Justice League Int'l comics Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
Clint == Clint Adams [EMAIL PROTECTED] writes: So why are you putting something in roots path ahead of the standard path unless you want it to be run? Clint Under what circumstances? In which context? root has different paths Clint at different times. Are you being delibrately obtuse? Is this soem arcane debating ploy? Or have you suddenly developed amnesia and no longer remember the context this discussion is taking place in? I think that is a bug. Clint I think that is a feature. I have shown in a companion message why this should be considered a bug. manoj -- If your lover doesn't like garlic, get a new lover. Jeff Smith, The Frugal Gourmet Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
Clint == Clint Adams [EMAIL PROTECTED] writes: Is POSIX + extention. Clint How is this relevant? Yes, it does. There are never going to be no problems. Clint Oh, I see your logic. Therefore, we should never solve any problems. Managing to rember context does not seem to be your strong point. If you recall (well, perhaps you can't), this particual exchange started when I asked how long should we keep ossifying ourselves by creating writs in stone, if there was an end criteria, and you are the one who came up with the pie in the sky ``when there are no problems''. Since you manage to forget context from message to message, I guess it makes a weird kind of sense that now you attribute statements like the above to your opponents. I suggest you keep these messages around, and peruse them prior to drafting a reply, so the context is in yourshort term memory. Unlikely. The best you'll get it POSIX+extention, and that still means command -v is a bashism. Clint Depends on the extensions. XSI. IEEE Std 1003.1-2001 describes utilities, functions, and facilities offered to application programs by the X/Open System Interface (XSI). Functionality marked XSI is also an extension to the ISO C standard. Application writers may confidently make use of an extension on all systems supporting the X/Open System Interfaces Extension. manoj -- Crab apples may not be the best kind of fruit; but a tree which every year bears a great crop of crab apples is better worth cultivating than a tree which bears nothing. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
Steve == Steve Greenland [EMAIL PROTECTED] writes: Steve I don't. However, we already have cases of specific developers being, Steve shall we say, difficult. Not sloppy, but having very strong opinions Steve about how a particular thing should be done, despite a large number of Steve other experienced developers disagreeing. Steve What is the purpose of Debian Policy? It certainly is not a stick to beat difficult developers on the head with. Steve I always thought it was a way to decide/document choices, when Steve more than one choice was reasonable, and when that choice Steve affected other developers and our users. This subject falls Steve into that definition, in my opinion. But that ought not to translate into ``every possible source of contention between developers is writ in stone in a static document, precluding any case by case mitigating factors, and not requiring common sense and human judgment. In my opinion, it is going to be vcry hard to come up with a criteria that defines / and /usrness, one which can be predectively used for the future, and one that takes into account the shifting reality of real world hardware, and real world usage. Human judgment. There still is a need for it, and this, I think, is one such case -- this is why robots have not yet taken over the world (that,, and, of course, the 3 laws of robotics). manoj -- Date: 20 Mar 90 01:21:37 GMT From: [EMAIL PROTECTED] (Randal Schwartz) $_=',Pr0e=kRcza0hb 5lOr+ePE :rBe}hRtho]nhaj nt.s[u=J@';s/../unshift(a,$)/eg;chop(@a);[EMAIL PROTECTED]; Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
On Tue, Jun 18, 2002 at 05:14:23AM -0400, Clint Adams wrote:
Apparently if you have zsh as /bin/sh and try to install xdm, the
postinst will happily tell you what version of debianutils to install to
get readlink.
?
First I've heard of this. What's going on?
Oh, I know.
if ! command -v readlink /dev/null 21; then
message The readlink command was not found. Please install version \
1.13.1 or later of the debianutils package.
readlink () {
# returns what symlink in $1 actually points to
perl -e '$l = shift; exit 1 unless -l $l; $r = readlink $l; exit 1 unless
$r; print $r\n' $1;
}
fi
Yeah, well, I'll be happy to change this once we have some official
Policy, or an offical Best Current Practice statement.
I'll let the shell maintainers finish their penis war first, though.
--
G. Branden Robinson| You live and learn.
Debian GNU/Linux | Or you don't live long.
[EMAIL PROTECTED] | -- Robert Heinlein
http://people.debian.org/~branden/ |
pgpfb0d7RsD09.pgp
Description: PGP signature
Re: RFD: Essential packages, /, and /usr
Manoj and you are the one who came up with the pie in the Manoj sky ``when there are no problems''. Manoj Since you manage to forget context from message to message, I Manoj guess it makes a weird kind of sense that now you attribute Manoj statements like the above to your opponents. No, Manoj, it's you who missed the context here. He said ...when there are no problems. You said That will never happen, therefore we should stop trying. He said That doesn't follow. IOW, your statement had the form of a logical implication, and he questioned (quite rightly) whether that relation between the logical parts actually took place. There'll always be wars and war crimes, does that mean we should stop trying to put in place laws forbidding them? -- Ian Zimmerman, Oakland, California, U.S.A. GPG: 433BA087 9C0F 194F 203A 63F7 B1B8 6E5A 8CA3 27DB 433B A087 EngSoc adopts market economy: cheap is wasteful, efficient is expensive. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
On Tue, Jun 18, 2002 at 10:51:27AM -0500, Manoj Srivastava wrote: Josip Notice or some other nice English word... when the admin Josip puts binaries in a $PATH, they need to be aware of the Josip consequences. If they put something in a place where it can Josip replace a Debian binary, how do we know it's intentional or Josip not? If we assume it's unintentional, our scripts need to Josip hardcode paths, which makes moving stuff tedious. If we assume Josip it's intentional, we risk admins having a taste of their own Josip medicine. I'd pick the former. You reversed the order from the sentence: how do we know it's intentional or not? and the rest of the explanation, so it is hard to know which one option you prefer (at least, I am fairly unclear). Oh, right, sorry :) I'd pick the option where we should assume it's intentional and not hardcode our paths. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
The scripts should not, and this is why hard codiong paths is a bug. A policy violation, or just a bug? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
XSI. IEEE Std 1003.1-2001 describes utilities, functions, and facilities offered to application programs by the X/Open System Interface (XSI). Functionality marked XSI is also an extension to the ISO C standard. Application writers may confidently make use of an extension on all systems supporting the X/Open System Interfaces Extension. Are you suggesting that Debian support this extension, or a subset thereof? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
Yeah, well, I'll be happy to change this once we have some official Policy, or an offical Best Current Practice statement. We DO have an official Policy. It makes 'command -v' unusable in #!/bin/sh scripts. That's 688 packages in violation. It makes 'set -e' unusable in #!/bin/sh scripts. That's 6810 packages in violation. At least 7498 packages in sid have preinsts, prerms, postinsts, or postrms which violate Debian policy. Manoj suggests that I file bugs. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
Clint == Clint Adams [EMAIL PROTECTED] writes: Yeah, well, I'll be happy to change this once we have some official Policy, or an offical Best Current Practice statement. Clint We DO have an official Policy. It makes 'command -v' unusable in !/bin/sh scripts. That's 688 packages in violation. It makes 'set -e' Clint unusable in #!/bin/sh scripts. That's 6810 packages in Clint violation. At least 7498 packages in sid have preinsts, Clint prerms, postinsts, or postrms which violate Debian policy. The policy explicitly mentions that set -e is to be used. Have we collectively taken leave of common sense? Clint Manoj suggests that I file bugs. For the former. For the latter, if it really confuses soemone whether set -e is to be used or not, I suggest they stop being a developer and take up some other hobby, like being a lawyer. manoj -- A gentleman is a man who wouldn't hit a lady with his hat on. Evan Esar [ And why not? For why does she have his hat on? Ed.] Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
Hi, Clint == Clint Adams [EMAIL PROTECTED] writes: Yeah, well, I'll be happy to change this once we have some official Policy, or an offical Best Current Practice statement. Clint It makes 'set -e' unusable in #!/bin/sh scripts. Umm, could you explain why this is so? manoj -- We prefer to believe that the absence of inverted commas guarantees the originality of a thought, whereas it may be merely that the utterer has forgotten its source. Clifton Fadiman, Any Number Can Play Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
Ian == Ian Zimmerman [EMAIL PROTECTED] writes: Manoj Since you manage to forget context from message to message, I Manoj guess it makes a weird kind of sense that now you attribute Manoj statements like the above to your opponents. Ian No, Manoj, it's you who missed the context here. Rubbish. Ian He said ...when there are no problems. Ian You said That will never happen, therefore we should stop trying. Ian He said That doesn't follow. Full context: Manoj do we want to stop codifying every little thing? Clint When there are no more problems? Manoj Then we should stop right here, since that is an impossible goal. Clint That doesn't necessarily follow. Manoj Yes, it does. There are never going to be no problems. I was asking if there was an exit criteria, and the proposed exit criteria was an impossibility. Ian There'll always be wars and war crimes, does that mean we should stop Ian trying to put in place laws forbidding them? False anology. We are talking about adding codicils to the law, constantly finagling to it, not prosecuting violations of current law. manoj -- He who enters his wife's dressing room is a philosopher or a fool. Balzac Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
Clint == Clint Adams [EMAIL PROTECTED] writes: Clint Are you suggesting that Debian support this extension, or a subset Clint thereof? Ah. Before I provide my impramatur of approval over words that shall be writ in stone, are there any shells that have POSIX+XSI extensions+UP-in-interactive-mode? If so, this could be a useful criteria. If there are no such shells, well, we live with what we have, and reassess when POSIX compliance is reached. Writing in stone the current state of the shells at hand, ad updating the stone tablet from release to release of each of the candidate shells is not what I wish to do. manoj -- Take your work seriously but never take yourself seriously; and do not take what happens either to yourself or your work seriously. Booth Tarkington Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
On Tue, Jun 18, 2002 at 07:58:21AM -0400, Clint Adams wrote: Notice or some other nice English word... when the admin puts binaries in a $PATH, they need to be aware of the consequences. If they put something in a place where it can replace a Debian binary, how do we know it's Why would someone, being told that '/usr/local is for the administrator; Debian doesn't touch it' assume that package scripts will go around running things in /usr/local? Maybe said someone has read Policy section 10.1.2, Site-specific programs :) [...] However, the package may create empty directories below `/usr/local' so that the system administrator knows where to place site-specific files. These directories should be removed on package removal if they are empty. [...] If you do create a directory in `/usr/local' for local additions to a package, you should ensure that settings in `/usr/local' take precedence over the equivalents in `/usr'. [...] This is the general policy for /usr/local, and I see no reason why it shouldn't apply to /usr/local/bin as well. Richard Braakman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
The policy explicitly mentions that set -e is to be used. Have we collectively taken leave of common sense? No, it mentions that set -e SHOULD be used in some cases. The fact that it mentions /bin/sh in context with 'set -e' might be a bit confusing, but I don't think that that overrides the declaration that #!/bin/sh scripts MUST not use set -e. For the former. For the latter, if it really confuses soemone whether set -e is to be used or not, I suggest they stop being a developer and take up some other hobby, like being a lawyer. There's no confusion. set -e is expressly forbidden. Perhaps those persons who prefer forbidding something while claiming that common sense allows it, to achieving some sort of consistency, should become lawyers or perhaps government officials. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
Clint == Clint Adams [EMAIL PROTECTED] writes: The policy explicitly mentions that set -e is to be used. Have we collectively taken leave of common sense? Clint No, it mentions that set -e SHOULD be used in some cases. The fact that Clint it mentions /bin/sh in context with 'set -e' might be a bit confusing, Clint but I don't think that that overrides the declaration that #!/bin/sh Clint scripts MUST not use set -e. Show me. Which section? For the former. For the latter, if it really confuses soemone whether set -e is to be used or not, I suggest they stop being a developer and take up some other hobby, like being a lawyer. Clint There's no confusion. set -e is expressly forbidden. You keep asserting this, with no supporting evidence. 2.4.5. Error trapping in makefiles -- Every time you put more than one shell command (this includes using a loop) in a makefile command you must make sure that errors are trapped. For simple compound commands, such as changing directory and then running a program, using `' rather than semicolon as a command separator is sufficient. For more complex commands including most loops and conditionals you should include a separate `set -e' command at the start of every makefile command that's actually one of these miniature shell scripts. 6.1. Introduction to package maintainer scripts --- The package management system looks at the exit status from these scripts. It is important that they exit with a non-zero status if there is an error, so that the package management system can stop its processing. For shell scripts this means that you _almost always_ need to use `set -e' (this is usually true when writing shell scripts, in fact). It is also important, of course, that they don't exit with a non-zero status if everything went well. 11.4. Scripts - Shell scripts (`sh' and `bash') should almost certainly start with `set -e' so that errors are detected. Every script should use `set -e' or check the exit status of _every_ command. Clint Perhaps those persons who prefer forbidding something while Clint claiming that common sense allows it, to achieving some sort Clint of consistency, should become lawyers or perhaps government Clint officials. Back it up, buddy. Where is your proof? I have given three explicit references from policy strongly recommending set -e. Where the heck is it forbidden? manoj -- This is a logical analogy too... anyone who's been around, knows the world is run by paenguins. Always a paenguin behind the curtain, really getting things done. And paenguins in politics--who can deny it? Kevin M. Bealer, commenting on the penguin Linux logo Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
Ah. Before I provide my impramatur of approval over words that shall be writ in stone, are there any shells that have POSIX+XSI extensions+UP-in-interactive-mode? If so, this could be a useful criteria. If there are no such shells, well, we live with what we have, and reassess when POSIX compliance is reached. I've whipped up a little test suite, to assess POSIX compliance. It is by no means near complete. The shells tested: ii ash0.3.8-37 NetBSD /bin/sh ii bash 2.05a-11 The GNU Bourne Again SHell ii pdksh 5.2.14-6 A public domain version of the Korn shell ii zsh4.0.4-43 A shell with lots of features. ii zsh-beta 4.1.0-dev-4+cv A shell with lots of features (dev tree) This is for SUSv3 compliance. The number represents lines of diff output from the proper output. These lines are not weighted, nor do they reflect a number of violations. ash 33 bash10 bash (posix mode) 10 ksh 5 ksh (posix mode) 5 zsh 30 zsh (sh mode) 20 zsh-beta28 zsh-beta (sh mode) 18 Now, for SUSv3 + UP + XSI: ash 42 bash20 bash (posix mode) 18 ksh 9 ksh (posix mode) 9 zsh 36 zsh (sh mode) 26 zsh-beta34 zsh-beta (sh mode) 24 I should note that the 5 for ksh represents conformance with Debian's echo policy. I'll put the tests on http://people.debian.org/~schizo/ in case anyone's interested. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
