scripting environments (was: /bin/date and coreutils)

[Elias Pipping]

On May 11, 2007, at 9:13 AM, Vincent Lefevre wrote:

> On 2007-05-11 00:27:54 +0200, Jochen Küpper wrote:
>> On 10.05.2007, at 23:56, Vincent Lefevre wrote:
>>> And Python isn't installed everywhere.
>>
>> Well, that's not my experience. It's even on all number crunchers  
>> and big
>> iron machines I have used over the last years, as scheduling/batch  
>> systems
>> also use it;)
>
> Well, I have an access to a Solaris machine, where perl is installed
> but not python.
>
>>> The system version is used, and this is not necessarily a problem,
>>> except if some modules only present in MacPorts are used.
>>
>> That's the real point - you are in principle back to the same point
>> as with shell scripts - unless you use only the basic stuff.
>
> No, with Perl, one can do very much without using modules (even much
> more than shell scripts and the standard utilities), and many modules
> are provided in standard, so that using the system version would not
> be a problem in practice.
>
>> If you do that in a shell-script (using only basic stuff), you are
>> as safe, because /bin/bash and /bin/tcsh are "always" there...
>
> They are always there under Mac OS X. But some Unix platforms do not
> necessarily have a /bin/bash (e.g. Solaris). And I don't think this
> is the case of tcsh either (/bin/csh is probably much more common,
> but anyway http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/).
> /bin/sh is always there, but this is not always a POSIX sh (e.g. it
> isn't under Solaris).

any reason not to use '/usr/bin/env bash'?

regards,

elias