Oh boy! Deja-vu... On 2003-02-28 18:32, [EMAIL PROTECTED] wrote: > This concerned how to load execve()'s argv[] array when parsing the > 'shebang' line of a script, ie: whether to pass everything after > '#!/interpeter' > > 1. as one string into execve()'s argv[] array, as some systems do, or > 2. as individual arguments, as exist after #!/interpreter, separated > by whitespace.
I don't like 2 and I will definitely suggest that it's *not* implementd for various reasons. See below. > Bug report 16383 showed the variance in the various UNIX's of how > this is done. I'm not sure if this is the right bug report. The (closed now) ports/16383 PR is about a broken port, that has been fixed. > Orginal SysV specs say to load '1 argument' only after > #!/interpreter, leaving it ambiguous as to whether the > '1 argument' is the 1st whitespace separated argument, > or whether it is everything after #!/interpreter as one > string. I don't mean to sound harsh here, but FreeBSD is BSD not SysV. We don't have to copy SysV 'bugs', and splitting blindly at whitespace is something I'll always consider a bug :( > Posix and SUSv3 don't say anything about how to load execve()'s > argv[] array after #!/interpreter, and seem to leave it to "whatever > is the most intelligent way". If they don't explicitly require a certain feature then it's not mandatory to implement it in any particular way. > I suggested it made more sense as FBSD 2.2.7 used to do it, > where execve()'s argv[] array was loaded contiguously with > whitespace separated elements, so one could use constructs > such as "#!/bin/sh /script-preprocessor options", and to > allow "#!/interpreter opt1 opt2" and "#!/interpreter opt1 arg1" > type constructs, things that intuitively work as one would > expect on a command line, since there didn't appear to be > any penalty for allowing this flexibility. > > A plausible argument was given in response: > > > #!/bin/sh "hello world" "foo bar" Thanks for 'plausible' :) > I repond as follows: that's something only a Windoze user would > think of doing! :) Unix users don't put whitespace in filenames, > nor would they create options to programs that contain whitespace. The only characters that are not allowed to be part of a filename are the path separator and ASCII nul '\0'. I don't like and I won't ever accept limitations other than that. Doing "special things" for any other character is one of the technical reasons why I don't use DOS and/or Windows. Why do you think that we have to do this in a way that is obviously broken for filenames that are perfectly valid? > Also, to load: > > '"hello world" "foo bar"' > > as one string, breaks it's purpose anyway. It still is a valid filename, and I might choose to write a shell script called "Find misfiled PRs.sh". How do you then propose that exec*() should handle filenames of that sort? > it is a bizarre example that has little practical value, and can be > easily compensated for by getting rid of whitespace in a filename, There are various reasons why splitting blindly on whitespace is a bug waiting in the background of programs to bite you in the future. For another known problem with this way of splitting parts of a command line look at http://www.freebsd.org/cgi/query-pr.cgi?pr=docs/35678. A very annoying 'feature' of make(1)... Do we really have to copy it to the way exec*() works? Also, think about Samba shares. One doesn't always have control of what something includes in the name. If I mount over Samba a Windows filesystem that contains some of my shell scripts why does it seem good to you to force limitations on me about the way I name my files? FreeBSD used to have a motto along the lines of "We provide the tools, and you make the policy". Implementing and mandating limitations of this sort is something that is far beyond the borders of "tools" and very deep within the heart of "policy". I don't like this... at all :( > in the bizarre case where it may exist as such. Finally, to be > slightly extreme with a tiny performance penalty, a beginning and > ending quote in a string could be check for and respected by > execve()'s code that fills argv[]. I'd have to see the code and several sample scripts to comment on this. - Giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
