sh vs. Perl

[JayBee]

Okay partisans, take up some spears...

I've read that programming in sh can actually be harmful to your health, and have variously heard that Bash is the "Shell of kings!" or "the real shell" or other such praising statements.

When scripting stuff for these forums, what do we reckon the benefits/drawbacks are of the various scripting languages out there? I agree that Bash (being fairly "standard" in most flavours of *nix out there) would probably be the ideal, but it's not part of OS X, so it's a bit of a non-starter as far as portability goes.

Being from a web background, I'm a big fan of Perl, and have written most of my custom scripts in it. However, I haven't really played much with sh or its ilk, and wonder what people's personal preferences are?

Feel free to move this into a discussion area if you like, but I figured it was UNIXy enough to warrant falling in here :)

[mervTormel]

sh programming is legit. it is csh scripts that are to be avoided...

http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/

sh is pretty much a guarantee on a unix boxen, whereas other shells are not. if you want your scripts to be portable, write them in sh, or perl.

bash is a good interactive shell, and some features make it a good scripting shell, too. bash is largely considered to be the preferred shell of professional unix gurus. bash will probably be standard in jagwire.

if you know perl, i think you are at an advantage, since it is the king of scripting; there isn't much you can't do with perl.

[JayBee]

Originally posted by mervTormel

...
bash will probably be standard in jagwire
...

Off topic, I know - but hey, it's my topic! - I thought there were problems with bash's GNU GPL nature that made it nigh-on impossible to integrate it with OS X. Something along the lines of the GPL being "infectious" if it covers a central part of an OS (like the shell, for example)?

I seem to remember that bash made an appearance in the PB, but died in the main release. Anyone got the full scoop?

[ashevin]

There is nothing wrong with including GPL software as a standard part of OS X. The GPL only stipulates that Apple would have to make the source available to those that receive OS X. It has been that providing a place to download the source is enough, and Apple already has bash available on their site.

- Avi

[JayBee]

Ah, I knew it was something like that. Cheers Ashevin.

The version I got (and I smelled a bit of "National Enquirer" in it) was that if OS X had bash in it, the whole shebang had to be GPL friendly ;)

Though why did this make them pull bash from the first release?

[Titanium Man]

There are lots of people who use different shells, and they all have good reasons to do so. For me, I decided to make bash my default because I was wanting to learn more about scripting. Since most scripts (in my small amount of experience) are written in sh I figured why not use an interactive shell that was close to what I'd be writing scripts in? Some people say that zsh is king, and others are happy with tcsh. It's kinda odd to me that the current default shell in OS X is tcsh, but when you boot to single user mode you're in zsh. merv had a great idea for standardizing where bash lives for those of us who've gotten it through fink. fink puts bash here:

/sw/bin/bash

and merv suggested doing this

sudo ln -s /sw/bin/bash /bin/bash

so there's a symlink in /bin which is the standad repository for bash. That way we can write and use scripts for/from the rest of the bash using community without having to modify the #! /bin/bash to #! /sw/bin/bash at the beginning of a script. As to whether bash will be included in Jaguar, I'd love to see it, have a strong hunch that it will be, but we'll just have to wait and see.

[osxpez]

I see no reason to limit yourself to write your scripts using sh. sh is a really old shell and scripting capabilities has been greatly improved in later shells. Most notably ksh and it's followers. On many *nixes sh is in fact ksh. bash is, scriptwise, very compatible to ksh, making it an excellent choice for shell scripting. As I understand zsh too is very compatible to ksh. And I think that sh on OS X is zsh anyway (though I changed this on my box to be bash in order to get surfraw to work).

As for the original question. I think that if you are fluent in Perl you should seldom need shell scripting anyway. Perl is often better than shell scripts since you can do so much within the same process instead of having to start awk, grep, sed and what have you to perform things that are native in Perl. That said, I often find myself writing shell scripts even though I am pretty comfortable with Perl scripting. I'm just a thick headed shell script junkie. =)

