opinions on shell scripting on windows
Jean-Luc Fontaine
shell script is launched through exec'ing sh) and I was wondering if
such a functionality is easily portable on windows platforms.
I know about command.com and .bat files, but I would very much like to
hear about your experiences and the issues involved.
My goal is to make the moodss threshold scripts functionality
(http://jfontain.free.fr/moodss.htm#menus.edit.thresholds.script) work
transparently on windows.
Many thanks in advance,
--
Jean-Luc Fontaine mailto:jfon...@free.fr http://jfontain.free.fr/
Stéphane Padovani
Why not using cygwin ?
You only need to distribute the bash.exe, cygwin.dll, and the commands
you use in your shell scripts ( cat.exe, ls.exe, ...), with your
program.
I did this several times, the advantage is that you use the same shell
code for Unix, and windows. That means less work for you, and more time
for the rest.
Stephane,
Jean-Luc Fontaine a écrit :
Iain B. Findleton
I have shell scripting working from Tcl very nicely on UNIX platforms (a
shell script is launched through exec'ing sh) and I was wondering if
such a functionality is easily portable on windows platforms.I know about command.com and .bat files, but I would very much like to
hear about your experiences and the issues involved.
What i did was the following:
- I wrote a cron look-alike for Windows that looks at the clock, checks a file that looks similar to a crontab file to find an event match, and then uses the Windows API to create a task that runs a command line in a hidden window.
- The command line is a .BAT file that invokes tclsh to process a script. Typically these scripts will access a web page that contains weather data, extract the weather data from the HTML, format it, and using Dynamic Data Exchange (DDE) sends the formatted data to an application that does something with the data. My applictions do things like database the data, do image processing, and do display of the data.
I can say that I have never investigated a crash or hang that could be traced back to tclsh itself, although I presume, since there are bugfix releases for Tcl, that it is possible to encounter such an event. When I say "tclsh" here, I mean tclsh80, tclsh81, tclsh82 and tclsh83.
By way of comparison, I have had Linux based data acquisition jobs doing the same type of thing running 24/7 since about the same time, and I have never seen a crash or hang of the Linux box. My conclusions are, therefore, the following:
- Tcl under Windows is, itself, highly robust
- A major issue with the Windows O/Ss that I used is the clock appears to loose time as a function of load. After several weeks my clocks are slow by a large enough time to misalign events to the extent that the application is no longer performing as desired.
- For dedicated, single application style use, cron style script processing under Windows is feasible and demonstrates what I would think of a typical Windows environment levels of reliability.
- On a box that has other things going on while the background processing is underway, such as running Office or surfing the Web, the concept of HA (High Availablility) is problematic, to say the least.
- If your script does heavy computations, then when it gets launched it can grind other things to a halt. One of my scripts, for instance, manipulates satellite images by cropping them and moving labels about and remapping colors. If I am working on a Word document when this happens, the mouse won't move, the clock won't tick and buttons won't push. Oddly enough, the same behaviour is manifest on a P-I/90, P-III/233 and P-IV/2Ghz. Availability of CPU does not appear to be the underlying factor. By contrast, the same script running on a Linux machine using a 486/66 shows no such behaviour.
- It appears that just about every Windows O/S has different DLLs, different "standard" file layouts, and different levels of implementation of API features. In the case of DDE for example, W95, W98 and NT4 all have different implementations of DDE API calls, even although the documentation makes no specific mention of this rather innovative approach to software standardization. To me this meant that a lot of testing of any extensions is needed before they can be included in a distribution.
- If your mortgage payments are dependant on this activity, strongly consider the use of Linux/UNIX instead.
I have done a lot of Windows development, particularly with Tcl/Tk
extensions. There is no doubt that that environment has some distinct benefits,
especially where graphics animation and file system performance over a
network are concerned.
About a year ago I moved to a cross-platform GUI development environment for my extensions, which was originally intended to save me time and effort for extension porting and maintenance. I have since, however, concluded that the Linux environment is so much more stable that its a waste of time bothering with Windows, so I have just installed RH 7.2 on top of W95/W98/WME and NT. I have not seen a Blue Screen of Death since. I have not even seen a hang or a crash since!
-- Iain B. Findleton http://pages.infinit.net/cclients (514)457-0744 The motto "Honi soit qui mal y pense" is found frequently on devices of death and distruction! The motto "E pluribus unum" is found on an item that strongly distinguishes those that have it from those who don't!
Anton Kovalenko
Hello, Jean-Luc!
In my opinion, generally, using "shell scripting" on windows is asking
for trouble.
Scripting facilities of command.com are very weak. There is nothing
we can do with command.com that's hard to do in tcl itself.
Cmd.exe (on Windows NT) is another thing. It's much more flexible than
command.com (but beyond compare with normal UNIX shells), and it's
32-bit application. And we can expect that some experienced users of
Windows NT will find CMD.EXE-scripting functionality very useful.
At home, I use the cygwin environment (when I use Windows). It seems to
be a good idea for moodss to use cygwin shell when it's available on
user's machine. So it will be able to execute unix-oriented shell scripts
not only on unix, but also on Windows with installed cygwin.
> Many thanks in advance,
--
Good luck!
Anton Kovalenko.
Jean-Luc Fontaine
> Hi,
> Why not using cygwin ?
> You only need to distribute the bash.exe, cygwin.dll, and the commands
> you use in your shell scripts ( cat.exe, ls.exe, ...), with your
> program.
> I did this several times, the advantage is that you use the same shell
> code for Unix, and windows. That means less work for you, and more time
> for the rest.
> Stephane,
Thank you for the idea.
Unfortunately, I cannot expect Windows users to install such tools, but
rather use what they know...
I will include it in the FAQ though.
Thanks again.
Jean-Luc
stephane Padovani
You don't need to ask to the users to install cygwin.
By example, I have to distribute a Tk/Tcl prog using some bash scripts,
and the cat, ls and find commands.
In the MyTclProgDistrib/bin directory of my distribution, I put bash.exe,
cat.exe, ls.exe, find.exe and cygwin1.dll. You don't need more and
the user doesn't need to know that the program uses bash scripts and cygwin.
Stéphane,
Your name
Just like to say that contrary to some others, I think bash.exe from cygwin
sucks. Its dogslow on my 600 mhz athlon, running Win98 (NOT second édition)
mmm, sorry, not many good ideas, only negativity.
SLAP me!
jooky