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