[honestpuck]

Originally posted by JayBee
When scripting stuff for these forums, what do we reckon the benefits/drawbacks are of the various scripting languages out there? I agree that Bash (being fairly "standard" in most flavours of *nix out there) would probably be the ideal, but it's not part of OS X, so it's a bit of a non-starter as far as portability goes.

Being from a web background, I'm a big fan of Perl, and have written most of my custom scripts in it. However, I haven't really played much with sh or its ilk, and wonder what people's personal preferences are?

Personally I use nothing in my shell scripts that relies on any particular version of the shell.

As for shell vs perl it's a real non-contest these days. For extremely small stuff (like cron tasks or startup tasks) use the shell, everything else use Perl - I do have some relic shell scripts that use awk, sed etc. with such complexities as command files but not many of them. Perl is a marvellous tool for system hacking and has replaced C in my armoury as weapon of first choice.

On a further note I've almost totally given up Perl for web tasks in favour of PHP.

Tony

[osxpez]

Personally I use nothing in my shell scripts that relies on any particular version of the shell.

That boils down to about no script at all. csh and sh use very different scripting syntax. But, yes, Perl indeed is an excellent system scripting tool.

[vonleigh]

Hello,

While we're on the subject of bash, and seeing that it may be included in Jaguar, how hard would it be for a newby who just learned a bit of tcsh to make the transition? is it that different?

I am a bit happy since this would put me on par with my linux using friends, as i understand they use bash.


Vonleigh

[osxpez]

If it's using it as your interactive shell you shouldn't find it all that different. Bash has borrowed quite a few of it's interactive behaviours from tcsh. And learning to script bash should be quite easy as well if you know how to script tcsh. You should avoid using tcsh for scripting anyway.

[mervTormel]

...easy's getting harder every day...

bash command line completion is so gawd awful powerful, it's frighteningly approaching "type a char, hit tab and yer done"

[ but completion coding is complex at first, and even second. ]

here's some examples of completions:

$ help [tab] # help builtin
. bind compgen disown exit getopts
: break complete echo export hash ...

$ cd m[tab] # change dir completes on dirs
Mail/ Movies/ Music/ man/ mbsl@ mtsl@

$ ssh [tab] # hostnames !
130.94.219.148 192.168.1.51 192.168.1.54
192.168.1.50 192.168.1.52 204.152.186.48

$ which o[tab] # commands in path
od open openfiles openman openurl
onsgmls opendiff openjade openssl osacompile

$ v[tab] # commands in path
vacation vers_string vi vim vimtuto
vdir vgrind view vimdiff vipw

$ shopt [tab] # shell options
cdable_vars execfail hostcompl
cdspell expand_aliases huponexit ...

$ set [tab] # shell set options
allexport histexpand monitor
braceexpand history noclobber ...

$ chgrp [tab] # chgrp reads from group table
admin dialer kmem network
bin games mail new_directory ...

$ ls --[tab] # long options
--all --dired --ignore-backup
--almost-all --escape --ignore=
--block-size= --file-type --indicator-sty
--classify --format= --inode
--color --full-time --literal
--color= --help ...

$ decl[tab] -f sy[tab] # builtin ref used to complete the function

$ declare -f syslogger
syslogger ()
{
local pri=${1} tag=${2} msg=${3};
/usr/bin/logger -i -p "${pri}" -t "${tag}" "${msg}"
}

note that i colrm'd 60 120 and edited the output for brevity and so it would fit

[osxpez]

¿que?

[Titanium Man]

I thought command completion was easy in bash! I've been playing around with zsh. In bash if you hit tab it will show you all the possibilities. In zsh if you hit tab it will *cycle through* all the possibilities. This is good for me as I am so lazy I usually don't wear pants to work. Not only that, but with zsh you can have a "cd path" where you tell zsh where to look for a directory, and it'll take you there without you having to type the full path. Easier illustrated than explained:

