On Wed, Nov 29, 2000 at 02:11:00PM +0900, Daniel C. Sobral wrote:
Ugh. Evil stuff. Are environment variables starting with digits allowed
in sh(1)?
Nope:
$ 3FOO=yes
3FOO=yes: not found
$ export 3FOO=yes
export: 3FOO: bad variable name
To Unsubscribe: send mail to [EMAIL
The standard way of loading a particular module at boot from
/boot/loader.conf is 'modulename_load="YES"', right? This
doesn't seem to be possible with the 3dfx module, however...
Since it's name starts with a number, it causes a syntax error.
Being FORTH-impaired, I have no idea how to work
"Donald J . Maddox" wrote:
Also, it doesn't seem to be possible to compile 'device tdfx'
statically into the kernel either, since it depends on symbols
that only exist in the kernel when compat_linux is defined, and
COMPAT_LINUX is no longer an option, is it?
COMPAT_LINUX is still
I actually thought that COMPAT_LINUX had been completely removed, just
causing opt_dontuse.h to be generated. I see now that it doesn't
even warn about this being a deprecated option. *Is* it still
considered a deprecated option? I'm sure config used to warn about
COMPAT_LINUX being deprecated
"Donald J . Maddox" wrote:
I actually thought that COMPAT_LINUX had been completely removed, just
causing opt_dontuse.h to be generated. I see now that it doesn't
even warn about this being a deprecated option. *Is* it still
considered a deprecated option? I'm sure config used to warn
"Donald J . Maddox" wrote:
The standard way of loading a particular module at boot from
/boot/loader.conf is 'modulename_load="YES"', right? This
doesn't seem to be possible with the 3dfx module, however...
Since it's name starts with a number, it causes a syntax error.
Ugh. Evil stuff.
Thanks! This works great. I remember reading the stuff at the
bottom of /boot/defaults/loader.conf about the 'module_name'
variable, etc. and wondering what on Earth it might be useful for :)
Guess I know now :) Thanks again...
"Daniel C. Sobral" wrote:
Use two variables to control this. For
