I think FreeBSD uses csh.

This is annoying. I've should have chosen another title (like "wrong /bin/sh shebang line in /etc/rc.d/rc.S" or so).

All I wanted to say was:

1. There is Bash code in /etc/rc.d/rc.S.
2. This file has a "/bin/sh" shebang line, which is wrong.
3. The fix is easy - change /bin/sh to /bin/bash.

i am serious about this matter, as rc.S is one of the most importants scripts. I'd really like to read an oppinion from Pat about that, but I think he won't wade through all the "ksh vs. bash" pages.

Isn't that enough?

Sure /etc/rc.d/rc.S should really say /bin/sh but really, in the grand scheme of things it just doesn't matter and if it ain't broke, don't fix it.

Well, I've been using KornShell for..., um, just about 25 years (in Unix, Solaris and Slackware) with zero problems. During that time, BASH came along, tried it, didn't much like it and it kept "improving" (read: bloat). Too, BASH incorporates a great deal of the functionality (and syntax) of both KornShell and Bourne (along with the C-Shell thrown in for good measure).

User accounts on my systems (and those that I've administered over time) have defaulted to /bin/ksh (users are free to change to BASH if they want, most haven't). Haven't had too many complaints.

Leaving system software (including all start up, shut down, rc's alone) to execute as /bin/sh (which, yeah, is BASH, not actual sh) is no problem; things work if you let them.

There is no reason to remove BASH, leave it there, just don't use it -- just change the account shell in /etc/passwd from /bin/bash to /bin/ksh and life is good. Wouldn't mess with the system accounts (except root which is /bin/ksh on all my systems).

I would note that the above has never resulted in any difficulties whatsoever.

Hope this helps some.

Bash is designed to be invoked as 'sh' - check the man page:
There are certain pieces of functionality in bash which only work if you switch off POSIX compliance (set +o posix).
Perhaps bash *shouldn't* execute the code you're referring to if it's mimicking the behavior of 'sh' - maybe you should check with the authors of bash?

Once again, two wildly inaccurate statements. The second edition was heavily revised and appeared in 2002, 11 years after Linux appeared and 2 years after ksh93 was released as open-source in 2000.

I'm not sure what you mean when you say the O'Reilly book is not ksh. I'm half-way through the book and it certainly seems to be all about the official Korn shell, ksh93, to me.

This is a very strange thread. If you ignore the obvious trolls this Slackware forum is invariably informative, with interesting input from people who have years of experience. But in this thread we've had more than a couple of long-established members offering completely ill-informed opinions, if not indeed outright falsehoods. As if that wasn't bad enough, they have sought to impose certain viewpoints on other users, adopting a contemptuous and dismissive tone in the process that I for one have come to expect elsewhere in the Linux world, but not here. A sad day indeed if that elitist, patronising and ill-informed attitude takes root here.

y, arrays are a bash thing

if i read it right something like http://stackoverflow.com/questions/5...tring-variable and a counter
there is maybe a better solution but none comes to mind

there is more bashism in inet scripts and more
also shutdown scripts use "kill" that is the gnu /bin/kill in bash but builtin in ksh so you'd need to change that to /bin/kill or change the flags to be posix so ksh don't fail

There is also the issue of future proofing. If smash (the new Super Mega All-in-one shell) came along, then a simple change 'ln -s /bin/smash /bin/sh' would allow the init scripts to continue to function.

The CPL is more restrictive than, and incompatible with, the GPL. I didn't say the licence wasn't open source; I said it was restrictive. Even the CPL's progenitor (IBM) has disowned it.

The book's statement that misled you, and at least one more like it, should clearly have been excised from the 2002 revision. They were not. That's what confused you. Please don't keep shooting the messenger; it hurts, actually.

You've never seen that Magritte painting? The O'Reilly book is not ksh; the O'Reilly book is a book about ksh.

When I criticise one statement in the O'Reilly book, I am not criticising ksh, nor am I trashing the whole of the O'Reilly book, nor am I trashing *you* *personally*.

Wow. Just *wow*. Where did all that come from? <spock> Fascinating </spock>

And it's broken. When bash is started as 'sh' it enters POSIX mode, and runs /etc/profile followed by $ENV as a proper POSIX shell should do; both ksh and ash do this.

But try this: create yourself a test user with /bin/sh specified as its login shell. When you login from the login prompt on a console, everything works as expected, bash starts in POSIXLY_CORRECT mode and runs the POSIX startup scripts.

Now, try a "su - testuser" instead: bash will start in its normal native mode, not POSIX mode. The reason for this, is that bash looks at argv[0] to see whether it is running as 'sh' or not, but when started by 'su' argv[0] is 'su' and bash has no way of knowing what mode to start in. Its approach is fundamentally flawed.

This is why I was saying above that I have no problem with bash when it's run in its native bash mode, but its not a good choice to use for the POSIX /bin/sh.

So, we have the strange situation on Slackware where a user wanting a POSIX shell can't use /bin/sh as their default shell because it wont work correctly.

I accept that this is only a edge-case that the typical user will remain blissfully ignorant of, but stuff like this gets under my skin.

The user can just set /bin/ash as default shell then.

But in the other hand if the user doesn't know that invoked as sh bash behaves as a POSIX shell he or she we will invoke it with the --posix option anyway (just kidding :)

Most of my scripts begin with #!/bin/sh as a habit from using Solaris at University, but my scripts have for many years tended to use some bash-specific code (some of which requires set +o posix). I'd have moved to invoking 'bash' if it'd have been required.

My personal opinion of the standard 'sh' is that if you ever had the misfortune to have it as your shell on Solaris, one of the first things you did was to find a binary package of 'bash' and compile or install it :-)
I recall one of the first things I had to do with 'sh' was: stty erase <press backspace>
I did like Solaris though.

Ahh yes, the old backspace/del issue. Used to have to muck about with that on AIX too. :) But that's more to do with the terminal and tty layer than the shell. It's only because bash uses readline for its command line input that you don't see the problem in bash, but have the wrong terminal setting and you can still see the escape codes appear in stdin when you hit backspace when running programs that read directly from stdin without readline, even when started under bash.

If anything bash is masking the fact that your terminal isn't set up correctly.

"stty erase ^H" can still be used to fix that, but if you get the right settings in your terminal it's not necessary.
I use these Xresources for xterm:
?.vt100.metaSendsEscape: true
?.vt100.backarrowKey: false

Well, "wrong" might not the right term here. Slackware is the oldest surviving Linux distribution and predates most of what "modern" Linux distributions consider "right". Of course nowadays one might think, that /bin/sh should point to a real POSIX shell, so "bashisms" don't go by unnoticed. I agree with that.
Which is a no-op on the Slackware default install, but should make things more robust, because it removes an implicit assumption (sh = bash) and the reliance on a symlink. If you ask me, I'm not against your proposal.