I don't understand. Is there something wrong with the Korn shell? In their book "Learning the Korn Shell" Rosenblatt and Robbins say the Korn shell, unlike most other shells, can be installed as the system shell, replacing the Bourne shell (p.321). Is this bad advice? I'm genuinely curious. Perhaps I'm misinterpreting your tone but it comes across as elitist. I use the Korn shell because it allows me to have a consistent shell in both Slackware and NetBSD, and also because I think it's a nicer shell than Bash. If there's something utterly ridiculous about this I'd like to know before I go any further with it!

Bash is the default system shell of GNU/Linux and bsd/sysvinit because it uses universal shell scripting compliance methods when booting the machine.

You are not limited to using just Bash within the GNU/Linux environment on user accounts, but the administrator(root) should always use Bash natively.

Although the Korn Shell may be more POSIX compliant, it is not truly geared to run the low level system administrative functions Bash does any more. While some books say you can replace the Bourne Shell with the Korn Shell, it is actually not recommended you do so.

To fix the problem is simple... use Bash for root and boot, and set up your user account(s) to use Korn Shell.

Could you elaborate a bit, or give examples? I don't know what are these "universal shell scripting methods" that bash have and that miss in other shells like ash (if I understand you).

Again, could you please provide examples of these low level administrative functions the only bash has? (as I'm not familiar with ksh I'd like to know if these functions are also missing in ash).

Well, I fixed the ones that I need to use ash, and everything seems to work ok so far.

I used:
http://sourceforge.net/projects/checkbaskisms/
with the '-p -x' mode.

It usually involves changing:
'-a' to '] && [' and '-o' to '] || ['
fixing sourced with parameters: '. /etc/rc.d/rc.mysqld stop' becomes just '/etc/rc.d/rc.mysqld stop'
fixing files run explicitly with 'sh': 'sh /etc/rc.d/rc.messagebus stop' becomes just '/etc/rc.d/rc.messagebus stop'
'echo -n' or -en becomes 'printf'
'&>/dev/null' becomes '>/dev/null 2>&1' which is much more portable
get rid of '$' in front of strings: '$"Usage: $0 {start|stop|restart|reload|status}"' becomes '"Usage: $0 {start|stop|restart|reload|status}"'
get rid of 'local', although it probably will still work with ash
use just "$@" in rc.sysvinit startup()
in rc.S expand '/bin/rm -f /etc/mtab{,~,.tmp} && /bin/touch /etc/mtab' into '/bin/rm -f /etc/mtab /etc/mtab~ /etc/mtab.tmp && /bin/touch /etc/mtab' which is what it would expand to anyway

Things I removed:
rc.inet1 is unexecutable as I already use network manager
the rc.S LUKS part using arrays, I don't even use LUKS, but you could fix it up using cut or awk.
init.d/functions, it is very hard to fix and useless in most cases (except rc.cgred)

EDIT:
Of course I also changed '#!/bin/sh' to '#!/bin/ash'. I did NOT relink /bin/sh, because that may break a lot of scripts, not my scripts tho.

Not sure how up-to-date this was but...

http://www.unix.com/answers-to-frequ...nt-shells.html

Bash is able to do Process Substitution whereas Korn Shell can not. All I know is every book I've read or question that I've seen here all say that you should always uses Bash for the system/root shell and turn the user accounts over to their own shells.

