On Tue, 13 Jun 2000, Christos Zoulas wrote:

# > I've changed NetBSD's exec_script.c to have the Solaris behavior and
# > am using it that way in our environment here.  But I'd like to get
# > comments on this before I commit the change to the master NetBSD
# > sources.
# 
# Now I suddenly cannot use an interpreter that has a space in its
# filename.

"Don't do that."

Spaces in filenames are fairly anomalous; catering to filenames with spaces
seems like a silly thing compared to passing in at least the first arg.

# What should the kernel do next? Start parsing backslash
# and quotes?

I think you're starting to overreact, here...

# Then hmm, maybe #!/bin/sh -c echo *.c should be expanded
# by the kernel too.

Anyone who is trying to do that deserves what they get.

# Well, I do agree that it is a cute hack that
# works in the perl case, but given that the user has control over
# the perl script and can turn -w himself on, why change things?

What if there are programs in which the user does NOT have control to
alter options?

# Plus if it only works on Solaris, then we should be following the
# general trend, not Solaris.

This from the guy who created the Zoularis package?

Did someone walk into your office and use your console while you were
out?

define(sarcasm,1)

Hell, we seem to be wanting to adopt other Solarisms (/usr/xpg4, different
binaries for echo and ps to be "POSIX-compliant"...[rant deleted after
much deliberation]), so why not go all the way?

undef(sarcasm)

I always understood
#! /some/exec -flags other-args

to effectively set argv to ("/some/exec", "-flags", 0); i.e.,
anything after argv[1] was discarded.  Spaces in an exec string?  Please.
I mean, sure, it could happen, but if you need that, then maybe you should
consider

#! /bin/sh -

"/some/path to an exec with spaces" -FLAGS other_args << 'EOF'
...
EOF

# christos


				--*greywolf;
--
BSD: Stop, Drop, and Load