Re: [gccsdk] exec() possibly a problem

In message <a821639154.beeb@ron1954.woosh.co.nz>
Ron <beeb@woosh.co.nz> wrote:

> 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
> $

My useage here is in fact wrong, it appears that command and args are
wrapped in single quotes for a subshell. (Also done in a shellscript)
$ $PATH/sh -c 'printf "hello...\\n"'
hello...
$
all good
Simplifies things, now just the \\n being needed across the new process.

> 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.

It is now, they probably use single quotes to wrap them.

> 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.
>
Ron M. (redoing it a little)

_______________________________________________
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