Looking for reasonable Advices which Shell to use for scripting

Peacekeeper2000

Active Member

Reaction score: 3
Messages: 100

While I am not new to UX, I currently use ZSH only interactive and for some very small scripts. During my current build of a longer ZFS backup script, I found some unexpected behaviour of the ZSH - which are in the end total correct if you understand how ZSH extend/expanse/match etc. variables.
Also I missed some C standard functions for string handling (like left, right etc.).

When I was looking for learning sources, I often find most of the scripts are using the Bourne Shell (sh); while I have some difficulties to find sources for zsh ( seems it is often only used for interactive use) .

So I wonder if I could get some reasonable advices if I should use sh in the future for scripting or stay with zsh. Staying with zsh would have the advantage , that I only need to learn one syntax - even when there are not a lot scripting tutorials/examples available. What do you think ?
 

drhowarddrfine

Son of Beastie

Reaction score: 1,845
Messages: 3,897

Unless you have a compelling reason to use another, just use the built-in shells, but that's your opinion-based decision. Otherwise this becomes a "What's your favorite language?" question and that has already been asked on this forum.
 
OP
P

Peacekeeper2000

Active Member

Reaction score: 3
Messages: 100

Oh, just recognised: Who ever moved this to the right forum section : a big thank you ! Sorry, I was not aware of this section
 

Jose

Aspiring Daemon

Reaction score: 489
Messages: 646

I've recently been using shells/mksh because I'm old and weak-minded and I missed the ctrl-r history search from Bash. It's only ok so far. The two things that annoy me most about it are that it arbitrarily truncates command lines it considers long, and that the history file is binary so I can't grep it.

I use a scripting language whenever I find myself writing more than a dozen lines or so in shell, though. The only way to win the shell scripting game is not to play.

Yeah, there's no ideal scripting language either. That's a whole separate religious battle in its own right. FWIW, as of FBSD 13, Lua is now in core. Doesn't look like you can do much with it yet, though.
 
OP
P

Peacekeeper2000

Active Member

Reaction score: 3
Messages: 100

... and I missed the ctrl-r history search from Bash. It's only ok so far. The two things that annoy me most about it are that it arbitrarily truncates command lines it considers long, and that the history file is binary so I can't grep it.
Ok, when I get it right, soshells/mksh that would be another .. say login shell for interactive usage. I am happy with shells/zsh and I also have shells/zsh-navigation-tools installed. That brings a very easy Shell-History navigation and other good addition to the shell.

And a big smile for your comment about "win by not playing" . Lua sounds interesting as it is also available in other type of systems ( like network devices) - but would go away from shell scripting.

Thanks to all for your replies, hints and advices !

I think I will give shells/sh a try for scripting. Knowing sh is also good for crash recovery as root is using this shell. Other scripting languages like python are also on my list to learn more, but I also want to recover my C/C++ skills - but that is off-topic
 

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 10,164
Messages: 35,668

I missed the ctrl-r history search from Bash.
bindkey '^R' i-search-back for tcsh(1). You can use bindkey(1) to (re)bind a bunch of keys, with lots of options. On bash(1) you use the bind(1) command for this. Principle is the same, they just have different keys bound to different functions by default. You can make bash(1) act more like csh(1) or vice versa with a bit of effort. I like tcsh(1) history-search-backward for example. So I've modified the cursor keys on bash(1) at work (stuck with RHEL there) to act the same way.

I think I will give shells/sh a try for scripting.
Just use /bin/sh, it's included in the base, not a port.

Knowing sh is also good for crash recovery as root is using this shell.
Root's shell is csh(1) by default. Still useful to learn some interactive sh(1) tricks, in case you get stuck in single user mode (which defaults to loading /bin/sh).

For interactive use, just pick a shell you like. It really doesn't matter which one you're most comfortable with. I just learned to use the standard tcsh(1) interactively because it doesn't require installing anything, it's always available. For scripting purposes however stick to sh(1). It will provide the most portable scripts and they'll still work without having to install a port. If you can't hack it with sh(1) because things get too complex then you should consider using a scripting language (Perl, Python, etc) instead of a shell.
 

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 10,164
Messages: 35,668

I kicked csh and its derivatives to the curb because you can't redirect stderr.
You can, but not separately from stdout. Which could be annoying, yes. I don't use it interactively that way, so I'm not bothered by it.
 
OP
P

Peacekeeper2000

Active Member

Reaction score: 3
Messages: 100

Just use /bin/sh, it's included in the base, not a port.

Root's shell is csh(1) by default. Still useful to learn some interactive sh(1) tricks, in case you get stuck in single user mode (which defaults to loading /bin/sh).
OK, that was more a fault of using the wrong forum style. I meant to use /bin/sh .
And yes, I thougzht crash recovery is always as single user where you use /bin/sh. I am using the user toor for a longer root session. There I switched also to shells/zsh to have a common environment.

Using other scripting languages as a replacement of shell scripting is currently not on my list. Most of the time , shell script is good enough. Just sometimes I bounce on the boundaries of a shell languages ( like the mentioned C string functions).

I learnt on HP Apollo with HP-UX , CDE Env and the korn shell multiple decades ago. Now with to HP Microserver in the cellar for NAS and others, I try to setup a good development environment using the minimal possible no of packages. So shell scripting is only one battle to fight ( and currently to get my backup scripts with zfs running) . So future scripts for shells will use /bin/sh for easier handling of expectation.
 
Top