/usr/bin/tclsh84

[Jonathan Larmour <jifl at eCosCentric dot com>]

Ah another day another tclsh.

Unfortunately there are those of us who like having scripts that are 
portable between OS's :-). On Linux at least, tclsh is installed as 
/usr/bin/tclsh with no version number suffix. Cygwin used tclsh83 and 
tclsh84 and will no doubt use tclsh85 when it comes out.

Why can't we just have a nice standard /usr/bin/tclsh that scripts can 
easily reference like other UNIX environments? Even if it's only a soft 
link to the most recently installed tclshNN (like RPM post-install scripts 
do for the linux kernel etc.). I know cygwin has got post-install scripts, 
so any reason not to?

Out of interest, this is the magic we've so far used to cope with name and 
path differences on cygwin, and we'd like it not to keep getting out of 
date. Or indeed our documentation - eCos users use cygwin because the 
tools require it, not because they want to understand the intricacies of 
finding the correct tcl version having never touched bash/cygwin before :-).

#!/bin/bash
# restart using a Tcl shell \
    exec sh -c 'for tclshell in tclsh tclsh83 cygtclsh80 ; do \
            ( echo | $tclshell ) 2> /dev/null && \
  exec $tclshell "`( cygpath -w \"$0\" ) 2> /dev/null || \
  echo $0`" "$@" ; \
        done ; \
        echo "Cannot find Tcl shell" ; exit 1' "$0" "$@"

The convolutions are to deal with spaces in path names, and this was 
recently fixed to cope with tclsh83 not liking cygwin style paths as $0, a 
regression from cygtclsh80 out of interest.

Jifl
--
eCosCentric       http://www.eCosCentric.com/       <info@eCosCentric.com>
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/