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
New Product Announcement
NEW PRODUCT ANNOUNCEMENT From: OUTSOURCE ENG. MFG. INC. Sir/Madam; This note is to inform you of new watchdog board technology for maintaining continuous unattended operation of PC/Servers etc. that we have released for distribution. We are proud to announce Watchdog Control Center featuring MAM (Multiple Applications Monitor) capability. The key feature of this application enables you to monitor as many applications as you have resident on any computer as well as the operating system for continuous unattended operation. The Watchdog Control Center featuring MAM capability expands third party application control of a Watchdog as access to the application's source code is no longer needed. Here is how it all works: Upon installation of the application and Watchdog, the user may select many configuration options, based on their model of Watchdog, to fit their operational needs. If the MAM feature is enabled, the user may select any executable program that they wish for monitoring. A lock up of the operating system or if any one of the selected applications is not running, the MAM feature, in conjunction with the Watchdog, will reset the system allowing for continuous operation. It's that simple! Watchdog Control Center is supported on most Microsoft Windows platforms (Win9x/WinNT/Win2k) and includes a Linux version for PCI Programmable Watchdogs. Watchdog Control Center Features: - Automated installation - Controls all Outsource Engineering Watchdogs - User selectable Watchdog timeout period - User selectable Watchdog stroke interval - Multiple Application Monitoring Included on the Installation CD: - Watchdog Control Center - Watchdog Drivers - Documentation For more information, please visit out website at http://www.outsrc-em.com/ or send an e-mail to [EMAIL PROTECTED] -- 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 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]