cdpath=(~ ..) #excerpt from .zshrc

Now if I'm anywhere, I can type:

doc[tab]

and I'll be transported to ~/Documents. Or if I'm in ~/Documents, I can type mus[tab] and I'll be transported to ../Music. See? I'm still trying to figure out just what the heck I'm doing in bash (I can't believe the first time I launched Terminal was in January) but zsh looks pretty cool too. vonleigh, if you're new to the command line as I am, ANY shell you learn right now will be challenging/frustrating/fun, so I would take the practical approach. Learn something you can get help with, and something other people write scripts in, so you can study them and learn. Most scripts I've come accross are in sh, so bash was the way to go for me (bash is the more feature filled offspring of sh, while tcsh comes from csh). Hardly anybody scripts in csh anymore, so I got away from tcsh since I wanted to learn more about scripting. Have fun!

[honestpuck]

Originally posted by Titanium Man
Not only that, but with zsh you can have a "cd path" where you tell zsh where to look for a directory, and it'll take you there without you having to type the full path.
Both bash and tcsh also have a cd path. They both also have a directory stack, which I find equally useful since in a shell I usually spend my time moving between a small number of directories in each session.

Tony

[mervTormel]

Originally posted by osxpez
¿que?
osxpez, pesares. i see now that tcsh's command line completion has this feature, also. i forgot since i spent most time migrating from tcsh.

TiMan, executing command completion is easy in bash; programming it is another kettle of tacos altogether...

$ complete | grep grok
complete -F _command grok