On that page it is written:So no, this is not really up to date (but maybe still valid, I just don't know).

Reading this I don't understand why this feature is needed, say in init scripts. At least it is not used in Slackware init scripts:That doesn't give me the practical examples I asked for. So I still don't understand your statements I quoted in blue.

Not sure about other BSDs but on NetBSD Bash is most certainly not the default system shell. It's not even installed by default. During installation you're given a choice of three options - sh, ksh and csh. No sign of bash there. I'd be very surprised as well if Bash was the default system shell on OpenBSD.

I'd really like an authoritative answer to the questions I posed, from someone who understands the ins and outs of changing the default system shell. If Bill Rosenblatt and Arnold Robbins in their definitive guide to the Korn shell say you can safely replace the system Bourne shell with the Korn shell why are people here saying you most certainly cannot? I'm thoroughly confused about this now.

They are not talking about Linux systems (evidence: there is no single "system shell", neither for all Linuxes, nor even within some distros -- e.g. Slackware uses either bash or busybox, depending on context. None of them ship classic Bourne Shell. The classic Bourne Shell is not bash and was dead before Linux was born.)

That statement is very badly out of date (evidence: they refer to "Bourne shell" instead of the Posix shell), and was only ever intended to apply to commercial Unixes (evidence: ksh was not available under a free licence for many years).

Sorry to knock your gods off their pedestal.

1 members found this post helpful.

Well if I'd realised using ksh instead of bash would offend so many around here I'd never have opened my mouth to ask a question in this thread.

Thanks for your uninformed opinion. It's nice to know there are people around who understand the contents of a book better than I do, even though they've never actually had that book open before their eyes.

It seems Linux elitism is alive and kicking even in the Slackware forum. A sad day indeed. I'm out of here.

Hey! Calm down!

It can hardly be news to you that loose statements in a book written in 1993 don't really grok Linux, which first saw the light of day in... 1991. The O'Reilly book is not ksh.

FYI I personally consider ksh to be vastly superior to bash in many regards, and that it's highly regrettable that AT&T killed any hope of wide adoption by hanging onto a restrictive licence until long after bash became impossible to dislodge, but hey, apparently I'm an uninformed elitist, so what would I know.

The >( cmd ) and <( cmd ) process substitutions are quite handy in bash
You usually use them to avoid this problem (without having to resort to named pipes)
bash runs a pipeline in a subshell so the value in $out doesn't survive to be used outside of the loop later on.

Using these bashisms you would write it as
... avoiding the pipeline/subshell.


Thing is, you don't need this in ksh anyway, because it treats the scope of the variables differently to bash.
Here's a real life example of it in use from one of my bash scripts:
These substitutions can be useful in other places, and I use them quite a lot when I'm writing bash scripts but its mostly to avoid this variable scoping issue in a while loop. There are other ways to workaround this particular issue though.

Here's another example from further down in the same script where I use them for a purpose unrelated to escaping the scope of a while loop:

I'm sure you can appreciate how nice they are in this sort of situation, though in ksh I'd have probably used a
... pipeline to do the same job, so its just a matter of style more than anything else when you're using them like this.

As I said above the main reason you tend to need them in bash is because bash does strange things to pipelines.

3 members found this post helpful.

The problem is simply this... Most shell scripts are written in a syntax for Bash. For this, blame the guy who wrote the script. While for every day usage you can use any other shell, typically any system boot scripts are written for Bash syntax.

To effectively switch to korn shell you should evaluate the scripts and audit the syntax to match for korn shell.

I work in a mixed Solaris / Red Hat Shop - but it was originally all Sun/Solaris - and the system shell for most the in-house work is Korn. Not surprising, but quite a few 'Kornisms' exist in our scripts. I can't say that I've ever looked carefully into which shell is used by the init scripts; but I wouldn't be suprised to learn all the Solaris hosts use ksh while all the Red Hat hosts use bash. I don't think it's elitism; just momentum. Between the two shells, I prefer Korn myself - probably that momentum thing. Occasionally, Ive had to debug Bash scripts; unless management tells me otherwise, I leave them as Bash scripts. So long as they're portable enough to run on both sets of hosts, everything's good.

Just an opinion

ksh isn't 'less fit' for use as a system shell; it just won't work in Slackware because no effort was made to maintain POSIX compliance in init/administration scripts. The same may be said of various other Linux distros, though there certainly may be some that can cope (Debian does use 'dash', or at least used to, so I wouldn't be surprised if you could get ksh to work with minimal effort if any). The BSDs don't tend to rely on bash at all.

So continue using ksh if you want (there's nothing inherently wrong with it), but don't expect to be able to remove bash entirely *in Slackware*. In the end, POSIX shells are simply much less capable than full-fledged bash, ksh, zsh, etc., and it is way easier to add little shell-specific commands (often without realizing it) than to remain POSIX compliant (unless the script is trivial). And simply because bash is the most popular shell in Linux distros (by far), you are likely to encounter shell scripts with bashisms. If you are willing to fix every script you happen to come across (either in the distro you use or third-party scripts from the internet), then you can use any shell you like.

1 members found this post helpful.

Well someone's got to answer the questions...so here goes:
No that is not bad advice.

If you replace the #!/bin/sh line with #!/bin/ksh they will still work.

The current topic the OP mentioned is that some Slackware scripts have #!/bin/sh but they use bashisms so #!/bin/sh should really be #!/bin/bash, or for a little portability, #!/usr/bin/env bash.

That information is just wrong. I can't speak for all the GNU/Linux distros, but FreeBSD and OpenBSD use ksh (and according to gezley, I suppose NetBSD does as well). For FreeBSD, which if I recall correctly you use(d), bash is its own port under shells/bash.

What's your reasoning for that?

Can we get some examples for this one as well?

1 members found this post helpful.