> > So my guess is that you don't run GNU sed. I don't know too well what
> > to do wrt this issue.
>
> Every DOS utility I have is GNU, including sed.
Ahh, I found the problem, but I don't as yet have a solution:
bash-2.04$ echo "one too three four" | sed "s|\btoo\b|two"
one too three four
b
> So my guess is that you don't run GNU sed. I don't know too well what
> to do wrt this issue.
Every DOS utility I have is GNU, including sed.
> Have autoupdate use Perl?
Sorry, I don't understand the question.
| c:/djgpp/tmp/au7944/input.m4:44: c:/djgpp/bin/m4.exe: Cannot open
| [c:/djgpp/tmp/au7944/m4.m4]: No such file or directory (ENOENT)
| c:/djgpp/tmp/au7944/input.m4:44: c:/djgpp/bin/m4.exe: Cannot open [../libm4.m4]: No
| such file or directory (ENOENT)
|
| and a preserved input.m4:
|
| diver
| c:/djgpp/tmp/au7944/input.m4:44: c:/djgpp/bin/m4.exe: Cannot open
| [c:/djgpp/tmp/au7944/m4.m4]: No such file or directory (ENOENT)
| c:/djgpp/tmp/au7944/input.m4:44: c:/djgpp/bin/m4.exe: Cannot open [../libm4.m4]: No
| such file or directory (ENOENT)
|
| and a preserved input.m4:
|
| diver
> I don't get it at all. Why would you have such problems, and I
> don't???
>
> Can you send one of these input.m4 files? Thanks!
>
The first error messages from debug-98.sh are this:
../autoupdate -d -v -m $top_srcdir -
| > I don't get it at all. Why would you have such problems, and I
| > don't???
|
| The problem went away after the latest cvs update. I still get one failure,
| but I see nothing as of yet that would classify it as DOS-specific.
Good to know.
| =
| ./debug-9
> I don't get it at all. Why would you have such problems, and I
> don't???
The problem went away after the latest cvs update. I still get one failure,
but I see nothing as of yet that would classify it as DOS-specific.
=
./debug-98.sh: Testing autoupdate
=
| > + ../autoupdate -m .. -
| > c:/djgpp/tmp/au16317/input.m4:44: c:/djgpp/bin/m4.exe: Cannot open
| > [c:/djgpp/tmp/au16317/m4.m4]: No such file or directory (ENOENT)
| > c:/djgpp/tmp/au16317/input.m4:44: c:/djgpp/bin/m4.exe: Cannot open
|
| After playing with generated temporary files, it se
> + ../autoupdate -m .. -
> c:/djgpp/tmp/au16317/input.m4:44: c:/djgpp/bin/m4.exe: Cannot open
> [c:/djgpp/tmp/au16317/m4.m4]: No such file or directory (ENOENT)
> c:/djgpp/tmp/au16317/input.m4:44: c:/djgpp/bin/m4.exe: Cannot open
After playing with generated temporary files, it seems like a pr
> IIUC, everything is fine, isn't it?
Relative fine anyway. Any other folks can hack their shell port to let 'test -
f prog' return true for 'test -f prog.exe' (assuming test is builtin in to
the shell they port).
> Puke puke puke! Bloody colons in file names :( I'm surprised that
> the `autoc
| A unified solution is certainly desirable. But perhaps we should find
| out how urgent a solution to this problem is before you decide to take
| on this problem for the next release. DJGPP's Bash has a solution
| (TEST_FINDS_EXE as mentioned), Cygwin (I've been told) has a similiar
| solution,
--- "Mark E." <[EMAIL PROTECTED]> wrote:
> > other similiar environment . My preference would be to test for programs
> > using 'prog_to_find${ac_exeext}'. Then somehow figure out when ${ac_exeext}
>
> > needs to be set without resorting to compiling a program.
>
> or at least allow it be set
--- Akim Demaille <[EMAIL PROTECTED]> wrote:
-8<-
> But after all, maybe just basing our decisions on uname is enough.
> Yes, this is against the philosophy of Autoconf, but it's better than
> nothing. And I guess we don't have to fear portability problems with
> uname, since I suppose the enviro
> OK, so we must start working on this.
A unified solution is certainly desirable. But perhaps we should find out how
urgent a solution to this problem is before you decide to take on this
problem for the next release. DJGPP's Bash has a solution (TEST_FINDS_EXE as
mentioned), Cygwin (I've bee
> "Mark" == Mark E <[EMAIL PROTECTED]> writes:
>> | TEST_FINDS_EXE=Y
>>
>> Wow, are you telling us we no longer need to dive into `test $ac_x'
>> and things like this?
Mark> It's a solution designed so we don't have to modify configure
Mark> scripts, but it's a hack. And it's a DJGPP-only
>
> | TEST_FINDS_EXE=Y
>
> Wow, are you telling us we no longer need to dive into `test $ac_x'
> and things like this?
It's a solution designed so we don't have to modify configure scripts, but
it's a hack. And it's a DJGPP-only solution, so it doesn't help EMX or any
other similiar environme
> other similiar environment . My preference would be to test for programs
> using 'prog_to_find${ac_exeext}'. Then somehow figure out when ${ac_exeext}
> needs to be set without resorting to compiling a program.
or at least allow it be set in config.site until a test can be divined.
| > Could you give more details on these steps? What can be done to have
| > it right without tuning by hand?
|
| What I set is:
| PATH_SEPARATOR=:
| TEST_FINDS_EXE=Y
Wow, are you telling us we no longer need to dive into `test $ac_x'
and things like this?
| CC=gcc
That's a known problem of
> | After setting some environment variables (CC, etc.) and correcting a DJGPP
> | specific bug in Bash 2.04, the test went well with one minor and one major
> | exception.
>
> Could you give more details on these steps? What can be done to have
> it right without tuning by hand?
What I set i
| Seeing as how Akim wants DJGPP to pass the testsuite, I figure it would be a
| good idea report my initial results using DJGPP and Autoconf from CVS.
Thanks a lot!
| After setting some environment variables (CC, etc.) and correcting a DJGPP
| specific bug in Bash 2.04, the test went well wi
Seeing as how Akim wants DJGPP to pass the testsuite, I figure it would be a
good idea report my initial results using DJGPP and Autoconf from CVS.
After setting some environment variables (CC, etc.) and correcting a DJGPP
specific bug in Bash 2.04, the test went well with one minor and one maj
21 matches
Mail list logo
