Re: [gccsdk] exec() possibly a problem
Hi Ron, 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) No, that's too simplistic. Unix shells like dash follow http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html in their processing of the backslash escape, and single and double quotes. $ $PATH/sh -c 'printf hello...\\n' hello... $ all good Simplifies things, now just the \\n being needed across the new process. I've only skimmed this thread to date, but be aware that there are three processes parsing that command above. The dash shell that's printed the `$ ' prompt. The sh you explicitly start. And the printf that's either a built-in to the shell or a separate executable that's processing the argv[] its main has been passed. All three of them are happy to interpret a backslash-escape in some circumstances. As an example, double quotes, which allow more interpolating, aren't necessary above. Another layer of single quotes can be used, with them mechanically being escaped, e.g. $ sh -c 'printf '\''hello...\n'\' hello... $ Cheers, Ralph. ___ 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
[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
Re: [gccsdk] exec() possibly a problem
In message a821639154.b...@ron1954.woosh.co.nz Ron b...@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
