So as some (none) of you might know, I've been using OpenBSD for some time by now. When I started, I decided to try shell scripting in actual shell for once. Before that, I mainly used ruby. I like ruby, but I wanted to try some actual shell.
So what did I use? Bash? POSIX sh? Zsh? Well, lets just say that BSDs do not ship with Bash for GNU reasons and OpenBSD decided to include the Korn shell instead. (and csh is also istalled for some reason) I thought I might as well try the default shell of the system I actually use, sooo...
The Korn shell is a POSIX complient shell developed by David Korn (no connection to the band) in 1983. Ksh was supposed to be the next shell afrer the Bourne shell. This goal was shared with csh and zsh, with which they all copied features from each other.
Ksh was proprietary Bell Labs software, which led to few things. First of all, there is a bunch of free clones. Second, (if I'm not mistaken) the development stopped at some point. It later continued and the source code has been released as free software, but OpenBSD ships with pdksh, which still uses the old standard.
It misses some modern features and it feels a bit rough at times, but using the new version would defeat the point of using the default OpenBSD shell, so I'll stick with it. I like learning about old technology anyways.
So, how does one use pdksh? Well, not that well by default. Not only do you get just a simple prompt that does not even contain pwd, but it is in vi mode by default. Did you knew that most shells have vi mode? It's both true and annoying!
So you just set up a config file, right? well, not quite. You see, ksh by default looks into your '.profile' file. It looks there only in the login shell however. If you wan't it to look smewhere every time, you need to set the 'ENV' variable pointing to some file. I mad mine point to '~/.kshrc'.
you can find it here.
It behaves a lot like any other shell. It has it's quirks tho. For example, it has a feature where if your command is too long, instead of continuing on the next line, it scrolls sideways. It's interesting approach, but it is very dependant on the length of your prompt. It can't count double-line prompts, or even escape codes properly, so I have to help it a bit there using the '\[' and '\]' escape characters. They end and start character counting.
I opted for a bit more minimal prompt this time.
You also have to set 'HISTFILE' if you wish for inter-session history. It's fun, because the shared history is updated in all instances in real time. In fish, each instance has it's own history and they just share the save file. I kinda prefer that, but it hasn't bothered me enough to search if I can change it, so not that big of a deal I guess.
It's a usable shell that has about what you need and expect from a shell of this type.
I have tried to write some scripts. I'm not good at comming up with ideas, so I tried some exercises I found online and reimplemented a version of tic-tac-toe originally written in python I had laying around for reasons.
It's not exactly the most shell thing to implement, but it shows you a bunch of language features.
Some things to note. BSD versions of some commands differ from theGNU versions, as GNU added a bunch of extra features. this made mainly grep(1) and sed(1) a bit harder to work with. You can still install the GNU versions, but I perfer to have as little dependencies as possible.
I would say that the shell is fine, but not great. It is enough when you want to just run a bunch of commands, save some output into a varible to use later, add some user interactivity and a bit of flow control. Not that great for bigger stuff tho.
I know that some stuff can be done better in some shells, but it doesn't change that much. no multi-dimensional arrays. Unnecesary keywords...
The syntax is complex, which makes writing stuff feel slow. Why do I need to enclose arrays in '${}' every time I want to use them? It is very obvious that everything is text and you mostly just do text substitution. Unlike TCL (which I still need to take look into, so be aware that I have no idea of what am I talking about), which uses this approach to achieve a very free-style syntax and powerfull metaprogramming, here you still have a restrictive syntax and it doesn't do much more than calling interpolated command from ruby.
This leads me to the main point. I thought that command calls and functions being syntatically the same would make using commands flow better than in ruby. But the extra bacticks and intepolation are way less typing than the syntax of the shell and when you get a output, you can just '.gsub(a, b).split(c).sort.each { |i|' and you have very powerfull and consise language to use on whatever the command returned.
Here is a little script I made for searching OpenBSD repos. 'pkg_info -Q' searches only in the official repo and openports.pl does not include all packages from the main repo. This script takes a text and searches it in both packages and ports. It can be written in ksh (this one even is in POSIX sh!), but do I get something by not using ruby? It's just my personal script after all...
Well, I will try some more shell scripting later, once I get some need for it.
For now, I'm not impressed.