simple shell question

is /bin/sh more like a Korn-Shell or more like a Bourne-shell or still something else ?
And which one is best ?
I think it's better to say that "Bourne-shell and Korn-shell are more like /bin/sh".
In the grand scheme of things, to the best of my knowledge /bin/sh is the "Bourne shell", I believe the original shell for BSD/Unix. Then came csh. Bash, tcsh, ksh, etc are all after that.
 
Currently my root shell is zsh and it executes all the sh in rc.d scripts just fine.
My recovery shell toor is oksh. As it has no dynamic dependencies.
Still I wonder is it worth to learn ksh ?
 
is /bin/sh more like a Korn-Shell or more like a Bourne-shell or still something else ?

/bin/sh is the Bourne shell.

And which one is best ?

Depends. For interactive use, probably either the tcsh (once configured - that's my personal configuration, you probably don't need all of it) or the zsh. For scripting, the KornShell (both mksh and ksh93 are pretty good); but then again, I warmly recommend to use Perl or something for scripting, instead of a shell. I, personally, am currently migrating from tcsh to the rc shell because I really don't need many interactive features. To each their own, I guess.

I believe the original shell for BSD/Unix.

csh is the BSD shell. Unix had several shells, the Thompson shell was the second one if I remember correctly; then, the Bourne shell, which was replaced by rc in the last Unix version, "V10 UNIX".
 
  • Like
