Password file with over 3000 users.
Ian
I have a server which runs with normal passwd/shadow/group/gshadow
files. There are now over 3000 users and I am beginning to notice a
performance slowdown and it is about time I looked for something more
efficient - I like the idea of db or cdb database files.
My requirements:
- Must be pam compatible.
- Most users have MD5 passwords, but some are still crypt passwords. I
do not have ready access to the original plain text passwords.
- I don't want to mess around with too much, so I must have real "Unix
accounts" (UID's and home directories) for each user.
- Vanilla Debian "deb" packages.
What alternatives should I consider?
Thanks
Ian
--
To UNSUBSCRIBE, email to debian-is...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Wojciech Ziniewicz
> Hi All
>
> I have a server which runs with normal passwd/shadow/group/gshadow
> files. There are now over 3000 users and I am beginning to notice a
> performance slowdown and it is about time I looked for something more
> efficient - I like the idea of db or cdb database files.
>
> My requirements:
>
> - Must be pam compatible.
>
> - Most users have MD5 passwords, but some are still crypt passwords. I
> do not have ready access to the original plain text passwords.
>
> - I don't want to mess around with too much, so I must have real "Unix
> accounts" (UID's and home directories) for each user.
>
> - Vanilla Debian "deb" packages.
>
> What alternatives should I consider?
maybe pam-mysql ?
--
Wojciech Ziniewicz
Unix SEX :{look;gawk;find;sed;talk;grep;touch;finger;find;fl
ex;unzip;head;tail; mount;workbone;fsck;yes;gasp;fsck;more;yes;yes;eje
ct;umount;makeclean; zip;split;done;exit:xargs!!;)}
Marc Schiffbauer
> Hi All
>
> I have a server which runs with normal passwd/shadow/group/gshadow
> files. There are now over 3000 users and I am beginning to notice a
> performance slowdown and it is about time I looked for something more
> efficient - I like the idea of db or cdb database files.
>
> My requirements:
>
> - Must be pam compatible.
>
> - Most users have MD5 passwords, but some are still crypt passwords. I
> do not have ready access to the original plain text passwords.
>
> - I don't want to mess around with too much, so I must have real "Unix
> accounts" (UID's and home directories) for each user.
>
> - Vanilla Debian "deb" packages.
>
> What alternatives should I consider?
Installing nscd might be worth a try.
I *can* speedup your system.
And you do not need to change anything (IIRC) on your system to make
it work.
-Marc
--
+-O . . . o . . . O . . . o . . . O . . . ___ . . . O . . . o .-+
| Ein Service von Links2Linux.de: / o\ RPMs for SuSE |
| --> PackMan! <-- naeheres unter | __| and others |
| http://packman.links2linux.de/ . . . O \__\ . . . O . . . O . |
Bernd Schuhmacher
Ian schrieb:
> ...
> - Must be pam compatible.
>
> - Most users have MD5 passwords, but some are still crypt passwords. I
> do not have ready access to the original plain text passwords.
>
> - I don't want to mess around with too much, so I must have real "Unix
> accounts" (UID's and home directories) for each user.
>
> - Vanilla Debian "deb" packages.
>
> What alternatives should I consider?
big as yours (only about 800 users), but I have no problems with
performance and the server is not the fastest. home directorys are even
exported with nfs and samba PDC with LDAP and Samba for a M$ Domain) is
doing its job too on this box.
best regards
Bernd
_____________________________________________________________________
Emmanuel Halbwachs
Marc Schiffbauer a écrit (Tue, Sep 18, 2007 at 06:24:34PM +0200) :
> Installing nscd might be worth a try.
> I *can* speedup your system.
nscd *sigh* ... As we use LDAP, we need this beast that crashes
happily several times a day.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=344563
We need a every-5' cronjob to restart it if it has disappeared.
rm -f /var/db/nscd/*; /etc/init.d/nscd start
In other words: I can't really recommend nscd.
YMMV.
--
Emmanuel Halbwachs
Resp. Réseau/Sécurité Observatoire de Paris-Meudon
tel : (+33)1 45 07 75 54 5 Place Jules Janssen
fax : (+33)1 45 07 76 13 F 92195 MEUDON CEDEX
Héctor González
> Hello,
>
> Marc Schiffbauer a écrit (Tue, Sep 18, 2007 at 06:24:34PM +0200) :
>
>> Installing nscd might be worth a try.
>> I *can* speedup your system.
>>
>
> nscd *sigh* ... As we use LDAP, we need this beast that crashes
> happily several times a day.
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=344563
>
> We need a every-5' cronjob to restart it if it has disappeared.
>
> rm -f /var/db/nscd/*; /etc/init.d/nscd start
>
> In other words: I can't really recommend nscd.
> YMMV.
>
>
users, the key is to properly configure nscd, which needs a properly
sized hash table to operate.
/etc/nscd.conf has a suggested-size parameter for passwd, it should be a
prime number, we chose a number bigger than twice the size of our
expected user base. Its default is 211, which is too small for lots of
users.
This way, nscd usually stops failing (usually, it can fail if you set
it up for more databases than needed, like hosts). You can use the
bsdgames "primes" program to get the hash size.
--
Hector Gonzalez
Michael Loftis
--On September 18, 2007 6:41:10 PM +0200 Emmanuel Halbwachs
<Emmanuel....@obspm.fr> wrote:
> Hello,
>
> Marc Schiffbauer a écrit (Tue, Sep 18, 2007 at 06:24:34PM +0200) :
>> Installing nscd might be worth a try.
>> I *can* speedup your system.
>
> nscd *sigh* ... As we use LDAP, we need this beast that crashes
> happily several times a day.
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=344563
We're experieincing occasional nscd crashes in our newest etch based
systems, but never in the older ones. and the fact that nscd is doing any
sort of persistence bugs me too, it shouldn't. when it crashes on our
webservers the slapd then starts to work really really hard keeping up with
all the requests.
>
> We need a every-5' cronjob to restart it if it has disappeared.
>
> rm -f /var/db/nscd/*; /etc/init.d/nscd start
>
> In other words: I can't really recommend nscd.
> YMMV.
>
> --
> Emmanuel Halbwachs
> Resp. Réseau/Sécurité Observatoire de Paris-Meudon
> tel : (+33)1 45 07 75 54 5 Place Jules Janssen
> fax : (+33)1 45 07 76 13 F 92195 MEUDON CEDEX
>
>
> --
> To UNSUBSCRIBE, email to debian-is...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listm...@lists.debian.org
>
>
>
--
Michael Loftis
Modwest Operations Manager
Powerful, Affordable Web Hosting
Craig Sanders
> I have a server which runs with normal passwd/shadow/group/gshadow
> files. There are now over 3000 users and I am beginning to notice a
> performance slowdown and it is about time I looked for something more
> efficient - I like the idea of db or cdb database files.
>
> My requirements:
>
> - Must be pam compatible.
>
> - Most users have MD5 passwords, but some are still crypt passwords. I
> do not have ready access to the original plain text passwords.
>
> - I don't want to mess around with too much, so I must have real "Unix
> accounts" (UID's and home directories) for each user.
>
> - Vanilla Debian "deb" packages.
>
> What alternatives should I consider?
if you have the libnss-db package (part of nsswitch) installed, you have
everything you need already.
nsswitch.conf allows you to specify "db" as one of the sources for
passwd, shadow, group, and other files. they are read from a Berkeley
db file in /var/lib/misc (i.e. a quick indexed lookup rather than a
sequential search).
there is also a Makefile in /var/lib/misc for generating the .db versions.
to set up:
1. edit /etc/nsswitch.conf and insert the word "db" into the lines that you
want to use the db module.
e.g. change this:
passwd: compat
group: compat
shadow: compat
to this:
passwd: db compat
group: db compat
shadow: db compat
2. edit /etc/default/libnss-db to tell it which dbs to generate.
3. run "cd /var/lib/misc ; make"
4. set up a cron job (to run, say, every 5 minutes) to run the commands
in step 3 (i.e. "cd /var/lib/misc ; make"). you probably want to
redirect stdout and stderr to /dev/null so that root's mail doesn't get
flooded with make's output (mostly "make: Nothing to be done for `all'."
unless passwd,group, or shadow have changed)
see /usr/share/doc/libnss-db and other related documentation for more info.
NOTE: LDAP is also a good alternative, but a *LOT* more work to set up.
libnss-db is a simple way to speed up what already works by putting the
passwd etc files into hashed database files.
craig
PS: this works. i did this several years ago on one server when the number of
accounts grew to about 5000. there is one small catch - with the cron job
running every 5 minutes, there is a small window of time when the source files
in /etc have been updated but the .db versions haven't been regenerated yet.
the nsswitch.conf file will check both the db and the original source files in
order, so it does not prevent new accounts from logging in. for account
deletions, however, the deleted account will still work until the .db files
are regenerated. similarly, password changes will not take effect
immediately.
actually, it's been years - i can't remember if only the old password
(in /var/lib/misc/shadow.db) works, or if both the old (shadow.db) and
new (/etc/shadow) password will work. either way, that's only until the
cron job runs make again (i.e. at most, up to 5 minutes. or less if you
have cron run make more frequently).
if you have written scripts to assist with account
creation/deletion/changing, you could easily modify them to run "cd
/var/lib/misc ; make" after any change, thus eliminating the delay.
you still want the cron job, though, in case there are other ways for a
password to be changed - shell login by users or poppassd or samba, for
instance.
--
craig sanders <c...@taz.net.au>
Michael Loftis
--On September 19, 2007 9:35:50 AM +1000 Craig Sanders <c...@taz.net.au>
wrote:
>
> NOTE: LDAP is also a good alternative, but a *LOT* more work to set up.
> libnss-db is a simple way to speed up what already works by putting the
> passwd etc files into hashed database files.
I will totally agree there and for a single system LDAP can be severe
overkill. libnss-db is exactly what i was mentioning in my just previous
email.
--
Michael Loftis
Modwest Operations Manager
Powerful, Affordable Web Hosting
Michael Loftis
> Hi All
>
> I have a server which runs with normal passwd/shadow/group/gshadow
> files. There are now over 3000 users and I am beginning to notice a
> performance slowdown and it is about time I looked for something more
> efficient - I like the idea of db or cdb database files.
You've got two issues to solve here. Authentication you actually have more
options than UID/Groups mapping which is controlled by the name service
swith library, libnss. LDAP can solve both using libnss-ldap, modifying
/etc/ldap.conf and /etc/nsswitch.conf and then importing your passwd file
into LDAP. That's actually what we use here, though we modified the
'stock' LDAP configuration to allow a substr index on one of the fields
that normally isn't allowed by the LDAP schema. It was causing the LDAP
servers to thrash. The solution is seamless to the users, the LDAP system
supports crypt or md5 based passwords as normal since the password calls,e
tc, are all handled via the normal pam_unix library via libnss, which is
exactly how it does it anyway. The only difference is where it's obtaining
the users.
There also might be a way (and i haven't looke dinto this) to get Linux to
use a GDB/BDB passwd.db like *BSD's do.
>
> My requirements:
>
> - Must be pam compatible.
>
> - Most users have MD5 passwords, but some are still crypt passwords. I
> do not have ready access to the original plain text passwords.
>
> - I don't want to mess around with too much, so I must have real "Unix
> accounts" (UID's and home directories) for each user.
>
> - Vanilla Debian "deb" packages.
>
> What alternatives should I consider?
>
> Thanks
>
>
> Ian
>
>
> --
> To UNSUBSCRIBE, email to debian-is...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listm...@lists.debian.org
>
>
>
--
Michael Loftis
Modwest Operations Manager
Powerful, Affordable Web Hosting
Andrew McGlashan
> 4. set up a cron job (to run, say, every 5 minutes) to run the
> commands
> in step 3 (i.e. "cd /var/lib/misc ; make"). you probably want to
> redirect stdout and stderr to /dev/null so that root's mail doesn't
> get flooded with make's output (mostly "make: Nothing to be done for
> `all'." unless passwd,group, or shadow have changed)
This is what I added to my /etc/crontab file:
*/5 * * * * root cd /var/lib/misc && make | grep -v "make: Nothing to
be done for .all."
If changes do occur, then I will see output from them, although the output
doesn't seem that meaningful -- as in you don't see which user changed
his/her password....
Kind Regards
AndrewM
Andrew McGlashan
Broadband Solutions now including VoIP
Current Land Line No: 03 9912 0504
Mobile: 04 2574 1827 Fax: 03 8790 1224
National No: 1300 85 3804
Affinity Vision Australia Pty Ltd
http://www.affinityvision.com.au
http://adsl2choice.net
In Case of Emergency -- http://www.affinityvision.com.au/ice.html
Michelle Konzack
> What alternatives should I consider?
libpam-pgsql
libnss-pgsql1
Thanks, Greetings and nice Day
Michelle Konzack
Tamay Dogan Network
--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
Michelle Konzack Apt. 917 ICQ #328449886
50, rue de Soultz MSN LinuxMichi
0033/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com)
Ian
> if you have the libnss-db package (part of nsswitch) installed, you have
> everything you need already.
Thanks. This is exactly what I need. I actually found this and got it
running shortly after I posted my original message. Everything is in
Debian - except the documentation!
My setup is pretty much exactly as you recommend.
> PS: this works. i did this several years ago on one server when the number of
> accounts grew to about 5000. there is one small catch - with the cron job
> running every 5 minutes, there is a small window of time when the source files
> in /etc have been updated but the .db versions haven't been regenerated yet.
Just one small addition.
I added this line to end of our /usr/local/sbin/adduser.local
[ -e /var/lib/misc/Makefile ] && cd /var/lib/misc/ && make
And I have a cron job which runs the same command once per hour to
effect deletions and account locking etc.
I will have to look into controlling the cron spam.
We actually use this password file across a couple of servers with a
cron job that copies it across with rsync every 5 minutes. At some stage
I must look at a SQL or LDAP based solution. I originally chose the
rsync because each server can run on its own if one goes down and there
are no performance issues. But libpam-ccreds and nss-updatedb appear to
offer the same functionality when coupled with ldap.
We already have a postgresql backend for our radius server, would it be
better to run SQL -> LDAP -> nss or go directly from SQL -> nss?
Thanks
Ian
Craig Sanders
> Craig Sanders wrote:
>
> > if you have the libnss-db package (part of nsswitch) installed, you have
> > everything you need already.
>
> Thanks. This is exactly what I need. I actually found this and got it
> running shortly after I posted my original message. Everything is in
> Debian - except the documentation!
AFAIK, there isn't any documentation. certainly not any step-by-step howto.
it's one of the many things that IF you know about it, it's easy to
figure out. the difficult part is finding out about it in the first
place.
> I will have to look into controlling the cron spam.
append ">/dev/null 2>&1" to the cron job. IMO, the output of that
Makefile isn't ever interesting enough to care about (and if there's a
problem, you'll notice it long before you read root's mail).
> We actually use this password file across a couple of servers with a
> cron job that copies it across with rsync every 5 minutes. At some
> stage I must look at a SQL or LDAP based solution. I originally chose
> the rsync because each server can run on its own if one goes down and
> there are no performance issues. But libpam-ccreds and nss-updatedb
> appear to offer the same functionality when coupled with ldap.
>
> We already have a postgresql backend for our radius server, would it
> be better to run SQL -> LDAP -> nss or go directly from SQL -> nss?
can't say. personally, i tend to avoid making web/mail/shell/etc servers
dependant on an SQL server for authentication (especially if it's
mysql). i'd be more inclined to use LDAP and have an LDAP slave on
every server that needs it.
SQL servers are useful, but i just don't trust them the way i trust
plain text files.
even where i've stored, e.g., postfix maps in postgresql, i've always
set them up so that the postgresql table is dumped (by cron job) to
a plain text file and made into a hashed db file - that way the mail
server will keep on working even if the postgresql server is down or
unreachable or overloaded.
the trick to that is using a timestamp table auto-updated by a trigger
when anything in the database is changed - that way you can avoid
regenerating the hash maps when nothing has changed (i.e. the same idea
as timestamp dependancies in Make).
craig
--
craig sanders <c...@taz.net.au>
Michael Loftis
--On September 21, 2007 12:02:23 AM +0200 Ian <ifo...@zsd.co.za> wrote:
> Craig Sanders wrote:
>
>> if you have the libnss-db package (part of nsswitch) installed, you have
>> everything you need already.
>
> Thanks. This is exactly what I need. I actually found this and got it
> running shortly after I posted my original message. Everything is in
> Debian - except the documentation!
>
> My setup is pretty much exactly as you recommend.
>
>> PS: this works. i did this several years ago on one server when the
>> number of accounts grew to about 5000. there is one small catch - with
>> the cron job running every 5 minutes, there is a small window of time
>> when the source files in /etc have been updated but the .db versions
>> haven't been regenerated yet.
>
> Just one small addition.
>
> I added this line to end of our /usr/local/sbin/adduser.local
>
> [ -e /var/lib/misc/Makefile ] && cd /var/lib/misc/ && make
>
> And I have a cron job which runs the same command once per hour to
> effect deletions and account locking etc.
>
> I will have to look into controlling the cron spam.
2>&1 > /dev/null to end of command line.
>
> We actually use this password file across a couple of servers with a
> cron job that copies it across with rsync every 5 minutes. At some stage
> I must look at a SQL or LDAP based solution. I originally chose the
> rsync because each server can run on its own if one goes down and there
> are no performance issues. But libpam-ccreds and nss-updatedb appear to
> offer the same functionality when coupled with ldap.
>
> We already have a postgresql backend for our radius server, would it be
> better to run SQL -> LDAP -> nss or go directly from SQL -> nss?
Up to you to me it seems simplest to run LDAP via it's builtin
bdb/ldbm/gdbm facilities. You can run replica slaves on the other
machines. It's what we do here. We're working on improving security by
doing authentication in a different method so we're not syncing auth
information elsewhere but have account data available everywhere. (we've
something like 10 webservers that each have LDAP slaves, another like 5 or
6 mail servers, etc).
You also have to be careful not to get service dependencies (like you need
to make sure your mysql and ldap server daemons users aren't in LDAP) when
you start making services depend on eachother.
Turbo Fredriksson
>> I will have to look into controlling the cron spam.
>
> 2>&1 > /dev/null to end of command line.
Actually, it's the other way around:
> /dev/null 2>&1
You first have to redirect STDOUT, then tell STDERR to go to STDOUT...
Andrew McGlashan
> Quoting Michael Loftis <mlo...@modwest.com>:
>
>>> I will have to look into controlling the cron spam.
>> 2>&1 > /dev/null to end of command line.
> Actually, it's the other way around:
>
>> /dev/null 2>&1
>
> You first have to redirect STDOUT, then tell STDERR to go to STDOUT...
I've heard that before many times, but the reverse has never failed me.
Kind Regards
AndrewM
Andrew McGlashan
Broadband Solutions now including VoIP
Current Land Line No: 03 9912 0504
Mobile: 04 2574 1827 Fax: 03 8790 1224
National No: 1300 85 3804
Affinity Vision Australia Pty Ltd
http://www.affinityvision.com.au
http://adsl2choice.net
In Case of Emergency -- http://www.affinityvision.com.au/ice.html
Marcin Sochacki
> only (t)csh redirection >& or |& will redirect both stdout and stderr
> together. you can't do that in (da)sh/bash/ksh
In bash you can use the '&>' redirect as an alias to both stdout and
stderr.
Marcin
--
+---------------------------------------+
| -o) http://wanted.eu.org/
| /\\ Message void if penguin violated
+ _\_V Don't mess with the penguin
Matus UHLAR - fantomas
> >Actually, it's the other way around:
> >
> >>/dev/null 2>&1
> >
> >You first have to redirect STDOUT, then tell STDERR to go to STDOUT...
On 21.09.07 17:55, Andrew McGlashan wrote:
> I've heard that before many times, but the reverse has never failed me.
But that does not mean it is correct. At least it's probably not what you
wanted to do...
> >>2>&1 > /dev/null to end of command line.
this will redirect stderr to stdout, and then stdout to /dev/null, but
stderr will still be directed to the file stdout was directed to.
only (t)csh redirection >& or |& will redirect both stdout and stderr
together. you can't do that in (da)sh/bash/ksh
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Microsoft dick is soft to do no harm
Marcin Sochacki
> Marcin Sochacki wrote:
> > On Fri, Sep 21, 2007 at 10:53:35AM +0200, Matus UHLAR - fantomas wrote:
> >> only (t)csh redirection >& or |& will redirect both stdout and stderr
> >> together. you can't do that in (da)sh/bash/ksh
> >
> > In bash you can use the '&>' redirect as an alias to both stdout and
> > stderr.
> >
> > Marcin
>
> packages).
I know, but the message I replied to specifically mentioned bash.
Martin Marcher
debian-user instead of -isp. Guess i'll stop mailing for today....
2007/9/21, Thomas Goirand <tho...@goirand.fr>:
> But the reference for Debian is sh, not bash... (at least when writing
> packages).
why is it then that /bin/sh is /bin/bash after a plain install of
about every stable version i had by now?
ok that makes only 3 but still (potato sarge etch iirc for that matter)
martin
--
http://noneisyours.marcher.name
http://feeds.feedburner.com/NoneIsYours
Michael Loftis
--On September 21, 2007 9:38:22 AM +0200 Turbo Fredriksson
<tu...@debian.org> wrote:
> Quoting Michael Loftis <mlo...@modwest.com>:
>
>>> I will have to look into controlling the cron spam.
>>
>> 2>&1 > /dev/null to end of command line.
>
> Actually, it's the other way around:
>
> > /dev/null 2>&1
>
> You first have to redirect STDOUT, then tell STDERR to go to STDOUT...
You're right. I never noticed all my scripts I do it the other way around
but when I wrote that email I wrote it the wrong way.
Craig Sanders
> 2007/9/21, Thomas Goirand <tho...@goirand.fr>:
> > But the reference for Debian is sh, not bash... (at least when writing
> > packages).
>
> why is it then that /bin/sh is /bin/bash after a plain install of
> about every stable version i had by now?
whatever the default sh is (bash), debian's policy says that init.d
etc shell scripts must not use any bash-isms. i.e. they must be
POSIX-compliant so they will work if you replace[1] /bin/sh with
ash/dash.
but that only applies to debian packages, not to whatever you write for
yourself.
[1] i doubt if anyone actually does that or cares any more. there arent
many (any?) systems being built where the extra disk-space, memory etc
used by bash compared to ash actually make any difference at all.
craig
--
craig sanders <c...@taz.net.au>
Stephen Gran
> On Fri, Sep 21, 2007 at 07:26:56PM +0200, Martin Marcher wrote:
> > 2007/9/21, Thomas Goirand <tho...@goirand.fr>:
> > > But the reference for Debian is sh, not bash... (at least when writing
> > > packages).
> >
> > why is it then that /bin/sh is /bin/bash after a plain install of
> > about every stable version i had by now?
>
> whatever the default sh is (bash), debian's policy says that init.d
> etc shell scripts must not use any bash-isms. i.e. they must be
> POSIX-compliant so they will work if you replace[1] /bin/sh with
> ash/dash.
This is only true if the shebang is /bin/sh - you are of course free to
write maintainer scripts with /bin/bash as the shebang, just as your
free to write perl scripts for your maintainer scripts. That being
said, there is a push for dash to replace bash as the dfeault
non-interactive shell for lenny.
--
-----------------------------------------------------------------
| ,''`. Stephen Gran |
| : :' : sg...@debian.org |
| `. `' Debian user, admin, and developer |
| `- http://www.debian.org |
-----------------------------------------------------------------
Thomas Goirand
> whatever the default sh is (bash), debian's policy says that init.d
> etc shell scripts must not use any bash-isms. i.e. they must be
> POSIX-compliant so they will work if you replace[1] /bin/sh with
> ash/dash.
>
> many (any?) systems being built where the extra disk-space, memory etc
> used by bash compared to ash actually make any difference at all.
Still, the embedded Debian would care about such things...
Thomas
Nate Duehr
On Sep 21, 2007, at 4:52 PM, Craig Sanders wrote:
> [1] i doubt if anyone actually does that or cares any more. there
> arent
> many (any?) systems being built where the extra disk-space, memory etc
> used by bash compared to ash actually make any difference at all.
"Embedded" systems. Tiny "disks".
--
Nate Duehr
na...@natetech.com
Nate Duehr
On Sep 21, 2007, at 5:12 PM, Stephen Gran wrote:
> This is only true if the shebang is /bin/sh - you are of course
> free to
> write maintainer scripts with /bin/bash as the shebang, just as your
> free to write perl scripts for your maintainer scripts. That being
> said, there is a push for dash to replace bash as the dfeault
> non-interactive shell for lenny.
Why? Just to be annoyingly different from every other distro
(again)? Or is there a very compelling technical reason?
--
Nate Duehr
na...@natetech.com
Stephen Gran
>
> On Sep 21, 2007, at 5:12 PM, Stephen Gran wrote:
>
> >This is only true if the shebang is /bin/sh - you are of course
> >free to
> >free to write perl scripts for your maintainer scripts. That being
> >non-interactive shell for lenny.
>
> Why? Just to be annoyingly different from every other distro
> (again)? Or is there a very compelling technical reason?
Presumably because its load and run time is less than bash's. The idea,
as far as I have followed the discussion, is that this will make boot
time faster.
Roberto C. Sánchez
> This one time, at band camp, Nate Duehr said:
> >
> > On Sep 21, 2007, at 5:12 PM, Stephen Gran wrote:
> >
> > >This is only true if the shebang is /bin/sh - you are of course
> > >free to
> > >write maintainer scripts with /bin/bash as the shebang, just as you're
> > >free to write perl scripts for your maintainer scripts. That being
> > >said, there is a push for dash to replace bash as the default
> > >non-interactive shell for lenny.
> >
> > Why? Just to be annoyingly different from every other distro
> > (again)? Or is there a very compelling technical reason?
>
> Presumably because its load and run time is less than bash's. The idea,
> as far as I have followed the discussion, is that this will make boot
> time faster.
This is especially true on embedded and older systems.
Regards,
-Roberto
--
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com
Matus UHLAR - fantomas
> >This is only true if the shebang is /bin/sh - you are of course
> >free to
> >write maintainer scripts with /bin/bash as the shebang, just as your
> >free to write perl scripts for your maintainer scripts. That being
> >said, there is a push for dash to replace bash as the dfeault
> >non-interactive shell for lenny.
On 22.09.07 07:06, Nate Duehr wrote:
> Why? Just to be annoyingly different from every other distro
> (again)? Or is there a very compelling technical reason?
I don't think it's annoying. I feel annoyed bu many distros expecting
/bin/sh to be bash, bringing up meny incompatibilities with FreeBSD and
Solaris. I'm for complete replacing of bash with dash, making dash essential
(and bash not essential) and I've used dash (and ash, which was its previous
name) since I've found it in debian distribution...
I think that bash is bloatware.
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Saving Private Ryan...
Private Ryan exists. Overwrite? (Y/N)
Maximilian Wilhelm
> > On Sep 21, 2007, at 5:12 PM, Stephen Gran wrote:
> > >This is only true if the shebang is /bin/sh - you are of course
> > >free to
> > >write maintainer scripts with /bin/bash as the shebang, just as your
> > >free to write perl scripts for your maintainer scripts. That being
> > >said, there is a push for dash to replace bash as the dfeault
> > >non-interactive shell for lenny.
> On 22.09.07 07:06, Nate Duehr wrote:
> > Why? Just to be annoyingly different from every other distro
> > (again)? Or is there a very compelling technical reason?
> I don't think it's annoying. I feel annoyed bu many distros expecting
> /bin/sh to be bash, bringing up meny incompatibilities with FreeBSD and
> Solaris.
So bash cannot do things FreeBSD or Solaris sh can?
> I'm for complete replacing of bash with dash, making dash essential
> (and bash not essential) and I've used dash (and ash, which was its previous
> name) since I've found it in debian distribution...
> I think that bash is bloatware.
Now *you* would break compability.
Sure, it's the problem of the user who wrote a script which uses
bashism and uses /bin/sh as shebang, but *you* would make it break.
What about using "#!/usr/bin/env sh" for all script which have to be
sh-compliant?
Ciao
Max
--
Follow the white penguin.
Roberto C. Sánchez
> Am Sunday, den 23 September hub Matus UHLAR - fantomas folgendes in die Tasten:
>
> > /bin/sh to be bash, bringing up meny incompatibilities with FreeBSD and
> > Solaris.
>
> So bash cannot do things FreeBSD or Solaris sh can?
>
differently) and that expecting sh everywhere to behave like bash is
wrong and broken.
> > I'm for complete replacing of bash with dash, making dash essential
> > (and bash not essential) and I've used dash (and ash, which was its previous
> > name) since I've found it in debian distribution...
>
> > I think that bash is bloatware.
>
> Now *you* would break compability.
> Sure, it's the problem of the user who wrote a script which uses
> bashism and uses /bin/sh as shebang, but *you* would make it break.
>
> What about using "#!/usr/bin/env sh" for all script which have to be
> sh-compliant?
>
Umm, because that would be pointless. If /bin/sh is a symlink to bash,
it doesn't matter how you invoke it, you get bash.
Craig Sanders
> I don't think it's annoying. I feel annoyed bu many distros expecting
> /bin/sh to be bash, bringing up meny incompatibilities with FreeBSD and
> Solaris. I'm for complete replacing of bash with dash, making dash essential
> (and bash not essential) and I've used dash (and ash, which was its previous
> name) since I've found it in debian distribution...
hooray. lets all go back to the 1970s.
and let's toss out GNU fileutils, shellutils, findutils, etc while we're
at it and write primitive clones of ancient propietary versions - debian
too can have a crappy archaic userland like freebsd and solaris.
mandating POSIX compliance for init.d and other system sh scripts is one
thing (and not that bad a requirement), but mandating it as the default
interactive sh is beyond stupid, it's cretinous.
craig
--
craig sanders <c...@taz.net.au>
Stephen Gran
> > I don't think it's annoying. I feel annoyed bu many distros expecting
> > /bin/sh to be bash, bringing up meny incompatibilities with FreeBSD and
> > Solaris. I'm for complete replacing of bash with dash, making dash essential
> > (and bash not essential) and I've used dash (and ash, which was its previous
> > name) since I've found it in debian distribution...
>
> hooray. lets all go back to the 1970s.
>
> and let's toss out GNU fileutils, shellutils, findutils, etc while we're
> at it and write primitive clones of ancient propietary versions - debian
> too can have a crappy archaic userland like freebsd and solaris.
>
>
> mandating POSIX compliance for init.d and other system sh scripts is one
> thing (and not that bad a requirement), but mandating it as the default
> interactive sh is beyond stupid, it's cretinous.
I don't think anyone in their right mind is recommending dash as the
default interactive shell. Maybe Matus wants to use it on his systems,
but so far as I've been following the discussion, it only concerns the
/bin/sh symlink, now what ends up in /etc/password for new accounts.
Christoph Moench-Tegeder
> > I don't think it's annoying. I feel annoyed bu many distros expecting
> > /bin/sh to be bash, bringing up meny incompatibilities with FreeBSD and
> > Solaris.
> So bash cannot do things FreeBSD or Solaris sh can?
There are (were?) some cases where bash is not strictly POSIX-compliant.
I remember some headache moving scripts from HP-UX (where /bin/sh is
a ksh88) to Linux with bash. I cured the major breakage by using ksh93.
In addition, bash has many extensions over "standard shells", so one
shoukld carefully look out for scripts with a /bin/sh-shebang which
are expecting bash and therefor will break with most other shells.
> What about using "#!/usr/bin/env sh" for all script which have to be
> sh-compliant?
You will have to agree on what bugs and features you expect from sh.
Regards
Christoph
--
Spare Space
Matus UHLAR - fantomas
> > I don't think it's annoying. I feel annoyed bu many distros expecting
> > /bin/sh to be bash, bringing up meny incompatibilities with FreeBSD and
> > Solaris. I'm for complete replacing of bash with dash, making dash essential
> > (and bash not essential) and I've used dash (and ash, which was its previous
> > name) since I've found it in debian distribution...
On 24.09.07 08:24, Craig Sanders wrote:
> hooray. lets all go back to the 1970s.
bullshit. This way you can say that need for a shell and terminals is going
back to the 70s because now we can have window environment, interactive
applications and perl (or visual basic?) for scripting.
> mandating POSIX compliance for init.d and other system sh scripts is one
> thing (and not that bad a requirement), but mandating it as the default
> interactive sh is beyond stupid, it's cretinous.
"Priority: standard" and "Priority: required" (or "Essential: yes") are
different things. While bash can be standard, it's not really needed to be
login shell for system users (yes, including root). I see nothing bad in
having bash installed when users want/use it or when packages _require_ it.
I see nothing bad when someone uses it as a login shell. But it should not
be forced by anyone.
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
I wonder how much deeper the ocean would be without sponges.
Nate Duehr
convincing seems to have boiled down to these answers:
- Bash is fat, especially for embedded systems, and smaller shells will
boot faster.
- Bash acts differently than other shells.
- Shell scripts starting with a wimpy /bin/sh-shebang are broken by default.
In response, I'd say...
- Don't use bash if you don't want to, but don't push your smaller shell
on me just because of that.
- Duh.
- Duh.
Seems like a dumb set of reasons to change the default non-login shell,
to me... people tinkering with the defaults always leads to breakage,
something Linux is uber-famous for. It's getting old.
Anyone that doesn't know all of the above when choosing to use Linux,
isn't paying any attention at all and shouldn't be designing anything,
let alone an OS. And especially not by committee.
(On the flip side, anyone using Linux not expecting the so-called
"leadership" to constantly break working things, hasn't paid any
attention to Linux history either.)
Linux as a whole is stuck in a never-ending break-fix cycle it can't
break out of. (No pun intended.)
Nate
Roberto C. Sánchez
> So the answer to my question, "Why dash?"... the answers weren't very
> convincing seems to have boiled down to these answers:
>
> - Bash is fat, especially for embedded systems, and smaller shells will
> boot faster.
> - Bash acts differently than other shells.
> - Shell scripts starting with a wimpy /bin/sh-shebang are broken by default.
>
> In response, I'd say...
>
> - Don't use bash if you don't want to, but don't push your smaller shell
> on me just because of that.
> - Duh.
> - Duh.
>
> Seems like a dumb set of reasons to change the default non-login shell,
> to me... people tinkering with the defaults always leads to breakage,
> something Linux is uber-famous for. It's getting old.
>
is suitable on a well resourced machine, bash is not suitable on a very
low resource machine.
Besides, if someone uses the /bin/sh specification for a script and then
goes on to use bashism, that is *by definition* broken. It simply the
fact that bash is the default that masks the brokenness.
> Anyone that doesn't know all of the above when choosing to use Linux,
> isn't paying any attention at all and shouldn't be designing anything,
> let alone an OS. And especially not by committee.
>
> (On the flip side, anyone using Linux not expecting the so-called
> "leadership" to constantly break working things, hasn't paid any
> attention to Linux history either.)
>
> Linux as a whole is stuck in a never-ending break-fix cycle it can't
> break out of. (No pun intended.)
>
So, you would rather that things stay the same rather than improve (and
potentially break)? There is an operating system targeted at just that
crowd. It is called MS Windows. You are more than welcome to go use
it.
Thomas Goirand
To that, there's a simple answer: that's why Debian has release cycles,
and different flavours (unstable, experimental, etc.).
Thomas
Craig Sanders
> So, you would rather that things stay the same rather than improve (and
> potentially break)? There is an operating system targeted at just that
actually, it's replacing bash with ash/dash as the default sh which has
the potential to break things.
bash has been /bin/sh on debian systems for over a decade. there's a lot
of local scripts that have been written assuming that fact (and even
several debian package scripts which make that assumption in violation
of policy - yes, that's a bug. the correct response to that is to file
bug reports and have them fixed, not just break them - and everyone's
local scripts - arbitrarily).
changing something that will break things for the majority in order
to cater for a miniscule minority (embedded systems developers) is a
ludicrous proposition. it makes no sense at all.
craig
--
craig sanders <c...@taz.net.au>
Matus UHLAR - fantomas
> > So, you would rather that things stay the same rather than improve (and
> > potentially break)? There is an operating system targeted at just that
On 25.09.07 18:25, Craig Sanders wrote:
> actually, it's replacing bash with ash/dash as the default sh which has
> the potential to break things.
> changing something that will break things for the majority in order
> to cater for a miniscule minority (embedded systems developers) is a
> ludicrous proposition. it makes no sense at all.
those things are already broken. using dash as /bin/sh will not break them.
replacing /bin/sh with /bin/bash is easy to do...
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Support bacteria - they're the only culture some people have.
Craig Sanders
> > On Mon, Sep 24, 2007 at 05:34:07PM -0400, Roberto C. Sánchez wrote:
> > > So, you would rather that things stay the same rather than improve (and
> > > potentially break)? There is an operating system targeted at just that
>
> On 25.09.07 18:25, Craig Sanders wrote:
> > actually, it's replacing bash with ash/dash as the default sh which has
> > the potential to break things.
[ i note that you carefully deleted the paragraphs about locally written
scripts - presumably because you have no answer and wish to ignore it
and hope nobody notices. ]
>
> > changing something that will break things for the majority in order
> > to cater for a miniscule minority (embedded systems developers) is a
> > ludicrous proposition. it makes no sense at all.
>
> those things are already broken. using dash as /bin/sh will not break them.
no, those locally written ARE NOT BROKEN.
bash has been /bin/sh on debian systems for over a decade. it is
perfectly reasonable for a local sysadmin to take advantage of the
non-POSIX features of the debian standard /bin/sh.
you may choose to write your sh scripts in pure POSIXLY_CORRECT form,
but that DOES NOT invalidate the choices of others.
> replacing /bin/sh with /bin/bash is easy to do...
it may be easy but it's not necessary because it's already the default.
it's even easier (and far less work for far fewer people) for the
miniscule minority who want an archaic sh to replace it on their
systems, or on their debian-derivative embedded distros.
just file bug reports on any debian packages that aren't POSIX
compliant, get them fixed, and use dash on your systems. that way, those
who want dash can have it, and those of us who don't wont even have to
know about or give a damn one way or the other.
but forcing your personal desires on everyone else just because you
think it's better/smaller/neater/more-aesthetically-pleasing or whatever
stupid reason you have AND because you don't give a shit how many
systems belonging to other people you break is both brain-damaged AND
maliciously stupid.
you might have had a chance to make ash/dash the default sh 12 or 13
years ago if a) you were around, and b) ash was around (it wasn't.
certainly not in debian and probably not anywhere AFAICR). but you
weren't and it wasn't. the issue was settled years ago. deal with it and
move on.
craig
--
craig sanders <c...@taz.net.au>
BOFH excuse #243:
The computer fleetly, mouse and all.
Nate Duehr
> So, you would rather that things stay the same rather than improve (and
> potentially break)? There is an operating system targeted at just that
> crowd. It is called MS Windows. You are more than welcome to go use
> it.
An improvement by who's standards? The devs or the users?
Craig's comments about breaking user's local stuff on the whims of the
devs, pretty much covers the rest of my thoughts on the topic.
Someone pointed out that Debian has release cycles. Yep, I've known
that since 1995 or so, thanks. It's why I use Debian, and another "duh"
moment...
But I've seen the devs get themselves all wound up in a tizzy over silly
crap like this before, make changes, break things for end-users without
need, and then wonder why users think Debian with it's "uber-great
goals" is just as insane as say, the RedHat/Fedora/RHEL fiasco.
We should strive for that lovely and much lauded goal... "The principal
of least surprise."
Some users have now used, and expect bash as the default shell on their
Debian systems, for longer than some of the devs have been old enough to
code, now.
Folks that KNOW why they need/want ash, dash, Bob's Big Boy Shell, or
even... shudder... tcsh... know how to change it, easily.
Leave the average Joe alone, leave his defaults alone. Be sane.
Roberto C. Sánchez
> On Mon, Sep 24, 2007 at 05:34:07PM -0400, Roberto C. Sánchez wrote:
> > So, you would rather that things stay the same rather than improve (and
> > potentially break)? There is an operating system targeted at just that
>
> actually, it's replacing bash with ash/dash as the default sh which has
> the potential to break things.
>
> bash has been /bin/sh on debian systems for over a decade. there's a lot
> of local scripts that have been written assuming that fact (and even
> several debian package scripts which make that assumption in violation
> of policy - yes, that's a bug. the correct response to that is to file
> bug reports and have them fixed, not just break them - and everyone's
> local scripts - arbitrarily).
>
> changing something that will break things for the majority in order
> to cater for a miniscule minority (embedded systems developers) is a
> ludicrous proposition. it makes no sense at all.
>
bugs? I mean there are C and C++ "features" that are in violation of
the spec or which are clearly buggy behavior. But of course, we shoud
be more concerned with not ever disturbing any locally developed
software than we should about making things more policy compliant.
Right?
Matus UHLAR - fantomas
> > > > So, you would rather that things stay the same rather than improve (and
> > > > potentially break)? There is an operating system targeted at just that
> >
> > On 25.09.07 18:25, Craig Sanders wrote:
> > > actually, it's replacing bash with ash/dash as the default sh which has
> > > the potential to break things.
On 25.09.07 18:46, Craig Sanders wrote:
> [ i note that you carefully deleted the paragraphs about locally written
> scripts - presumably because you have no answer and wish to ignore it
> and hope nobody notices. ]
I did not feel I have to differ between them.
> > > changing something that will break things for the majority in order
> > > to cater for a miniscule minority (embedded systems developers) is a
> > > ludicrous proposition. it makes no sense at all.
> >
> > those things are already broken. using dash as /bin/sh will not break them.
>
> no, those locally written ARE NOT BROKEN.
If any sscript calling /bin/sh uses bashisms, it IS broken by definition.
The fact that it's not visible, because /bin/sh and /bin/bash are the same,
does NOT mean they are not broken.
> bash has been /bin/sh on debian systems for over a decade. it is
> perfectly reasonable for a local sysadmin to take advantage of the
> non-POSIX features of the debian standard /bin/sh.
did I or anyone else say that bash MUST NOT be installed as /bin/sh?
I have no objections against this possibility. But having bash installed
just because some people break things is sick.
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Spam = (S)tupid (P)eople's (A)dvertising (M)ethod
Thomas Goirand
> actually, it's replacing bash with ash/dash as the default sh which has
> the potential to break things.
>
> bash has been /bin/sh on debian systems for over a decade. there's a lot
> of local scripts that have been written assuming that fact
That's a VERY bad assumption. It would have been a LOT better to write:
#!/bin/bash
instead of:
#!/bin/sh
I don't get why your "local scripts" made this BIG error.
> changing something that will break things for the majority in order
> to cater for a miniscule minority (embedded systems developers) is a
> ludicrous proposition. it makes no sense at all.
>
> craig
It does make sense if it makes the overall system faster and less sloppy.
Thomas
Thomas Goirand
>>> changing something that will break things for the majority in order
>>> to cater for a miniscule minority (embedded systems developers) is a
>>> ludicrous proposition. it makes no sense at all.
>> those things are already broken. using dash as /bin/sh will not break them.
>
> no, those locally written ARE NOT BROKEN.
>
> bash has been /bin/sh on debian systems for over a decade. it is
> perfectly reasonable for a local sysadmin to take advantage of the
> non-POSIX features of the debian standard /bin/sh.
I do not agree with that. I think it's a major design error to mistake
between bash and sh and do some *BAD* assumptions like this. You cannot
complain if you did, IMHO. And I do as well think that those locally
written script ARE broken.
> you may choose to write your sh scripts in pure POSIXLY_CORRECT form,
> but that DOES NOT invalidate the choices of others.
Nobody invalidate anything. You can still use bash if you like, as long
as you call it correctly with #!/bin/bash ...
> but forcing your personal desires on everyone else just because you
> think it's better/smaller/neater/more-aesthetically-pleasing or whatever
> stupid reason you have AND because you don't give a shit how many
> systems belonging to other people you break is both brain-damaged AND
> maliciously stupid.
Nobody is brain-damaged because of this. The one who where brain-damaged
are the one that wrote #!/bin/sh when they really wanted to write
#!/bin/bash instead... The replacement of bash by something else CAN be
argued, but NOT the fact that writing #!/bin/sh instead of #!/bin/bash
is a big big mistake when somebody really want to use bash... And you
CANNOT complain after that mistake, IMHO.
Thomas
Thomas Goirand
> just because some people break things is sick.
I 100% agree with this. This is the main point.
Apart from that, the fact that bash becomes the default CAN be
discussed, but not because some people have broken minds.
Thomas
Rodríguez de la Borbolla, Carlos
Hi all.
I think this should be moved to another threat (not RE: Password file with over 3000 users.).
I agree scripts should declare the correct shell, and those which use specific bashisms should use #!/bin/bash.
Some shells ask at install time to use it as sh. So people who have problems with their scripts can install bash and use it as sh.
Best regards.
PD: Sorry for my English.
-----Mensaje original-----
De: Thomas Goirand [mailto:tho...@goirand.fr]
Enviado el: martes, 25 de septiembre de 2007 14:18
Para: debia...@lists.debian.org
Asunto: Re: Password file with over 3000 users.
Craig Sanders
> On Tue, Sep 25, 2007 at 06:25:01PM +1000, Craig Sanders wrote:
> > changing something that will break things for the majority in order
> > to cater for a miniscule minority (embedded systems developers) is a
> > ludicrous proposition. it makes no sense at all.
> >
> So, you would be in favor not improving the compilers or fixing compiler
> bugs?
thanks for the stupid straw-man argument. it highlights the irrational
thinking behind the proposal to replace bash with dash.
> I mean there are C and C++ "features" that are in violation of the
> spec or which are clearly buggy behavior. But of course, we shoud
fixing actual bugs is completely different from arbitrarily breaking
things for no good reason.
craig
--
craig sanders <c...@taz.net.au>
BOFH excuse #81:
Please excuse me, I have to circuit an AC line through my head to get
this database working.
Craig Sanders
> And I do as well think that those locally
> written script ARE broken.
then you would be wrong.
on debian, /bin/sh has been bash for over a decade. that's an historical
fact. changing it now would break things for no good reason.
those who want dash can easily have it. those who don't do not need to
be disturbed.
craig
--
craig sanders <c...@taz.net.au>
Roberto C. Sánchez
> On Tue, Sep 25, 2007 at 05:03:54AM -0400, Roberto C. Sánchez wrote:
> > On Tue, Sep 25, 2007 at 06:25:01PM +1000, Craig Sanders wrote:
> > > changing something that will break things for the majority in order
> > > to cater for a miniscule minority (embedded systems developers) is a
> > > ludicrous proposition. it makes no sense at all.
> > >
> > So, you would be in favor not improving the compilers or fixing compiler
> > bugs?
>
> thanks for the stupid straw-man argument. it highlights the irrational
> thinking behind the proposal to replace bash with dash.
>
you consider that many compiler bugs persist for years and many
developers grow to "depend" on them. In such a case, things would break
for the majority (the developers who depend on buggy behavior) to cater
to the minority (the developers who wish to have a more cleanly
implemented compiler). Of course, if you don't really believe what you
are saying, then please feel free to admit it.
> > I mean there are C and C++ "features" that are in violation of the
> > spec or which are clearly buggy behavior. But of course, we shoud
>
> fixing actual bugs is completely different from arbitrarily breaking
> things for no good reason.
>
Really? What of the situation I mentioned above. To the affected
developers, fixing such a bug would certainly seem arbitrary.
Additionally, you fail to define "no good reason". I think that the
reasons to replace bash with dash are all perfectly good: to promote
portability, use fewer resources and be more standards compliant.
Now, if those are not good reasons to you, then I would venture that
your priorities are misplaced or that you think that the developers of
an operating system ought to listen to you simply because you throw a
little tantrum over not liking their decisions.
Craig Sanders
> On Wed, Sep 26, 2007 at 09:05:01AM +1000, Craig Sanders wrote:
> > On Tue, Sep 25, 2007 at 05:03:54AM -0400, Roberto C. Sánchez wrote:
> > > On Tue, Sep 25, 2007 at 06:25:01PM +1000, Craig Sanders wrote:
> > > > changing something that will break things for the majority in order
> > > > to cater for a miniscule minority (embedded systems developers) is a
> > > > ludicrous proposition. it makes no sense at all.
> > > >
> > > So, you would be in favor not improving the compilers or fixing compiler
> > > bugs?
> >
> > thanks for the stupid straw-man argument. it highlights the irrational
> > thinking behind the proposal to replace bash with dash.
> >
> Actually, my statement is a natural extension of yours.
no, it's a *stupid* extension of mine, not a "natural" extension.
it's what is known as "grasping at straws". indicating irrationality and
desperation. your argument holds no water, and you know it - hence the
descent into absurd projection.
craig
--
craig sanders <c...@taz.net.au>
Roberto C. Sánchez
> On Tue, Sep 25, 2007 at 07:13:15PM -0400, Roberto C. Sánchez wrote:
> > On Wed, Sep 26, 2007 at 09:05:01AM +1000, Craig Sanders wrote:
> > > On Tue, Sep 25, 2007 at 05:03:54AM -0400, Roberto C. Sánchez wrote:
> > > > On Tue, Sep 25, 2007 at 06:25:01PM +1000, Craig Sanders wrote:
> > > > > changing something that will break things for the majority in order
> > > > > to cater for a miniscule minority (embedded systems developers) is a
> > > > > ludicrous proposition. it makes no sense at all.
> > > > >
> > > > So, you would be in favor not improving the compilers or fixing compiler
> > > > bugs?
> > >
> > > thanks for the stupid straw-man argument. it highlights the irrational
> > > thinking behind the proposal to replace bash with dash.
> > >
> > Actually, my statement is a natural extension of yours.
>
> no, it's a *stupid* extension of mine, not a "natural" extension.
>
> it's what is known as "grasping at straws". indicating irrationality and
> desperation. your argument holds no water, and you know it - hence the
> descent into absurd projection.
>
conveniently ignore the explanation that I gave following that?
Craig Sanders
> > it's what is known as "grasping at straws". indicating irrationality and
> > desperation. your argument holds no water, and you know it - hence the
> > descent into absurd projection.
> >
> Clearly, your argument also holds no water. Else, why would you
nice to see that you admit that your own argument holds no water.
> conveniently ignore the explanation that I gave following that?
i ignored it because it was just a regurgitation of the same garbage
that you had posted (and which i had demolished) earlier. i see no point
in wasting my time repeating myself just because you feel a compelling
need to do so.
HTH, HAND,
Nate Duehr
> Please see my reply to Craig's message. Compilers fall into exactly the
> same boat.
Compilers have been "broken" in various ways since the beginning of
time. Devs are used to it. Additionally most compiler breakage gets
fixed with a patch that provides (yet another) switch option to
re-enable the "brokenness" for those that require it until they can fix
their software, at least for a while. You can deprecate things in a
compiler.
I would counter that if bash is to be replaced, it should be officially
deprecated for at LEAST one full release cycle, if not two.
Thomas Goirand
> On Tue, Sep 25, 2007 at 08:13:40PM +0800, Thomas Goirand wrote:
>
>> And I do as well think that those locally
>> written script ARE broken.
>
> then you would be wrong.
>
> on debian, /bin/sh has been bash for over a decade. that's an historical
> fact. changing it now would break things for no good reason.
> those who want dash can easily have it. those who don't do not need to
> be disturbed.
No need to repeat, everybody got your point that it's been a decade, and
that people can choose, but you want the default being the same thing as
before, with no change possible.
> no, it's a *stupid* extension of mine, not a "natural" extension.
>
> it's what is known as "grasping at straws". indicating irrationality and
> desperation. your argument holds no water, and you know it - hence the
> descent into absurd projection.
This reminds me the SORBS thread, and ... godwin! :)
Clearly, when somebody (if not a majority) do not agree with you, you
start to be aggressive. There's absolutely no point in insulting others,
and it seems you are the only one playing that game here... Please think
twice before using words like: stupid, irrationality, or absurd when
writing to others in public lists.
It's really a shame to read this when I see many very good comments from
you helping others, showing that you are far from being stupid, and that
your brain is full of knowledge. A bit of respect wouldn't have kill
you, even if you don't agree.
Stop wining and upgrade your *broken* scripts.
Thomas
Craig Sanders
> Craig Sanders wrote:
> > On Tue, Sep 25, 2007 at 08:13:40PM +0800, Thomas Goirand wrote:
> >
> >> And I do as well think that those locally
> >> written script ARE broken.
> >
> > then you would be wrong.
> >
> > on debian, /bin/sh has been bash for over a decade. that's an historical
> > fact. changing it now would break things for no good reason.
> > those who want dash can easily have it. those who don't do not need to
> > be disturbed.
>
> No need to repeat, everybody got your point that it's been a decade, and
> that people can choose, but you want the default being the same thing as
> before, with no change possible.
i just posted the following few paragraphs to someone else in private
mail. maybe they'll help you to see the point:
it is incumbent on those who are proposing a change to demonstrate:
1. that the change has significant benefits
2. that the change does not cause problems
3. that the benefits greatly outweigh the problems caused
and,
4. that there is no viable alternative to the proposed change
changing bash to dash as the default shell fails on all four counts:
there are no significant benefits, changing it would cause problems,
the benefits do NOT greatly outweigh the problems, and point 4 fails
because there is a viable alternative (those who want dash can install
it themselves).
in short, don't do unneccessary harm and don't violate the principle of
least surprise.
> > no, it's a *stupid* extension of mine, not a "natural" extension.
> >
> > it's what is known as "grasping at straws". indicating irrationality and
> > desperation. your argument holds no water, and you know it - hence the
> > descent into absurd projection.
>
> This reminds me the SORBS thread, and ... godwin! :)
> Clearly, when somebody (if not a majority) do not agree with you, you
> start to be aggressive. There's absolutely no point in insulting others,
> and it seems you are the only one playing that game here... Please think
> twice before using words like: stupid, irrationality, or absurd when
> writing to others in public lists.
i'll use those words (or indeed, ANY words i choose) when i consider them to
be accurate.
> It's really a shame to read this when I see many very good comments from
> you helping others, showing that you are far from being stupid, and that
> your brain is full of knowledge. A bit of respect wouldn't have kill
> you, even if you don't agree.
respect is earned, not an automatic entitlement.
it's extremely difficult to have respect for stupid propositions or those who
are proposing them.
> Stop wining and upgrade your *broken* scripts.
they aint my scripts, and they aint broken.
btw, regardless of what POSIX sh should or shouldn't be, on debian,
/bin/sh has always been bash. and has been documented as being bash.
see "man sh" - it clearly states that it is bash and it documents the
features of bash. it is entirely reasonable for a debian user to use the
features AS DOCUMENTED, whether you or POSIX or anyone else thinks that
is "correct" behaviour or not.
craig
--
craig sanders <c...@taz.net.au>
Thomas Goirand
> i just posted the following few paragraphs to someone else in private
> mail. maybe they'll help you to see the point:
>
> it is incumbent on those who are proposing a change to demonstrate:
>
> 1. that the change has significant benefits
> 2. that the change does not cause problems
> 3. that the benefits greatly outweigh the problems caused
> and,
> 4. that there is no viable alternative to the proposed change
You are repeating again, so it forces us to repeat also. I think you had
better re-read the backlog to see somebody's else point, but if you
still didn't get it, then I'll have to write it again.
1. The significant benefits are: faster, lighter, and more cross
comparabilities with the Debian embedded systems. Another one is a
better compatibility with BSD systems that wont have bash by default
(you need to set it up manually or depend on it). This last one is,
IMHO, very important. Another one is that scripts with bashism will be
detected immediately, and that's great, they will be modified quicker.
2. It doesn't cause any problem for scripts written with #!/bin/bash,
only for those who were badly written with #!/bin/sh instead when
expecting bash. These scripts HAVE to be modified, and it's not a very
big deal anyway.
3. See point 1, I think it's clear there are some very big benefits, and
the only problem is badly written scripts that can be modified really
easily.
4. The alternative is to setup bash, and restor the link as it was, or
to fix the badly written scripts. Both solution are really easy...
> in short, don't do unneccessary harm and don't violate the principle of
> least surprise.
People that DO read Debian news and things like that will know in
advance, and have quite a big amount of time to fix.
> respect is earned, not an automatic entitlement.
For sure, you are not earning respect when writing this way to others.
> btw, regardless of what POSIX sh should or shouldn't be, on debian,
> /bin/sh has always been bash. and has been documented as being bash.
> see "man sh" - it clearly states that it is bash and it documents the
> features of bash. it is entirely reasonable for a debian user to use the
> features AS DOCUMENTED, whether you or POSIX or anyone else thinks that
> is "correct" behaviour or not.
But lucky, things evolve. It's not because one thing exists, or have
always been in a way, and is documented as it is, that it shouldn't be
changed if there are some good things behind the move. Debian
maintainers will simply update the documentation... Also, nobody forced
anyone to call the wrong shell, and it was never documented this way.
Also, if "man sh" brings the man page of bash, that doesn't mean
anything but the fact that bash is currently used when calling sh (the
sh man page is just a symlink to the one of bash...).
I could find so many example of things that have been in a way for
decades, and that one day, changed. And there was always some people
against evolution. I have many example in mind, but I wont give any, as
automatically, you'll say it's a fullish one for whatever reason. But I
believe you are smart enough to understand my point without giving you
yet another car example...
Thomas
P.S: Once again, people are NOT stupid because they have different point
of view. Saying so IS disrespectful, and not only for the one you are
writing to, but for all the people reading this list. IMHO, by default,
you should respect the people reading you, especially in a public lists.
Matus UHLAR - fantomas
> I would counter that if bash is to be replaced, it should be officially
> deprecated for at LEAST one full release cycle, if not two.
actually, having bashisms in /bin/sh scripts has been considered a bug for a
long time (before etch). I've seen discussion about ash being the /bin/sh
long time ago. In such case, lenny can some with dash as /bin/sh and your
requirement will be satisfied :)
Note that nobody wants bash to be deprecated/disabled, or deny anyone using
it (probably even as /bin/sh ). It even may be installed by default
(although it may be possible to remove it).
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
REALITY.SYS corrupted. Press any key to reboot Universe.
Roberto C. Sánchez
>
> in short, don't do unneccessary harm and don't violate the principle of
> least surprise.
>
you think it would be surprising to both parties if I write a /bin/sh
script (using bashism which go unnoticed on my Debian system) and then
give to someone running BSD, where it does not work?
I would say that is a huge surprise.
Craig Sanders
> Craig Sanders wrote:
> > i just posted the following few paragraphs to someone else in private
> > mail. maybe they'll help you to see the point:
> >
> > it is incumbent on those who are proposing a change to demonstrate:
> >
> > 1. that the change has significant benefits
> > 2. that the change does not cause problems
> > 3. that the benefits greatly outweigh the problems caused
> > and,
> > 4. that there is no viable alternative to the proposed change
>
> You are repeating again, so it forces us to repeat also. I think you had
actually, it wasn't a repeat. it was the first time i'd posted that. i
posted it because it seems that appropriate caution is an alien concept
to the loony change-mongers here.
> 1. The significant benefits are: faster, lighter, and more cross
> comparabilities with the Debian embedded systems. Another one is a
they may be benefits, but they're not *significant* benefits. they're
irrelevant to >99% of debian users.
> better compatibility with BSD systems that wont have bash by default
it's debatable whether that's a benefit at all.
BSD systems have their own non-GNU versions of standard utilities, so sh
scripts from linux often wont work on *bsd anyway. and vice-versa.
> (you need to set it up manually or depend on it). This last one is,
nobody sane would replace, e.g., root's shell with bash on a solaris or *bsd
or other non-bash-by-default *nix - because there's no way of knowing what
cron jobs and other stuff will break.
instead, sane people who want bash on those systems install it in /usr/local
and run "exec bash" after they su to root.
similarly, nobody sane would want to replace bash as the default sh with
dash because there's also no way of knowing what would break.
> IMHO, very important. Another one is that scripts with bashism will be
> detected immediately, and that's great, they will be modified quicker.
OTOH, another way of looking at it is that if nobody has detected
them it's because nobody cares - nobody except for a tiny handful of
people (mostly embedded systems developers and not-entirely-rational
uber-pedants) bothers to install dash and replace the /bin/sh symlink.
frankly, if they care that much, it's up to THEM to file the bug
reports, not force the burden onto the vast majority who simply don't
care about dash or POSIX compliance.
breaking other people's systems for an aesthetic goal just because
you're too lazy to bother checking the init.d scripts in packages and
file bug-reports yourself is, as i mentioned before, maliciously stupid.
bashisms in init.d & cron & other packaged #!/bin/sh scripts is a bug.
bash as the default /bin/sh is NOT a bug.
> 2. It doesn't cause any problem for scripts written with #!/bin/bash,
> only for those who were badly written with #!/bin/sh instead when
> expecting bash. These scripts HAVE to be modified, and it's not a very
> big deal anyway.
no, they DON'T have to be modified (at least, not locally-written ones.
package scripts should have the pedantically-correct #! line).
as i pointed out last time, debian's /bin/sh has always been bash, and
has always been documented as such. it is NOT broken to write a script
that uses the documented features.
> 3. See point 1, I think it's clear there are some very big benefits, and
> the only problem is badly written scripts that can be modified really
> easily.
what's very clear is that the benefits are tiny, the problems are moderately
large, and that the scripts you claim to be "badly written" aren't.
> 4. The alternative is to setup bash, and restor the link as it was, or
> to fix the badly written scripts. Both solution are really easy...
only the proposed change has the potential to break existing systems
for no good reason.
in short, there's woefully insufficient justification for making this change.
> > in short, don't do unneccessary harm and don't violate the principle
> > of least surprise.
>
> People that DO read Debian news and things like that will know in
> advance, and have quite a big amount of time to fix.
again, a tiny minority of debian users.
> anyone to call the wrong shell, and it was never documented this way.
it was. i repeat: look at "man sh" on any default debian system.
> Also, if "man sh" brings the man page of bash, that doesn't mean
> anything but the fact that bash is currently used when calling sh (the
> sh man page is just a symlink to the one of bash...).
it's been that way for over a decade. since debian began. approx 14
years of debian telling users that sh is bash and documenting it as
such. now some morons want to change that without any good reason.
> I could find so many example of things that have been in a way for
> decades, and that one day, changed.
change has to be justifiable. see the four test points in my previous
message for the bare minimum justification for any change.
> P.S: Once again, people are NOT stupid because they have different point
> of view.
of course not. they are stupid because they have a stupid point of view.
difference has nothing to do with it.
> Saying so IS disrespectful,
putting false words in my mouth and claiming that is what i said is not only
disrespectful, it is dishonest.
craig
--
craig sanders <c...@taz.net.au>
BOFH excuse #34:
(l)user error
Craig Sanders
> On Wed, Sep 26, 2007 at 05:39:29PM +1000, Craig Sanders wrote:
> >
> > in short, don't do unneccessary harm and don't violate the principle
> > of least surprise.
>
> This is *exactly* one of the things that they are trying to fix.
no, it's not. if it was, then they wouldn't be making the proposal.
> Don't you think it would be surprising to both parties if I write a
> /bin/sh script (using bashism which go unnoticed on my Debian system)
> and then give to someone running BSD, where it does not work?
no, i don't.
a person expects debian and *bsd (and solaris and aix and ......) to be
different.
they DON'T expect one debian system to be that different to another,
depending on when it was built or when it was last upgraded.
> I would say that is a huge surprise.
i wouldn't.
i regularly have to modify scripts written on one *nix-like system so
that they will work on another. it's not in the least bit surprising. it
is *expected*.
and it's not just bashisms, almost all of the standard utilities (incl.
awk, sed, grep, cat, tail, find, du, df, nice, ps, time, and hundreds
more) are different from system to system. that's one of the reasons i
install the GNU utilities in /usr/local on any system that doesn't have
them so i only have to change the PATH to get the good GNU versions.
IMO, the GNU versions *ARE* the standard. they're available for every
unix-like systems (whereas, say, solaris' or AIX's or HP-UX's versions
of tools are ONLY available on their respective systems).
Thomas Goirand
>> Don't you think it would be surprising to both parties if I write a
>> /bin/sh script (using bashism which go unnoticed on my Debian system)
>> and then give to someone running BSD, where it does not work?
>
> no, i don't.
>
> a person expects debian and *bsd (and solaris and aix and ......) to be
> different.
>
> they DON'T expect one debian system to be that different to another,
> depending on when it was built or when it was last upgraded.
I don't know for others, but I try to write scripts that would work for
many different types of Unix. The SAME script. To me, having a sh shell
that is really close to the real sh implementation WILL help in my
developments. I DO expect sh to react like sh, and not like bash. I got
traped by some bashism when writing scripts, and I really feel like
cheated by Debian on that case.
So I do expect Debian and *BSD to be different, but it would really help
if it was not. And that's why I think this change for sh is a good thing.
If it breaks 1 or 2 shell scripts there and there, then be it! Changing
to call the real bash is not as hard as you are saying!
> i regularly have to modify scripts written on one *nix-like system so
> that they will work on another. it's not in the least bit surprising. it
> is *expected*.
But being closer to the standards of other Unix helps to have LESS work
when porting. That's a very good thing.
> and it's not just bashisms, almost all of the standard utilities (incl.
> awk, sed, grep, cat, tail, find, du, df, nice, ps, time, and hundreds
> more) are different from system to system.
This really pissed me off. Especially the implementation of tar that is
different from the BSD one, and then making my md5 checksum wrong many
times. I wish it was really the same !!!
Thomas
Roberto C. Sánchez
> On Wed, Sep 26, 2007 at 05:03:38PM +0800, Thomas Goirand wrote:
>
> > better compatibility with BSD systems that wont have bash by default
>
> it's debatable whether that's a benefit at all.
>
> BSD systems have their own non-GNU versions of standard utilities, so sh
> scripts from linux often wont work on *bsd anyway. and vice-versa.
>
having read the man and info pages for lots of GNU utilities, is that
the GNU folks go to great lengths to preserve compatibility with
traditional Unix utilities.
Craig Sanders
> On Wed, Sep 26, 2007 at 07:55:02PM +1000, Craig Sanders wrote:
> > BSD systems have their own non-GNU versions of standard utilities, so sh
> > scripts from linux often wont work on *bsd anyway. and vice-versa.
>
> Whoa there. That needs some backing up. My understanding, based on
> having read the man and info pages for lots of GNU utilities, is that
> the GNU folks go to great lengths to preserve compatibility with
> traditional Unix utilities.
with which particular implementations? each vendor had (and still has)
their own versions with not-quite-compatible command-line switches and
sometimes even incompatible file & output formats.
the GNU versions are the only ones that are standard across multiple
unix-like operating systems.
craig
--
craig sanders <c...@taz.net.au>
BOFH excuse #196:
Me no internet, only janitor, me just wax floors.
Nate Duehr
On Sep 26, 2007, at 7:48 AM, Roberto C. Sánchez wrote:
> Whoa there. That needs some backing up. My understanding, based on
> having read the man and info pages for lots of GNU utilities, is that
> the GNU folks go to great lengths to preserve compatibility with
> traditional Unix utilities.
It doesn't work that way in practice. I can name off numerous
differences in low-level tools between Solaris, AIX, HP-UX, BSD,
Linux and lord knows what else.
For those using multiple OS's it's a fact of life, and has been for
two decades. Only newbies get frustrated by it. Everyone else just
deals with it, since they ARE different OS's after all...
tar is one of the biggest "offenders", being quite different on
almost every Unix platform.
--
Nate Duehr
na...@natetech.com
Nate Duehr
On Sep 26, 2007, at 5:08 AM, Thomas Goirand wrote:
> Craig Sanders wrote:
>>> Don't you think it would be surprising to both parties if I write a
>>> /bin/sh script (using bashism which go unnoticed on my Debian
>>> system)
>>> and then give to someone running BSD, where it does not work?
>>
>> no, i don't.
>>
>> a person expects debian and *bsd (and solaris and aix and ......)
>> to be
>> different.
>>
>> they DON'T expect one debian system to be that different to another,
>> depending on when it was built or when it was last upgraded.
>
> I don't know for others, but I try to write scripts that would work
> for
> many different types of Unix. The SAME script. To me, having a sh
> shell
> that is really close to the real sh implementation WILL help in my
> developments. I DO expect sh to react like sh, and not like bash. I
> got
> traped by some bashism when writing scripts, and I really feel like
> cheated by Debian on that case.
Why can't you put your chosen sh shell in your shebang, just like
you're asking others to be forced to do?
Elitism is the only logical answer. Your needs are greater than theirs.
> If it breaks 1 or 2 shell scripts there and there, then be it!
> Changing
> to call the real bash is not as hard as you are saying!
And you changing YOUR scripts is easier for a whole lot of people.
> But being closer to the standards of other Unix helps to have LESS
> work
> when porting. That's a very good thing.
Anyone porting can call the correct shell.
>> and it's not just bashisms, almost all of the standard utilities
>> (incl.
>> awk, sed, grep, cat, tail, find, du, df, nice, ps, time, and hundreds
>> more) are different from system to system.
>
> This really pissed me off. Especially the implementation of tar
> that is
> different from the BSD one, and then making my md5 checksum wrong many
> times. I wish it was really the same !!!
Good luck with that. Unix has been fragmented since AT&T System V
days. Deal with it.
That's your recommendation to everyone else for the changes you
propose, why not just follow your own advice and leave everyone else
alone?
--
Nate Duehr
na...@natetech.com
Michael Loftis
--On September 27, 2007 6:53:16 AM +1000 Craig Sanders <c...@taz.net.au>
wrote:
> On Wed, Sep 26, 2007 at 09:48:17AM -0400, Roberto C. Sánchez wrote:
>> On Wed, Sep 26, 2007 at 07:55:02PM +1000, Craig Sanders wrote:
>> > BSD systems have their own non-GNU versions of standard utilities, so
>> > sh scripts from linux often wont work on *bsd anyway. and vice-versa.
>>
>> Whoa there. That needs some backing up. My understanding, based on
>> having read the man and info pages for lots of GNU utilities, is that
>> the GNU folks go to great lengths to preserve compatibility with
>> traditional Unix utilities.
>
> with which particular implementations? each vendor had (and still has)
> their own versions with not-quite-compatible command-line switches and
> sometimes even incompatible file & output formats.
>
> the GNU versions are the only ones that are standard across multiple
> unix-like operating systems.
I'll totally agree here. Cant' tell you how many times I've had a Makefile
fail from various open source projects because of flags sent to mv and/or
cp being different, or non-existent on *BSD (FreeBSD mostly).
Nate Duehr
On Sep 26, 2007, at 3:03 AM, Thomas Goirand wrote:
> Craig Sanders wrote:
>> i just posted the following few paragraphs to someone else in private
>> mail. maybe they'll help you to see the point:
>>
>> it is incumbent on those who are proposing a change to demonstrate:
>>
>> 1. that the change has significant benefits
>> 2. that the change does not cause problems
>> 3. that the benefits greatly outweigh the problems caused
>> and,
>> 4. that there is no viable alternative to the proposed change
>
> You are repeating again, so it forces us to repeat also. I think
> you had
> better re-read the backlog to see somebody's else point, but if you
> still didn't get it, then I'll have to write it again.
>
> 1. The significant benefits are: faster, lighter, and more cross
> comparabilities with the Debian embedded systems. Another one is a
> better compatibility with BSD systems that wont have bash by default
> (you need to set it up manually or depend on it). This last one is,
> IMHO, very important. Another one is that scripts with bashism will be
> detected immediately, and that's great, they will be modified quicker.
"faster", "lighter" - please quantify. Those are not engineering
terms. How much faster? How much lighter?
It also doesn't account for what percentage of Debian systems
deployed are "embedded". If 1%, who cares? If 50%... maybe someone
has a more reasonable argument for this change, then.
Who benefits?
Making that kind of change without hard numbers is not engineering,
it's hacking and childish and non-professional.
(There, I didn't use the "stupid" word Craig used, but I'm thinking it.)
> 2. It doesn't cause any problem for scripts written with #!/bin/bash,
> only for those who were badly written with #!/bin/sh instead when
> expecting bash. These scripts HAVE to be modified, and it's not a very
> big deal anyway.
User scripts if its left alone do NOT have to be modified. They are
poorly-written, but that would be EXPECTED of non-developer, non-
professional end-users.
Why force the people already having the hardest time in the learning
curve through a harder process when anyone beyond that stage of the
learning curve can much more easily deal with loading whatever shell
they want?
Making the newbies fight through this change is elitist and wrong.
But I've come to expect that of Debian, and so have others. Wonder
if Ubuntu will follow suit or if they'll keep bash. That'd be one
indicator of whether or not the change is REALLY needed, since they
have an end-user (and thus, desktop) focus that Debian lost years ago.
> 3. See point 1, I think it's clear there are some very big
> benefits, and
> the only problem is badly written scripts that can be modified really
> easily.
You think. You don't KNOW. Engineer, don't guess.
What "big benefits" and for whom? A majority of the users, or just
for a few devs who want to mess with things?
Quantify, don't equivocate. Be professional.
> 4. The alternative is to setup bash, and restor the link as it was, or
> to fix the badly written scripts. Both solution are really easy...
Easy for us, hard for how many?
>> in short, don't do unneccessary harm and don't violate the
>> principle of
>> least surprise.
>
> People that DO read Debian news and things like that will know in
> advance, and have quite a big amount of time to fix.
Quantify. How many users of Debian read DWN? (For that matter, how
many will be notified that a change is happening -- there IS a
warning that bash is deprecated being engineered into the packages so
that their next apt-get dist-upgrade will WARN them, isn't there? If
not, the very MINIMUM that needs to happen is that the package
maintainer do that. And that will need to be added and translated to
the various languages supported, etc... just like any other warning.)
>> respect is earned, not an automatic entitlement.
>
> For sure, you are not earning respect when writing this way to others.
Perhaps he doesn't care. You apparently are more worried about his
behavior than he is. Let it go. It's not your problem unless you
choose to engage with him in a conversation, and then you already
know what to expect, so stop whining about it.
> But lucky, things evolve. It's not because one thing exists, or have
> always been in a way, and is documented as it is, that it shouldn't be
> changed if there are some good things behind the move. Debian
> maintainers will simply update the documentation... Also, nobody
> forced
> anyone to call the wrong shell, and it was never documented this way.
> Also, if "man sh" brings the man page of bash, that doesn't mean
> anything but the fact that bash is currently used when calling sh (the
> sh man page is just a symlink to the one of bash...).
Constant breakage and changes that add no true value are the reasons
many people use Debian over other distros. It's not "evolution" when
other distros do this type of thing, it's just software churn for no
real engineered/quantified reason at all.
> I could find so many example of things that have been in a way for
> decades, and that one day, changed. And there was always some people
> against evolution. I have many example in mind, but I wont give
> any, as
> automatically, you'll say it's a fullish one for whatever reason.
> But I
> believe you are smart enough to understand my point without giving you
> yet another car example...
You could also find examples of a lot of people annoyed and/or
inconvenienced by those changes where ultimately all the people
making the change did, is cause them more effort for little return.
> P.S: Once again, people are NOT stupid because they have different
> point
> of view. Saying so IS disrespectful, and not only for the one you are
> writing to, but for all the people reading this list. IMHO, by
> default,
> you should respect the people reading you, especially in a public
> lists.
Not your problem.
You're making all the political arguments for this, but haven't
provided a whit of engineering documentation to back any of it up.
If it's so much better, why is there a debate at all? It generally
holds true that major changes that "make sense" to a large number of
people are the right thing to do. Major changes that garner debate
will also garner breakage, confusion, weeping and gnashing of teeth
for too many people to really be much of a net-benefit to either the
people using the Debian distribution, or the image of the distro in
the world/community stage.
Re-worded, will a majority other distros and their users applaud this
major change as something they "wish all distros did"? And then copy
Debian's lead?
If not... it's not worth doing... and it's not leadership. It's just
tinkering and screwing things up that don't need to be touched.
--
Nate Duehr
na...@natetech.com
Thomas Goirand
> "faster", "lighter" - please quantify. Those are not engineering
> terms. How much faster? How much lighter?
>
> It also doesn't account for what percentage of Debian systems deployed
> are "embedded". If 1%, who cares? If 50%... maybe someone has a more
> reasonable argument for this change, then.
The 2nd most popular arch after i386 and amd64 is arm, just because
people use it on small end routers like with OpenWRT. For that kind of
hardware, memory & speed DOES count, and there's quite a lot out there.
I don't know where to find the numbers, I didn't search for them (they
must be quite easy to find), but it should be quite enough to take care of.
> Making the newbies fight through this change is elitist and wrong. But
> I've come to expect that of Debian, and so have others. Wonder if
> Ubuntu will follow suit or if they'll keep bash.
Taking care of the poorest writer is not the best way to go either. And
if I'm not mistaking, Ubuntu did the switch to dash already, didn't
they? (please correct me if I'm wrong)
Thomas
Nate Duehr
> The 2nd most popular arch after i386 and amd64 is arm, just because
> people use it on small end routers like with OpenWRT. For that kind of
> hardware, memory & speed DOES count, and there's quite a lot out there.
> I don't know where to find the numbers, I didn't search for them (they
> must be quite easy to find), but it should be quite enough to take care of.
So the third most popular arch sets the standard?
That's by itself, the tail wagging the dog.
And the example of OpenWRT is a bad one, since that's a distro in and of
itself -- and it isn't someone loading an ARM machine with Debian.
They load it with an image from the developers who already knew how to
change the shell and strip down Debian already for them. (They do a lot
more than change the shell!)
Only a handful of people (the OpenWRT team) benefit from a shell change
to dash, in your example.
Again, I ask -- what's the driving need?
> Taking care of the poorest writer is not the best way to go either. And
But it causes the least harm to the largest group of people.
> if I'm not mistaking, Ubuntu did the switch to dash already, didn't
> they? (please correct me if I'm wrong)
No idea. I don't run it, right now anyway... someone will probably let
us know.
Nate
Matus UHLAR - fantomas
> >many different types of Unix. The SAME script. To me, having a sh shell
> >that is really close to the real sh implementation WILL help in my
> >developments. I DO expect sh to react like sh, and not like bash. I got
> >traped by some bashism when writing scripts, and I really feel like
> >cheated by Debian on that case.
On 26.09.07 15:28, Nate Duehr wrote:
> Why can't you put your chosen sh shell in your shebang, just like
> you're asking others to be forced to do?
he does - he uses /bin/sh. But some linux lamers (unluckily this means many
of linux distributions) install bash as /bin/sh which is incompatible.
> Good luck with that. Unix has been fragmented since AT&T System V
> days. Deal with it.
Yes, we are tyrying to be compatible, and some bash lamers object against
it.
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Windows found: (R)emove, (E)rase, (D)elete
Jean-Paul Blaquiere
> Again, I ask -- what's the driving need?
>
The only thing I can think of is for DR, for when your /lib or /usr/lib
has gone away.
I used sash for exactly that a while ago but *shrug* it was never a
driving need, merely a point of convenience, and a personal one at that.
> >if I'm not mistaking, Ubuntu did the switch to dash already, didn't
> >they? (please correct me if I'm wrong)
>
It's not installed in Dapper but it is in Edgy (and probably later
dists).
./jp
--
Jean-Paul Blaquiere
jean...@blaquiere.id.au
http://www.blaquiere.id.au
http://japester.ucc.asn.au/
Nate Duehr
>>> I don't know for others, but I try to write scripts that would work for
>>> many different types of Unix. The SAME script. To me, having a sh shell
>>> that is really close to the real sh implementation WILL help in my
>>> developments. I DO expect sh to react like sh, and not like bash. I got
>>> traped by some bashism when writing scripts, and I really feel like
>>> cheated by Debian on that case.
>
> On 26.09.07 15:28, Nate Duehr wrote:
>> Why can't you put your chosen sh shell in your shebang, just like
>> you're asking others to be forced to do?
>
> he does - he uses /bin/sh. But some linux lamers (unluckily this means many
> of linux distributions) install bash as /bin/sh which is incompatible.
He can call the SPECIFIC shell he wants, and not use /bin/sh.
>> Good luck with that. Unix has been fragmented since AT&T System V
>> days. Deal with it.
>
> Yes, we are tyrying to be compatible, and some bash lamers object against
> it.
The problem is, the original designers of Linux distros screwed you over
and chose bash as the standard shell. Your beef is with them, not the
current users, known as "bash lamers" to you.
Changing it "back" now just causes unnecessary grief for everyone except
the people who ALREADY understand the original Linux distro "sin".
Nate
Matus UHLAR - fantomas
> >>Why can't you put your chosen sh shell in your shebang, just like
> >>you're asking others to be forced to do?
> >
> >he does - he uses /bin/sh. But some linux lamers (unluckily this means many
> >of linux distributions) install bash as /bin/sh which is incompatible.
On 27.09.07 03:01, Nate Duehr wrote:
> He can call the SPECIFIC shell he wants, and not use /bin/sh.
the /bin/sh is SPECIFIC. It's standard bourne shell, which bash is not 100%
compatible with.
How would you feel if someone created shell similat to, but incompatible
with bash, and put /bin/bash as symlink to it, made it a default shell,
started making /bin/bash scripts that bash can't process (because of
incompatibilities) and finally started crying whenever someone complains?
It's sick. It's broken. If you want to be broken, just be. But don't force
us being broken and don't tell us that being broken is standard.
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
"One World. One Web. One Program." - Microsoft promotional advertisement
"Ein Volk, ein Reich, ein Fuhrer!" - Adolf Hitler
Giacomo A. Catenazzi
>>>> Why can't you put your chosen sh shell in your shebang, just like
>>>> you're asking others to be forced to do?
>>> he does - he uses /bin/sh. But some linux lamers (unluckily this means many
>>> of linux distributions) install bash as /bin/sh which is incompatible.
>
> On 27.09.07 03:01, Nate Duehr wrote:
>> He can call the SPECIFIC shell he wants, and not use /bin/sh.
>
> the /bin/sh is SPECIFIC. It's standard bourne shell, which bash is not 100%
> compatible with.
Could you be more specific?
BTW bash called as "sh" behave differently as if it is called as "bash".
But I see in Austin group (POSIX standardization), that there are changes
in both directions:
bash try to be more compatible to POSIX (when they found differences)
and POSIX try to be more like bash when bash behavior is better.
Anyway, bash has extensions, but this doesn't mean that it is not
compatible.
ciao
cate
Christoph Moench-Tegeder
> > He can call the SPECIFIC shell he wants, and not use /bin/sh.
> the /bin/sh is SPECIFIC. It's standard bourne shell, which bash is not 100%
> compatible with.
In fact, it's not that simple. It's "mostly some variant of bourne shell
and sometimes a korn shell (88-variant) or something else bourne-compatible"
(for varying levels of "compatible"). The following page has some (slightly
outdated) information: http://www.in-ulm.de/~mascheck/various/shells/
Better stick with "the linux way" and bash, just to not add further
confusion.
Regards
Christoph
--
Spare Space
Matus UHLAR - fantomas
>
> > > He can call the SPECIFIC shell he wants, and not use /bin/sh.
> > the /bin/sh is SPECIFIC. It's standard bourne shell, which bash is not 100%
> > compatible with.
On 27.09.07 12:49, Christoph Moench-Tegeder wrote:
> In fact, it's not that simple. It's "mostly some variant of bourne shell
> and sometimes a korn shell (88-variant) or something else bourne-compatible"
> (for varying levels of "compatible"). The following page has some (slightly
> outdated) information: http://www.in-ulm.de/~mascheck/various/shells/
> Better stick with "the linux way" and bash, just to not add further
> confusion.
I don't think why should we stick with worst way ;)
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Windows 2000: 640 MB ought to be enough for anybody
Joey Hess
> So the third most popular arch sets the standard?
>
> That's by itself, the tail wagging the dog.
Actually, we don't have any good statistical basis to compare the number
of i386 and arm systems that use Debian. There are large numbers of
Debian arm systems that various vendors[1] know about, but that do not
participate in the popularity contest.
> And the example of OpenWRT is a bad one, since that's a distro in and of
> itself -- and it isn't someone loading an ARM machine with Debian.
>
> They load it with an image from the developers who already knew how to
> change the shell and strip down Debian already for them. (They do a lot
> more than change the shell!)
>
> Only a handful of people (the OpenWRT team) benefit from a shell change to
> dash, in your example.
OpenWRT is not based on Debian at all AFAIK. However we do have many
good examples of people loading ARM machines with Debian, the most
commonly-reported two being the nslu2 and the thecus. Arm jumped from
about #8 to #3 in the popcon stats in less than a year, largely due to
people installing it on the nslu2.
--
see shy jo
[1] Including my employer.
Thomas Goirand
> However we do have many
> good examples of people loading ARM machines with Debian, the most
> commonly-reported two being the nslu2 and the thecus. Arm jumped from
> about #8 to #3 in the popcon stats in less than a year, largely due to
> people installing it on the nslu2.
It's a bit off-topic for this thread, but I thought it might be a good
advice.
<pub>
We got a Planex NAS 01-G which is based on power PC, has 64 MB of RAM, a
gigabit eth, and runs Debian etch in a chroot wonderfully. We are going
to set it up on all of our location for doing backups with dirvish.
I recommend this product to everyone, it's great, for only 125 USD from
www.planex.net !
</pub>
Thomas
P.S: I have no shares of that company... :)
Dan MacNeil
[snip]
> We are going to set it [snipped] up on all of our location for doing
> backups with dirvish.
We're using rdiff-backup through backup-ninja and are only 90% happy
with it. Sarge/Etch rdiff-backup archives aren't comparable. Syntax for
recovering from backups older than a day requires a trip the man page.
How does dirvish compare to rdiff-backup ?
Thomas Goirand
> Thomas Goirand wrote:
> [snip]
>
>> We are going to set it [snipped] up on all of our location for doing
>> backups with dirvish.
>
> We're using rdiff-backup through backup-ninja and are only 90% happy
> with it. Sarge/Etch rdiff-backup archives aren't comparable. Syntax for
> recovering from backups older than a day requires a trip the man page.
>
> How does dirvish compare to rdiff-backup ?
What dirvish does is that it does a first backup with rsync, then it
does it's incremental backups using hardlink. So it's quite strait
forward to use, and I don't think there are incomparability problems
with anything.
Thomas
Keith Edmunds
> We're using rdiff-backup through backup-ninja and are only 90% happy
> with it.
We switched from rdiff-backup (after using it for a number of years) to
backuppc. BackupPC uses rsync, combines common files in a pool, has a web
interface, and has proved more reliable and more flexible than
rdiff-backup. Worth considering.
Keith
Chris Bannister
> On Wed, Sep 26, 2007 at 05:44:40AM -0400, Roberto C. S?nchez wrote:
> > On Wed, Sep 26, 2007 at 05:39:29PM +1000, Craig Sanders wrote:
> > >
> > > in short, don't do unneccessary harm and don't violate the principle
> > > of least surprise.
> >
> > This is *exactly* one of the things that they are trying to fix.
>
> no, it's not. if it was, then they wouldn't be making the proposal.
Isn't this all about posix compliance.
(1) /bin/sh is supposed to be posix compliant.
(2) /bin/bash is not necessarily posix compliant because of bash extensions.
(3) If /bin/sh is sym linked to /bin/bash and a script is called with
the /bin/sh shebang, bash tries to behave in a posix compliant manner
and therefore if the script has bash extensions it will (should(?))
break and therefore the script should be called with the /bin/bash
shebang so the script can use bashisms.
(4) If /bin/sh is linked to /bin/dash or /bin/ash then posix compliance
is achieved because /bin/dash and /bin/ash are posix compliant shells.
(5) Debian is striving to be fully posix compliant.
--
Chris.
======
Jan-Benedict Glaw
> On Wed, Sep 26, 2007 at 08:05:33PM +1000, Craig Sanders wrote:
> > On Wed, Sep 26, 2007 at 05:44:40AM -0400, Roberto C. S?nchez wrote:
> > > On Wed, Sep 26, 2007 at 05:39:29PM +1000, Craig Sanders wrote:
> > > >
> > > > in short, don't do unneccessary harm and don't violate the principle
> > > > of least surprise.
> > >
> > > This is *exactly* one of the things that they are trying to fix.
> >
> > no, it's not. if it was, then they wouldn't be making the proposal.
>
> Isn't this all about posix compliance.
>
> (1) /bin/sh is supposed to be posix compliant.
AFAIR, /bin/sh is a bourne shell, not neccessarily a POSIX compatible
shell. If you formally want a POSIX shell, prepare a POSIX compatible
environment and use the first `sh' from $PATH.
> (4) If /bin/sh is linked to /bin/dash or /bin/ash then posix compliance
> is achieved because /bin/dash and /bin/ash are posix compliant shells.
This is IMHO the result of (most of) the implementations, but not
covered by the POSIX standards.
MfG, JBG
--
Jan-Benedict Glaw jbg...@lug-owl.de +49-172-7608481
Signature of: The course of history shows that as a government grows, liberty
the second : decreases." (Thomas Jefferson)
Craig Sanders
> On Wed, Sep 26, 2007 at 08:05:33PM +1000, Craig Sanders wrote:
> > On Wed, Sep 26, 2007 at 05:44:40AM -0400, Roberto C. S?nchez wrote:
> > > On Wed, Sep 26, 2007 at 05:39:29PM +1000, Craig Sanders wrote:
> > > >
> > > > in short, don't do unneccessary harm and don't violate the principle
> > > > of least surprise.
> > >
> > > This is *exactly* one of the things that they are trying to fix.
> >
> > no, it's not. if it was, then they wouldn't be making the proposal.
>
> Isn't this all about posix compliance.
no, it's about "outing"[1] package scripts that have #!/bin/sh but use
bashisms.
bash itself IS posix-compliant, in that it can run posix-compliant
scripts. being a superset of posix sh does NOT make it non-compliant.
packaged scripts that use bashisms but wrongly declare themselves to be
posix compliant (i.e. with #!/bin/sh) are non-compliant. not bash.
[1] i.e. deliberately causing breakage in order to encourage users to
file bug reports.
the fact that this act of vandalism will ALSO break users' locally
written scripts, not just packaged scripts, is ignored - or, at best,
hand-waved away - by the zealots who are proposing it. their view of the
Way Things Should Be trumps all other considerations.
in short: the bugs are in packaged scripts with incorrect shebang lines.
the correct fix is to file bug reports on those packages and get them
fixed, not to arbitrarily break lots of other unrelated things.
there aren't many of these bugs remaining - the proponents of this idea
would be doing far more useful work if they concentrated on getting
those fixed than on breaking stuff by forcing their preference for
ash/dash on everyone else.
craig
--
craig sanders <c...@taz.net.au>
Noah Dain
> On Fri, 28 Sep 2007 15:06:52 -0400, d...@thecsl.org said:
>
> > We're using rdiff-backup through backup-ninja and are only 90% happy
> > with it.
>
> We switched from rdiff-backup (after using it for a number of years) to
> backuppc. BackupPC uses rsync, combines common files in a pool, has a web
> interface, and has proved more reliable and more flexible than
> rdiff-backup. Worth considering.
>
> Keith
The only thing backuppc seems to be missing over rdiff-backup is ACL
and xattr support.
The pooling feature will be great for backing up virtual machines.
--
Noah Dain
"The beatings will continue, until morale improves" - the Management