Kay-Uwe Kasemir wrote:
> The real problem is that a 'shell script'
> does not only need a UNIX-style shell
> but usually requires more tools like
> ls, cp, rm, mkdir, awk, grep, date, find, sed, ...
>
> Solution A: Implement all these tools on every system.
> ---------------------------------------------------------
> This is what we do right now:
> - I use some free tools that compile with
> Visual C++, the 'native' compiler for Windows.
> - Other approaches may use gnuwin32 which makes
> WIN32 look like Unix and will probably work some day.
> The question is: Do we want a portable EPICS
> or does everything have to look like UNIX?
> And there will always be scripts that won't
> work on WIN32 or VMS or ...
cygnus, if they do not already have it working, have a version of bash
that supports the bourne shell as a subset. It is my impression that all
the standard unix commands specified above are also supported. Since the
cygnus support is available free via the net it seems a shame to give up
on this support. There is a book
Portable Shell Programming
Bruce Blinn
Prentice Hall
1996
that gives good advice about how to develop portable shell scripts.
> Solution B: Use no script but only ANSI C programs.
> ---------------------------------------------------------
> This would work but many one-line-scripts
> are hard to implement in C, so everybody who
> likes to get his/her job done in time will
> fall back on shell scripts.
This also relys on compatible library calls (system calls, etc.) My
guess is that this approach may still have problems with non conforming
systems. The only hope would be POSIX calls. Can we safely assiume that
every system properly supports POSIX? Does POSIX.1 provide everything we
need? Also for many tasks c is not as nice as shell scripts. We will
also have a bootstrapping problem, i.e. cant build until the "C" script
programs are buildt. How are they built?
> Solution C: Replace all the tools mentioned above by perl.
> ---------------------------------------------------------
> I am not sure if the Perl book is right when
> it claims that Perl will save the world,
> but:
Is perl really replacing everything? I dont think so. I think it is
really just replacing the shell. I think it relys on the underlying
system for things like mkdir, etc. Granted commands like grep may not be
necessary bit all system type calls rely on underlying support.
Have you tried using gmake with SHELL set to perl? Does everything work
nicely? This includes all make rules and the $(shell ...) builtin
function. Is there a performance hit?
This sounds like a major change. We should not do it lightly.
Marty Kraimer
- References:
- Make, Scripts, Shell, Perl!? Kay-Uwe Kasemir
- Navigate by Date:
- Prev:
Re: Make, Scripts, Shell, Perl!? Jeff Hill
- Next:
XYCOM 566 Help Alicia Hofler
- Index:
1994
1995
1996
<1997>
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: Make, Scripts, Shell, Perl!? Jeff Hill
- Next:
Re: Make, Scripts, Shell, Perl!? Chris Timossi
- Index:
1994
1995
1996
<1997>
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|