shell scripts in DJGPP
Sherlock Campbell
problem.
I have a c program that I need to compile and run on a Win98 desktop.
It is a fairly complex program with several makefiles and lots of
executables. I set it up and compiled it successfully on a Solaris Unix
system. So far, I have been able to compile it using DJGPP but I cannot
get the shell scripts to run. They all begin with '#!/bin/sh' and
bash.exe and sh.exe are in my PATH statements. If I run 'sh', then the
scripts are available, but from my regular DOS prompt it reads 'bad
command or file name' when I try to run the scripts.
Damian Yerrick
<scam...@mail.utexas.edu> wrote:
>I am new to DJGPP (and Unix, for that matter) and have run
>into a problem. I have a c program that I need to compile
>and run on a Win98 desktop. It is a fairly complex program
>with several makefiles and lots of executables. I set it up
>and compiled it successfully on a Solaris Unix system.
Does it also work on a GNU system (i.e. Linux)?
>So far, I have been able to compile it using DJGPP but I
>cannot get the shell scripts to run. They all begin with
>'#!/bin/sh' and bash.exe and sh.exe are in my PATH statements.
>If I run 'sh', then the scripts are available, but from my
>regular DOS prompt it reads 'bad command or file name' when
>I try to run the scripts.
Command is a crappy shell.
It doesn't even understand #!/ headers or even # comments.
Try typing the word bash before the script's filename.
Or try this:
===== begin config.bat =====
@echo off
bash configure
===== end config.bat =====
--
Damian Yerrick http://yerricde.tripod.com/
Comment on story ideas: http://home1.gte.net/frodo/quickjot.html
AOL is sucks! Find out why: http://anti-aol.org/faqs/aas/
View full sig: http://www.rose-hulman.edu/~yerricde/sig.html
Eli Zaretskii
On Mon, 7 Feb 2000, Sherlock Campbell wrote:
> So far, I have been able to compile it using DJGPP but I cannot
> get the shell scripts to run. They all begin with '#!/bin/sh' and
> bash.exe and sh.exe are in my PATH statements. If I run 'sh', then the
> scripts are available, but from my regular DOS prompt it reads 'bad
> command or file name' when I try to run the scripts.
COMMAND.COM cannot run shell scripts. You need to run them like this:
sh script
or
sh ./script
Then it will work. You could also create a batch file for each
script FOO, called FOO.bat, which would say this:
@echo off
sh %0
However, there's a caveat: you cannot redirect standard streams of a
batch file, so if you go this way, you lose the ability to redirect
the script's I/O, which might be important for some scripts.
Note that you don't need all this tyrickery when the script is run by
a DJGPP program, like by Make reading the Makefile, because the DJGPP
library knows about shell scripts and will automatically invoke the
shell, as if you prepended "sh". But COMMAND.COM is not a DJGPP
program...
Hans-Bernhard Broeker
> I am new to DJGPP (and Unix, for that matter) and have run into a
> problem.
> I have a c program that I need to compile and run on a Win98 desktop.
> It is a fairly complex program with several makefiles and lots of
> executables. I set it up and compiled it successfully on a Solaris Unix
> get the shell scripts to run. They all begin with '#!/bin/sh' and
> bash.exe and sh.exe are in my PATH statements. If I run 'sh', then the
> scripts are available, but from my regular DOS prompt it reads 'bad
> command or file name' when I try to run the scripts.
Exactly. 'command.com' and/or DOS know nothing about the #! method of
specifying that a given file is a script for some specified utility.
So you cannot expect shell scripts to be directly executable, from
command.com.
Remedies:
1) Use 'bash' as your shell (at least for the time of working with that
package the shell scripts belong to)
2) Start them with an explicit call of 'sh', like
sh /path/to/script arguments...
or, if they're on the PATH:
sh -c script arguments...
--
Hans-Bernhard Broeker (bro...@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Hans-Bernhard Broeker
[...]
> You could also create a batch file for each
> script FOO, called FOO.bat, which would say this:
> @echo off
> sh %0
> However, there's a caveat: you cannot redirect standard streams of a
> batch file, so if you go this way, you lose the ability to redirect
> the script's I/O, which might be important for some scripts.
If you want, there's a remedy for that, as well: *Compile* the batch
files to .com files, using PC Magazines 'Bat2exec'. Remarkably enough,
those compiled batch files do support redirection, unlike the
originals.
I used it, a *long* while ago, to set up a whole legion of such
compiled batches for the DJGPP port of NETPBM. Worked like a charm,
once I got it set up.
Eli Zaretskii
On 8 Feb 2000, Hans-Bernhard Broeker wrote:
> > However, there's a caveat: you cannot redirect standard streams of a
> > batch file, so if you go this way, you lose the ability to redirect
> > the script's I/O, which might be important for some scripts.
>
> If you want, there's a remedy for that, as well: *Compile* the batch
> files to .com files, using PC Magazines 'Bat2exec'.
It strikes me that it would be much simpler to use `redir', like this:
redir script
or
redir -o file script
(`redir', being a DJGPP program, will know how to invoke a shell
script.)
> Remarkably enough, those compiled batch files do support
> redirection, unlike the originals.
That's not surprising: the problems with redirection from a batch file
are a misfeature of COMMAND.COM, caused by the fact that it doesn't
spawn another copy of itself to run the batch. Compiled batch files,
OTOH, are normal .com programs, so redirection works as usual.
Richard Slobod
Eli Zaretskii <el...@is.elta.co.il> wrote:
> That's not surprising: the problems with redirection from a batch file
> are a misfeature of COMMAND.COM, caused by the fact that it doesn't
> spawn another copy of itself to run the batch.
If COMMAND.COM spawned a new shell to run batch files, it would (1)
waste precious conventional memory (and note that batch files are often
used to launch application programs which might need that memory), (2)
make it impossible to permanently set environment variables from a batch
file, and (3) make it unsafe to start TSR programs from a batch file.
For that matter, this behavior doesn't really prevent I/O redirection
with batch files; it just complicates implementing it a bit and
Microsoft didn't bother to go to the trouble. Note that 4DOS works the
same way and it manages redirection with batch files just fine.
Sent via Deja.com http://www.deja.com/
Before you buy.