Reactions: mer
Currently my root shell is zsh and it executes all the sh in rc.d scripts just fine.
My recovery shell toor is oksh. As it has no dynamic dependencies.
Still I wonder is it worth to learn ksh ?
My opinion:
Shells fall into 2 basic camps.
csh and sh (bourne). almost all of the current shells are derivatives/extensions of these.
tcsh is an extended csh
bash is an extended sh (hence it's name of Bourne Again sh)
zsh, ksh are like bash, extended versions of sh.
Beyond the compatibility, the extensions are what make scripts break. Use bashisms for substitutions and try to run it with raw sh? Gonna break. Same thing for zsh/ksh/whatever-sh.
I tend to use tcsh for my interactive term sessions, bash/sh for my scripting.
Learn another? Maybe worth it to do quick overview of differences between a new one and one you know. Then if you come across a script written in the new one, you can easily adapt.
 
csh and sh (bourne). almost all of the current shells are derivatives/extensions of these.

No, not quite - especially newer shells tend to reinvent the wheel.

Use bashisms for substitutions and try to run it with raw sh? Gonna break. Same thing for zsh/ksh/whatever-sh.

Even worse: zsh claims to have "compatibility modes" for other shells. None of those are not broken.
 
  • Like
Reactions: mer
If you care about the Genealogy...

The Bourne Shell (written by Stephen Bourne) was introduced in V7 Unix. It rapidly usurped the V6 shell (written by Ken Thompson).

Some years later, David Korn modified the Bourne Shell to produce the Korn Shell. Its principal feature was command history and editing. It took quite a while for that to escape Bell Labs. I got a bootleg copy in 1983.

In FreeBSD, I believe that /bin/sh is the Almquist Shell -- an unencumbered Posix compliant version of the System V Bourne Shell.
 
I don't use Windows on my desktop. But nushell looks interesting to filter,sort data in tables.
Note, bash is better documented ...
 
I tried nushell on freebsd. The only command showing in a table is "ls".
For instance "zfs list" does not show a table, nor does "ps" show a table.
So it's in this sense rather very limited.
But the idea is behind is good.
 
Still I wonder is it worth to learn ksh ?
The only people I come across that regularly write ksh scripts is Oracle DBAs - I know the odd old (pre-Oracle) Solaris admin that also uses it for both scripting and interactive use.

Personally my root shell is whatever the default is, my personal interactive shell is ZSH, and as much as possible I script in POSIX compliant sh with POSIX compliant tooling/arguments - depending on the task, I'll make sure it runs on Linux, macOS, and FreeBSD, I use all three so generally like my scripts to be portable.
 
The only people I come across that regularly write ksh scripts is Oracle DBAs
On AIX, all system scripting is done in ksh. It's generally the only shell that AIX people know.
generally like my scripts to be portable.
Agreed, but shell is a pretty awful programming language. I have always been of the view that as soon as a shell script got complicated it was time to move to perl(1), but that just makes me old fashioned these days.
 
On AIX, all system scripting is done in ksh. It's generally the only shell that AIX people know.

Agreed, but shell is a pretty awful programming language. I have always been of the view that as soon as a shell script got complicated it was time to move to perl(1), but that just makes me old fashioned these days.
perl(1) is much bashed upon (no pun intended!) when you google around what could be a proper scripting language. In fact, from my own experience, I find Perl pretty awful. For example: How do you prove that your regex doesn't yield a false positive? Is there support for proper way of testing your code, etc.? In general, I frown upon the whole “bash on stereoids”-pradigm that lies at the heart of Perl. Let alone the horrible ”there are a thousand ways of doing things”-syntax.

But I see it mentioned regularly here in the forum. Which makes me wonder: Is there something I do not (yet) know? Why is Perl the superior scripting languange? What are its benefits?

(sorry for getting off-topic …)
 
Why is Perl the superior scripting languange?

It is a mature, portable language that does text processing better than any other language - and it comes preinstalled on most operating systems these days and you can be relatively sure that perl is Perl 5, not "GNU Perl", not "BSD Perl", not a symlink to Python.

I find "lua" not bad as language. It's also used by the freebsd-boot-loader.

Do you plan to turn this thread into "Alain De Vos lists every language he has seen so far"? Just asking for continuity.
 
I frown upon the whole “bash on stereoids”-pradigm that lies at the heart of Perl.
Bash was released in 1989. It is not Posix compliant.
So bash scripts are only portable if you have bash (not usually an issue these days, but it was in the past).
Perl dates back to 1987. So perl was first. I remember unpacking it from comp.sources.unix.
Perl has been universally available and portable from its inception.
In fact, perl's ./Configure script paved the way for vast improvements in free software portability.
I find Perl pretty awful... What are its benefits?
It's certainly not perfect, but I find bash "pretty awful" to a much greater degree (for scripting). Perl is:
  • designed from scratch as a scripting language;
  • mature (with a vast library);
  • well documented;
  • portable;
  • powerful;
  • has integrated protections against hacking -- vital for CGI scripts -- with taint method; and
  • really fast at just about everything, but orders of magnitude faster than any shell on string handling.
Speed can be vital if you are processing large text files in real time.

Also, I know it's historical, but perl's pattern matching was just stunning (not to mention trail blazing).

Like C and C++, perl requires professional discipline to produce "good" code. i.e. there's a vast amount of rope, and plenty enough to hang yourself -- but there's usually little glory without power.
 
Perl dates back to 1987. So perl was first. I remember unpacking it from comp.sources.unix.
Perl has been universally available and portable from its inception.
In fact, perl's ./Configure script paved the way for vast improvements in free software portability.

REXX dates back to '79, though not ANSI standard until '96. (It's ok to be off-topic in this topic, right?)

https://en.m.wikipedia.org/wiki/Rexx

It's certainly not perfect, but I find bash "pretty awful" to a much greater degree (for scripting). Perl is:
  • designed from scratch as a scripting language;
  • mature (with a vast library);
  • well documented;
  • portable;
  • powerful;
  • has integrated protections against hacking -- vital for CGI scripts -- with taint method; and
  • really fast at just about everything, but orders of magnitude faster than any shell on string handling.

More or less readable. Bash code may be readable, but I find almost all GNU docs virtually impenetrable, so I rarely even try.

I used OS/2 REXX from c. '92, later rexx-imc on FreeBSD from maybe '99-'05, the latter for billing our internet-sharing club members from ppp and login logs; superb for text parsing but I can't compare it with perl. For serious stuff I use FreePascal (weird, eh?)

Speed can be vital if you are processing large text files in real time.

Also, I know it's historical, but perl's pattern matching was just stunning (not to mention trail blazing).

OS/2 REXX was fast, rexx-imc not so much, but author Ian Collier was then very helpful, as was the disparate rexx community, FidoNet list etc.

Like C and C++, perl requires professional discipline to produce "good" code. i.e. there's a vast amount of rope, and plenty enough to hang yourself -- but there's usually little glory without power.

Same can be said for any useful language I guess?

I've been working on bits of bsdconfig(8) which is sh on steroids. Talk about obscurity, though it does make sense eventually, and (mostly) works ...

cheers
 
Back
Top