$ declare -f _command
_command ()
{
local cur func cline cspec;
COMPREPLY=();
cur=${COMP_WORDS[COMP_CWORD]};
if [ $COMP_CWORD -eq 1 ]; then
COMPREPLY=( $( compgen -c -- $cur ) );
else
if complete -p ${COMP_WORDS[1]} >&/dev/null; then
cspec=$( complete -p ${COMP_WORDS[1]} );
if [ "${cspec#*-F }" != "$cspec" ]; then
COMP_CWORD=$(( $COMP_CWORD - 1 ));
func=${cspec#*-F };
func=${func%% *};
cline="${COMP_LINE#$1 }";
COMP_WORDS=( $cline );
$func $cline;
if [ "${cspec#*-o }" != "$cspec" ]; then
cspec=${cspec#*-o };
cspec=${cspec%% *};
if [[ "$cspec" != @(dir|file)names ]]; then
COMPREPLY=( "${COMPREPLY[@]//\\\\:/:}" );
fi;
fi;
else
if [ "${cspec#*-[abcdefgjkvu]}" != "$cspec" ]; then
func=$( echo $cspec | \
sed -e 's/^.*\(-[abcdefgjkvu]\).*$/\1/' );
COMPREPLY=( $( compgen $func -- $cur ) );
else
if [ "${cspec#*-A}" != "$cspec" ]; then
func=${cspec#*-A };
func=${func%% *};
COMPREPLY=( $( compgen -A $func -- $cur ) );
fi;
fi;
fi;
fi;
fi;
[ ${#COMPREPLY[@]} -eq 0 ] && _filedir
}

$ grok bz[tab]
bzcat bzdiff bzfgrep bzip2 bzless
bzcmp bzegrep bzgrep bzip2recover bzmore

$ grok bzgrep

bzgrep is /sw/bin/bzgrep : Bourne shell script text

seen in /sw/bin/bzgrep

-rwxr-xr-x 3 root admin 1582 Apr 15 13:37 /sw/bin/bzgrep

whatis : bzgrep(1), bzfgrep(1), bzegrep(1) - search
possibly bzip2 compressed files for a regular expression

notes:

grok - my personal command grok'er; a hack really, requires bash, get it here...

http://home.mindspring.com/~bduart/grok.gz

function _command - from a huge file of bash command completions found out there, somewhere

don't let the above discourage you from using bash as an interactive shell. a lot of the tough nuts have been cracked and you just 'plug into the matrix'.

back to the topic:

sh vs. perl - learn both, and use bash as a shell because it's a superset of sh. adding csh/tcsh in that mix will lead to complicating the mix with another set of interpolative machinations to go through to 'don the right helmet'.

i think knowing shell has to help in perl land, after all perl was begotten from shell "not having the stones". and sometimes you have to know shell.

[mervTormel]

sh and zsh are the same?...

$ ls -l /bin/sh /bin/zsh
-r-xr-xr-x 1 root wheel 449616 Dec 8 10:49 /bin/sh
-rwxr-xr-x 1 root wheel 449616 Dec 8 10:49 /bin/zsh

$ cmp /bin/sh /bin/zsh

$

¡no me gusta! can zsh be sh plus all the interactive features?! then, does vanilla sh have the interactive features? is this zeroing the scorecard?

[Titanium Man]

merv, what tha heck is that _command function? My brain hurts from looking at it. Thanks for sharing grok, it kicks booty! I'm not sure what's up with the included versions of zsh and sh. I noticed that the stock zsh is version 3.0.8, but there is a 4.0.4 version in the unstable fink distro. I've installed it and other than a minor mishap during compiling (conftest crashed) everything's ok so far. For those interested parties, the unstable zsh can be gotten by copying this item:

/sw/fink/dists/unstable/main/finkinfo/shells/zsh-4.0.4-1.info

to this folder:

/sw/fink/dists/stable/main/finkinfo/shells/

(Thanks for hipping me to that, sao) Now if I could just manage to wade through all the options you get with zsh. BTW, thanks for the heads up on cdpaths existing in tcsh and bash, honestpuck.

[Titanium Man]

P.S. merv is that function entered in your .bashrc? I got a syntax error when I pasted it into mine and opened a new window. Anyhoo, this is what I get regarding zsh (stock version) and sh:

ls -l /bin/zsh /bin/csh
-r-xr-xr-x 1 root wheel 318716 Apr 26 14:20 /bin/csh
-rwxr-xr-x 1 root wheel 449616 Apr 26 14:20 /bin/zsh


cmp /bin/zsh /bin/csh
/bin/zsh /bin/csh differ: char 114, line 1


I'm running 10.1.4

[mervTormel]

Originally posted by Titanium Man
merv, what tha heck is that _command function? My brain hurts from looking at it...
that _command () function is what interprets the completion for a command that you've said is to be completed with commands from the path, e.g. sudo...

$ complete -p | grep sudo
complete -o filenames -F _root_command sudo

$ sudo cv[tab]
cvs cvs-make-branch cvs-revert
cvs-diff-branch cvs-merge-branch cvs-view-diffs

i'll try and find the package and send it to you. _command() won't work without some other supporting completion functions and stuff.

regrets that you tried to wale it in and make it work. hope you dint rip a whole in the ozone.

i was trying to illustrate that bash's completion facility is broken down into subatomic particles that make fine tuning possible, if not very appealing.

anyhow, a large number of 'functions' exist (co-dependently) that assist in the implementation of bash completion functionality.

i haven't decided if the granularity of focus over the onerous programming is a plus or minus, yet.

in any system, given A, if A has two components, it's relatively easy. if A has more components that play together, the complexity grows geometrically, and we have, well, complexity. but also, power.

[osxpez]

mervTormel: I did mention in my first post in this thread that I thought sh was zsh on OS X. =) As for my ¿que¿ I neither hablo Español, nor mentioned that bash would be particularly easy to learn. I just pointed out that bash has many things in common with tcsh so the transition should not be hard. Thanks for waking us up on the marvels of command completion though. I had forgotten just how much you can customize it. Maybe this is the time to mention the sometimes excellent Dotfiles site? Here goes: Dotfiles shell section (http://dotfiles.com/index.php3?cat_id=6)