Re: Mass bugfiling potential: 'rules' with space
Matthew Garrett wrote:
In chiark.mail.debian.devel, you wrote:
No, NetBSD passes a single argument. It's just that it passes "-f "
rather than "-f", and make treats these differently. Your "bar baz"
example will behave in the same way on NetBSD. Now, can anyone find a
reference that suggests that NetBSD is wrong to do this? If not, I'm not
happy about trying to get NetBSD upstream to accept the change.
Hmm. Two things to do here:
1. Check Posix and SUSv2. It would be interesting to see what, if
anything, they say about this.
2. Survey a handful of other Unices. I'd suggest checking OpenBSD,
Solaris, AIX, HPUX, etc. as many as can be arranged. (I know there are
people on this list with access to some of these systems.) It would be
useful to know if Linux or NetBSD behaviour is common. And helpful in
determining the right thing to do about it.
It'd be nice to able to say: Everything but NetBSD does it this way,
rather than, this problem breaks some files from Linux.
Just to make it absolutely clear - "#!/usr/bin/make -f " on NetBSD
results in "make" "-f ", *not* "make" "-f" "". I'm inclined to think
that the rules files in question are buggy, and it's just luck that they
happen to run on Linux. Oddly, this does seem to be a deliberate
decision - from fs/binfmt_script.c in the Linux source, we have:
if ((*cp == ' ') || (*cp == '\t'))
*cp = '\0';
Ted, was there any particular reason for this?
Something interesting: I checked FreeBSD, and it's behaviour is
different from both Linux and NetBSD, although probably more like Linux.
It drops the trailing blanks, and appears to split on whitespace. If I put:
#!/tmp/test-argv -f foo bar
I get:
/tmp$ ./t.sh
argv[0]:/tmp/test-argv,argv[1]:-f,argv[2]:foo,argv[3]:bar;
(Source for test-argv below.)
So FreeBSD behaves differently in the other case, but handles make "-f "
just fine. 8-)
---Nathan
test-argv.c:
#include <stdio.h>
void main(char argc, char *argv[])
{
printf("argv[0]:%s,argv[1]:%s,argv[2]:%s,argv[3]:%s;\n",argv[0],argv[1],argv[2],argv[3]);
}
Reply to: