Mail Archives: djgpp-workers/2000/08/19/19:28:39
Hello.
I've encountered a problem while using the DJGPP port of bash 2.03. The
DJGPP porter of bash, Mark E., said that he think the script that I'm
trying to execute is actually wrong.
Here is a snippet of the code that fails:
bash-2.03$ pwd
d:/develop/ports/gnu.dev/filutl-4.0x/lib
bash-2.03$ make
source='getdate.c' object='getdate.o' libtool=no \
depfile='.deps/getdate.Po' tmpdepfile='.deps/getdate.TPo' \
depmode=gcc /bin/sh.exe ../depcomp \
gcc -DLIBDIR=\"/dev/env/DJDIR/lib\" -DHAVE_CONFIG_H -I.. -I. -I../intl
-g -O2
-c -o getdate.o `test -f getdate.c || echo './'`getdate.c
depcomp: Variables source, object and depmode must be set
make.exe: *** [getdate.o] Error 1
[gcc args line has wrapped.]
All the paths, programs, etc. that are required exist. The problem appears
to be that the backticks in the depcomp command-line stop the environment
being set up for depcomp (source, libtool, depfile, depmode do not get
set).
I duplicated this problem with a simpler test case. Below is a mail that I
sent to the DJGPP workers list describing the problem.
My question is: is the syntax used in the depcomp command-line valid? Is
it valid to use backtick substitution and set up the environment?
Incidentally, the $() form of command substituion doesn't seem to work
either in the DJGPP port.
[START mail to djgpp-workers]
I tried to build fileutils 4.0x at the weekend, but I hit a problem with
depcomp. With some help from Prashant and Eli the problem was narrowed
down to bash 2.03 (thanks guys!). This is actually a problem earlier
encountered in the djgpp-workers thread "Porting problems with Sh-utils
(beta)" - the first mail is dated Sat, 8 Apr 2000 18:49:49 +0500 on my
system.
Here is the problem: when passing parameters to a command using
backticks, the supplied environment is ignored. E.g.
a=foo ./someprog `echo hello`
will not pass $a to 'someprog'.
Here's a simple test program:
[BEGIN echo-a]
echo Args: $*
echo $a
[END echo-a]
Here's an example session showing the problem:
[START results.txt]
bash203-2.03$ ls -al
total 5
drwxr-xr-x 2 rich root 64 Aug 14 20:59 ./
drwxr-xr-x 37 rich root 2400 Mar 19 13:29 ../
-rw-r--r-- 1 rich root 24 Aug 14 21:00 echo-a
bash203-2.03$ test -f echo-a; echo $?
0
bash203-2.03$ a=foo ./echo-a
Args:
foo
bash203-2.03$ a=foo ./echo-a `test -f echo-a`
Args:
bash203-2.03$ a=foo ./echo-a `test -f ./echo-a`
Args:
bash203-2.03$ a=foo /bin/bash203.exe echo-a `test -f ./echo-a`
Args:
bash203-2.03$ a=foo /bin/bash203.exe echo-a
Args:
foo
[END results.txt]
Please note that my bash 2.03 was installed in /bin, because I have beta
5c of bash 2.04 installed. The second set of invocations is to show that
bash 2.03 is actually being using when doing './echo-a'.
Thankfully this problem does not exist in bash 2.04 beta 5c. Are there
any plans to fix this problem in bash 2.03?
[END mail to djgpp-workers]
TIA, bye,
--
Richard Dawe
[ mailto:richdawe AT bigfoot DOT com | http://www.bigfoot.com/~richdawe/ ]
- Raw text -