[gccsdk] exec() possibly a problem

Following on from the issues with make, I am trying to work out why we
have the problem with \n requiring \\n sometimes.

Using dash interactively in a taskwindow:
$ printf "hello...\n"
hello... $
no problem, there is no fork for an inbuilt command.
But when using dash as the shell for make and it does need \\n

Calling a dash shell this way seems to be bad from an interactive dash
shell also.
$ $PATH/sh -c printf "hello...\n"
hello...n: 1: printf: usage: printf format [arg ...]
Hangup
$
There are two things pointing at exec()s being wrong here, $PATH should
not be needed and the more obvious difference from the subshell fork
that is effecting the \n
\\n will output hello...\n -still not right in this situation.
It is sufficient from within a makefile, not so clear why.


The coreutils printf binary requires \\n to work interactivly, and then
it will also work from make with \\n.
Redirecting it's output to a file and there is no change, so I dont
think it is termios io interfering (I suggested this earlier)
Perhaps it is a simpler source to experiment with.

A big thanks to Duncan for nailing the make bug, at least the water is
less murky, though I have looked at exec()'s before and havn't found a
thing.

I cross-compiled the bsd bmake and found that it behaves the same way as
make with the //n

bmake is dependant on a shell, good news, it is working with dash OK.
In fact, after configuring, the compiling process is handled by a shell
script, and it built OK with dash on RISC OS also.

I have to use $PATH/binary at the moment though.

I don't have any previous experience with bmake, and how much it differs
from gnu make.
Most source comes for gnu make, the obvious issue with
using alternatives.

Ron M.



_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK