MFC'ing new md(4) functionality?

[Dima Dorfman]

Is there any reason not to MFC the new md(4) functionality (i.e., swap
and vnode support)?  With MFS and vn(4) gone in -current, I think that
the sooner users can start moving to md(4) in -stable the less cries
there will be come 5.0-RELEASE.

Additionally, the porting effort is not that great.  mdconfig(8) and
mdioctl.h aren't in -stable so those can be brought over verbatim, and the
only changes to md.c itself are bio->buf stuff, and some added spl's.  I've
put the diff for the latter against -stable at
http://www.unixfreak.org/~dima/home/mdmfc.diff.  If someone wants a diff
between that and -current for review let me know and I'll generate one.

I'm also willing to do the actual merges if no one else has time, so the
question raised in the first paragraph remains: is there any reason not to
do this?

Thanks in advance,

Dima Dorfman
[EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: speeding up /etc/security

[Kevin Way]

> The answer there is 'sort of'.  /etc/security checks all ufs partitions
> that aren't marked nosuid.  if you're using anything other than UFS
> (e.g. MFS,ext2,whatever), it's not getting checked at all.

i hate to followup to my own message, but in order for the SUID checks to
be accurate, is there a reson we don't do something like the following?

--- security.orig   Mon Jun  4 22:26:01 2001
+++ securityMon Jun  4 22:31:47 2001

@@ -69,7 +69,7 @@
 # Note that one of the original problems, the possibility of overrunning
 # the args to ls, is still here...
 #
-MP=`mount -t ufs | grep -v " nosuid" | awk '{ print $3 }' | sort`
+MP=`( mount -t cd9660; mount -t ext2fs; mount -t ffs; mount -t ifs; mount -t lfs; 
+mount -t mfs; mount -t ufs ) | grep -v ' nosuid' | awk '{ print $3 }' | sort` set 
+${MP}
 while [ $# -ge 1 ]; do
   mount=$1


-Kevin Way

 PGP signature

Re: Resource reservation idea

[Mike Smith]

> Currently on FreeBSD, resources are either free, allocated or activated.  
> As I understand it, they mean approximately the following:
>  - Free: unused.
>  - Allocated: Resource reserved for use by device X.
>  - Activated: Resource actively used by device X.
> 
> This leaves somewhat of a gap.  What if bus Y wants to reserve some
> resource for an attached hardware, but the driver of the hardware does
> not exist (yet)?  Currently, I can think of two ways this can be done:
>  - Have the bus allocate the resource, then hand it off to the child 
>if/when it requests it.  From my experience with cardbus, this can 
>get messy and each bus has to implement its own resource management.

This is how I'm doing it in the new PCI code; since PCI devices actually 
have these resources assigned whether a device happens to be using them 
or not, this is a good match.

With Cardbus, you should be allocating the resources when the card 
arrives, then hand them off to the driver, and release them when the card 
goes away.

This model works quite well; a resource is typically either extant and 
decoded, or not extant at all.  The grey cases are already reasonablly 
well handled (multiple ownership, allocated vs. active, etc.)

Resource lists make handling this fairly easy.

>  - Some dummy driver which grabs the resource.  The dummy driver would 
>need to be unloaded when the actual driver needs the resources.

This sounds attractive, but it's hard to find the dummy driver when 
you want to open the bidding for one or more devices again.  You also end 
up with the ugly case where the device has more resources than the driver 
uses; you end up needing a placeholder of some sort for these as well, so 
you might as well just built it into the way the bus thinks about child 
devices and be done with it.

> What I propose is this -- implement a new set of bus functions
> bus_reserve_resource(), with the following parameters:

I don't see that these are actually necessary.  The current model works 
just fine.

> An alternative to this system is to provide some interface to easily 
> hand-off resources from a bus to its child.  While this will work for 
> most cases, it does not provide functionality for a case where a bus 
> might want to reserve a range to eventually dish out to various 
> different children.

Typically, a bus isn't going to "reserve a range" in the fashion you 
describe.  It should just request the resources it wants, and let the 
bridge above it (and potentially the series of bridges above it) sort out 
what range(s) are appropriate.  In most cases, a bus really isn't going 
to know in advance what sort of resources it might need to assign to its 
children, so second-guessing will lead to suboptimal behaviour.

> On a side note, I just thought of something -- should PCI bus numbers be 
> treated as a resource too?

Yes; at least, a PCI device should be able to request a PCI bus number 
range.  This is necessary for configuring unconfigured PCI:PCI bridges.
-- 
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also.  But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view.  [Dr. Fritz Todt]
   V I C T O R Y   N O T   V E N G E A N C E



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Resource reservation idea

[Jonathan Chen]

Currently on FreeBSD, resources are either free, allocated or activated.  
As I understand it, they mean approximately the following:
 - Free: unused.
 - Allocated: Resource reserved for use by device X.
 - Activated: Resource actively used by device X.

This leaves somewhat of a gap.  What if bus Y wants to reserve some
resource for an attached hardware, but the driver of the hardware does
not exist (yet)?  Currently, I can think of two ways this can be done:
 - Have the bus allocate the resource, then hand it off to the child 
   if/when it requests it.  From my experience with cardbus, this can 
   get messy and each bus has to implement its own resource management.
 - Some dummy driver which grabs the resource.  The dummy driver would 
   need to be unloaded when the actual driver needs the resources.

What I propose is this -- implement a new set of bus functions
bus_reserve_resource(), with the following parameters:
  device_t parent,
  device_t bus,
  int type,
  u_long start,
  u_long end,
  u_int flags

  [I don't believe a resource id is necessary or desirable.  Consider the 
   case where a child might reserve a range in the middle of what the 
   parent has reserved, thereby splitting the original reservation into 
   three, rendering the rid's messed up.]

The core functions can be implemented at the nexus level with the default 
function passing the hat to its parent.  The nexus reserve functions would 
have the following properties:
 - If resource specified is free, reserve it to the bus.
 - If resource specified is (partially) allocated/activated by anything 
   other than the bus's immediate child, return error.
 - If resource specified is (partially) already reserved, and
   - requested resource is completely reserved to any parent, change 
 reservation to new device. 
   - otherwise, fail.

One flag might be RF_DEFAULT_RANGE, where child devices to that bus with 
automatically try to use something within that range if the resource 
range is not explicitly specified.

bus_unreserve_resource() would simply remove the reservation for all 
resources within the specified range that is reserved to the bus, 
regardless of whether the resource is currently allocated.  It would 
have the following parameters:
  device_t parent,
  device_t bus,
  int type,
  u_long start,
  u_long end

There would also need to be changes in the nexus alloc_resource() 
functions, as follows:
 - If resource range is not explicitly specified, try allocation within 
   default range.  If entire resource does not fit, try fitting as much 
   as possible.
 - If resource range is explicitly specified, check if any portion of 
   the resource is reserved.  If any portion of the resource is reserved 
   to anything other than the device's immediate parent, return error.

The proposed changes above should not require changes to existing bus 
codes to maintain compatibility.  Only minimal changes should be 
required to take advantage of this.

An alternative to this system is to provide some interface to easily 
hand-off resources from a bus to its child.  While this will work for 
most cases, it does not provide functionality for a case where a bus 
might want to reserve a range to eventually dish out to various 
different children.

Please comment on the necessity, portability, interface, functionality 
(or whatever else you can think of) of what is described here.  If all 
goes well, I hope to have some initial implementation in not too long.


On a side note, I just thought of something -- should PCI bus numbers be 
treated as a resource too?

-- 
(o_ 1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2 _o)
 \\\_\Jonathan Chen  [EMAIL PROTECTED] /_///
 <)  No electrons were harmed during production of this message (>
 ~


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: background_fsck rc.conf option

[Andreas Dobloug; UiO; H98]

Index: etc/rc
===
RCS file: /stl/src/FreeBSD/src/etc/rc,v
retrieving revision 1.264
diff -u -r1.264 rc
--- etc/rc  2001/05/13 20:43:30 1.264
+++ etc/rc  2001/05/21 00:19:25
@@ -184,9 +184,14 @@
 case ${bootmode} in
 autoboot)
echo 'Automatic boot in progress...'
-#  To restore old fsck behavior use:
-#  fsck -p
-   fsck -F -p
+   case ${background_fsck} in
+   [Yy][Ee][Ss])
+   fsck -F -p
[..]


This patch doesn't work on boxes with nfs/msdos mounts...
I suggest adding "-t no,nfs,msdos,ntfs" to the parameter list.

-- 
Andreas Dobloug

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: speeding up /etc/security

[Kevin Way]

> Does /etc/security take filesystem mounted with:
> 
>  nosuid  Do not allow set-user-identifier or set-group-identifier
>  bits to take effect.  Note: this option is worthless if a
>  public available suid or sgid wrapper like suidperl(1)
>  is installed on your system.
> 
> into account? If so, and the filesystems have nothing on them that
> needs suid you could mount 'm this way

The answer there is 'sort of'.  /etc/security checks all ufs partitions
that aren't marked nosuid.  if you're using anything other than UFS
(e.g. MFS,ext2,whatever), it's not getting checked at all.

Kevin Way

 PGP signature

Re: speeding up /etc/security

[Rich Morin]

At 10:48 PM +0100 6/4/01, Brian Somers wrote:
>As you suspect, mounting nosuid makes /etc/security skip the
>suid checks... good for giving the security-unconscious a reason
>to fix their system :)

Works for me...

-r
-- 
email: [EMAIL PROTECTED]; phone: +1 650-873-7841
http://www.cfcl.com/rdm - home page, resume, etc.
http://www.cfcl.com/Meta/md_fb.html - The FreeBSD Browser
http://www.ptf.com/tdc - Prime Time Freeware's Darwin Collection

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: speeding up /etc/security

[Brian Somers]

As you suspect, mounting nosuid makes /etc/security skip the 
suid checks... good for giving the security-unconscious a reason 
to fix their system :)

I was alway quite impressed with this :)

> On Mon, Jun 04, 2001 at 12:07:19PM -0700, Matthew Jacob wrote:
> 
> Does /etc/security take filesystem mounted with:
> 
>  nosuid  Do not allow set-user-identifier or set-group-identifier
>  bits to take effect.  Note: this option is worthless if a
>  public available suid or sgid wrapper like suidperl(1)
>  is installed on your system.
> 
> into account? If so, and the filesystems have nothing on them that
> needs suid you could mount 'm this way
> 
> Just a thought,
> 
> Wilko
> 
> > That's an interesting question.
> > 
> > A couple of ideas:
> > 
> > a) I wonder of RWatson's ACL stuff could help here?
> > 
> > b) This problem cries for a DMAPI type solution- you could have a daemon that
> > monitors all creats/chmods and retains knowledge of the filenames for all
> > SUID/SGID creats/chmods- this way /etc/security would simply summarize the
> > current list and could be run any time.
> > 
> > > /etc/security takes a number of hours to run on my system.  The problem
> > > is that I have some very large mounted file systems and the code to look
> > > for setuid files wants to walk through them all.  I recoded the check in
> > > Perl, but it ran at about the same speed.  I have considered reworking
> > > the code to do the file systems in parallel, but I thought I should ask
> > > here first.  Comments?  Suggestions?
> > > 
> > > -r
> > > 
> > 
> > 
> > 
> > To Unsubscribe: send mail to [EMAIL PROTECTED]
> > with "unsubscribe freebsd-hackers" in the body of the message
> ---end of quoted text---
> 
> -- 
> |   / o / /  _ Arnhem, The Netherlandsemail: [EMAIL PROTECTED]
> |/|/ / / /( (_) Bulte  Powered by FreeBSD/[alpha,x86] http://www.freebsd.org  

-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

pipe implementation questions

[Jaromír Dolecek]

Hi folks,
I'm working on a port of FreeBSD pipe implementation to NetBSD. So far,
the results are pretty owesame, the new pipes are significantly faster
than the old socketpair-based ones. Good work!

However, I found couple of things I don't quite understand and would
like to clarify if this is how things are supposed to work or if
I'm consfused :)

1) SIGIO for O_ASYNC reader, sync writer
   I made a test program which makes a pipe, sets owner of the read end,
   setup signal handler for SIGIO and switches the read end to
   O_NONBLOCK|O_ASYNC mode. Program forks,
   child makes sync write to the write (synchronous) end of pipe.
   When parents loops calling read() on the read end until it succeeds.
   However, I found out the parent gets SIGIO for each read(2) attempt.

This behaviour seems to be due to last couple of lines of pipe_read():

if ((rpipe->pipe_buffer.size - rpipe->pipe_buffer.cnt) >= PIPE_BUF)
pipeselwakeup(rpipe);

This condition is commonly true if the reader is polling for input. The code
should signal the writer, not the reader - it doesn't make sense to
signal possibility of writing more data to the reader itself.
IMHO the code should be like:

if ((rpipe->pipe_buffer.size - rpipe->pipe_buffer.cnt) >= PIPE_BUF) {
struct pipe *wpipe = rpipe->pipe_peer;
if (wpipe)
pipeselwakeup(wpipe);
}

Also, the code could possibly only call the pipeselwakeup() if anything
was actually read from the pipe previously (or, even better, only once
since last write(2)), to avoid sending SIGIO's to the writer if the
the reader found the pipe empty.

2) direct write - first uio only
  FreeBSD direct write code seems to handle only first uio buffer,
  so e.g. writev(2) with multiple buffers doesn't write all data
  at once.  This is valid behaviour (return short write and expect
  writer to update itself and try again with rest), I'd like just
  to ensure I read the code correctly.

3) direct write - loses for huge buffers?
  It seems pipe_build_write_buffer() tries to fault all the address space
  specified by uio. However, pipe_map.ms[] has only (BIG_PIPE_SIZE/PAGE_SIZE+1)
  members, so this seems to lose if the covered address space (size of
  buffer passed to write(2)) is > 64+4=68KB. Also, the code
  which calls pmap_qenter() thinks the buffer size is
  wpipe->pipe_buffer.size + PAGE_SIZE maximum. Do I read the code correctly,
  or is there anything I miss? The current port to NetBSD doesn't use
  this particular piece of code (the difference between FreeBSD VM and UVM
  is too big), but it's something I encountered and would like to understand :)
  
Thanks for you cooperation :)

Jaromir

P.S. Please CC: me, I'm not on the list
-- 
Jaromir Dolecek <[EMAIL PROTECTED]>  http://www.ics.muni.cz/~dolecek/
NetBSD - just plain best OS! -=*=- Got spare MCA cards or docs? Hand me them!

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: speeding up /etc/security

[Matthew Jacob]

Let me turn it around and say that process accounting should be only one of a
set of actions that can be emitted from the kernel and recorded somewhere.


On Mon, 4 Jun 2001, Gersh wrote:

> What about something like what process accounting does?
> 
> It would be trivial to update a file (say /var/db/setxid)
> whenever certian chmod / fchmod actions are taken.
> 
> If it only happened when chmod/fchmod actions happened that
> effected setxid stauts it should not impact performence to much either 
> IMHO.
> 
> I think that the real thing to consid with a approach like this is.
> 
> 1)  How useful would it be.
> 2)  Because it would be used for something security relevant the
> "database" file would need to remain secure at all times.
> 
> On Mon, 4 Jun 2001, Matthew Jacob wrote:
> 
> > 
> > That's an interesting question.
> > 
> > A couple of ideas:
> > 
> > a) I wonder of RWatson's ACL stuff could help here?
> > 
> > b) This problem cries for a DMAPI type solution- you could have a daemon that
> > monitors all creats/chmods and retains knowledge of the filenames for all
> > SUID/SGID creats/chmods- this way /etc/security would simply summarize the
> > current list and could be run any time.
> > 
> > > /etc/security takes a number of hours to run on my system.  The problem
> > > is that I have some very large mounted file systems and the code to look
> > > for setuid files wants to walk through them all.  I recoded the check in
> > > Perl, but it ran at about the same speed.  I have considered reworking
> > > the code to do the file systems in parallel, but I thought I should ask
> > > here first.  Comments?  Suggestions?
> > > 
> > > -r
> > > 
> > 
> > 
> > 
> > To Unsubscribe: send mail to [EMAIL PROTECTED]
> > with "unsubscribe freebsd-hackers" in the body of the message
> > 
> 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: speeding up /etc/security

[Gersh]

What about something like what process accounting does?

It would be trivial to update a file (say /var/db/setxid)
whenever certian chmod / fchmod actions are taken.

If it only happened when chmod/fchmod actions happened that
effected setxid stauts it should not impact performence to much either 
IMHO.

I think that the real thing to consid with a approach like this is.

1)  How useful would it be.
2)  Because it would be used for something security relevant the
"database" file would need to remain secure at all times.

On Mon, 4 Jun 2001, Matthew Jacob wrote:

> 
> That's an interesting question.
> 
> A couple of ideas:
> 
> a) I wonder of RWatson's ACL stuff could help here?
> 
> b) This problem cries for a DMAPI type solution- you could have a daemon that
> monitors all creats/chmods and retains knowledge of the filenames for all
> SUID/SGID creats/chmods- this way /etc/security would simply summarize the
> current list and could be run any time.
> 
> > /etc/security takes a number of hours to run on my system.  The problem
> > is that I have some very large mounted file systems and the code to look
> > for setuid files wants to walk through them all.  I recoded the check in
> > Perl, but it ran at about the same speed.  I have considered reworking
> > the code to do the file systems in parallel, but I thought I should ask
> > here first.  Comments?  Suggestions?
> > 
> > -r
> > 
> 
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
> 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: speeding up /etc/security

[Wilko Bulte]

On Mon, Jun 04, 2001 at 12:07:19PM -0700, Matthew Jacob wrote:

Does /etc/security take filesystem mounted with:

 nosuid  Do not allow set-user-identifier or set-group-identifier
 bits to take effect.  Note: this option is worthless if a
 public available suid or sgid wrapper like suidperl(1)
 is installed on your system.

into account? If so, and the filesystems have nothing on them that
needs suid you could mount 'm this way

Just a thought,

Wilko

> That's an interesting question.
> 
> A couple of ideas:
> 
> a) I wonder of RWatson's ACL stuff could help here?
> 
> b) This problem cries for a DMAPI type solution- you could have a daemon that
> monitors all creats/chmods and retains knowledge of the filenames for all
> SUID/SGID creats/chmods- this way /etc/security would simply summarize the
> current list and could be run any time.
> 
> > /etc/security takes a number of hours to run on my system.  The problem
> > is that I have some very large mounted file systems and the code to look
> > for setuid files wants to walk through them all.  I recoded the check in
> > Perl, but it ran at about the same speed.  I have considered reworking
> > the code to do the file systems in parallel, but I thought I should ask
> > here first.  Comments?  Suggestions?
> > 
> > -r
> > 
> 
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
---end of quoted text---

-- 
|   / o / /  _   Arnhem, The Netherlandsemail: [EMAIL PROTECTED]
|/|/ / / /( (_) BultePowered by FreeBSD/[alpha,x86] http://www.freebsd.org  

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: speeding up /etc/security

[Matthew Jacob]

That's an interesting question.

A couple of ideas:

a) I wonder of RWatson's ACL stuff could help here?

b) This problem cries for a DMAPI type solution- you could have a daemon that
monitors all creats/chmods and retains knowledge of the filenames for all
SUID/SGID creats/chmods- this way /etc/security would simply summarize the
current list and could be run any time.

> /etc/security takes a number of hours to run on my system.  The problem
> is that I have some very large mounted file systems and the code to look
> for setuid files wants to walk through them all.  I recoded the check in
> Perl, but it ran at about the same speed.  I have considered reworking
> the code to do the file systems in parallel, but I thought I should ask
> here first.  Comments?  Suggestions?
> 
> -r
> 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

speeding up /etc/security

[Rich Morin]

/etc/security takes a number of hours to run on my system.  The problem
is that I have some very large mounted file systems and the code to look
for setuid files wants to walk through them all.  I recoded the check in
Perl, but it ran at about the same speed.  I have considered reworking
the code to do the file systems in parallel, but I thought I should ask
here first.  Comments?  Suggestions?

-r
-- 
http://www.cfcl.com/rdm - home page, resume, etc.
http://www.cfcl.com/Meta/md_fb.html - The FreeBSD Browser
email: [EMAIL PROTECTED]; phone: +1 650-873-7841

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

RE: Patch to fix code that kills procs when swap runs out (stabl

[John Baldwin]

On 03-Jun-01 Matt Dillon wrote:
> Alfred, I'm cc'ing you.  If you have some time, could you check the
> vmspace_swap_count() routine?  What do I need to mutex it for -current?
> For -stable I don't think there's an issue since VM objects are not
> instantiated/destroyed by interrupts.
> 
> All suggestions are welcome.

Barring whatever Alfred says, it looks like you don't need any additional
locking as we already hold the vm mutex by the time we get to that point
in swapout_procs().

-- 

John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

cyclades Cyclom-8Ys card with newer firmware

[Falco Krepel]

Hello Andrew,

I want to use the Cyclom-8Ys card for a console server (with FreeBSD
5.0). But the driver doesn't work. First I get the error "No ports
found".

After debugging I found the problem. You check in cy.c in the function
cy_units() the firmware version. If the firmware is between 0x40-0x4F no
problem occur but my card has the firmware version 0x91. I make a strait
forward approach and comment out that if-statement. I get no error
message but when I try to connect to the port with kermit than I get a
timeout message "channel command timeout (5001 usec)" from the function
cd1400_channel_cmd_wait().

Do you have any idea what the problem may be?

Thanx,

Falco Krepel

-- 
Falco KrepelPhone:  +49-(0)30 - 34 63 - 7 276
GMD-FOKUS   Fax:+49-(0)30 - 34 63 - 8 276
Kaiserin-Augusta-Allee 31   e-mail: [EMAIL PROTECTED]
10589 BerlinWWW:http://www.fokus.gmd.de/usr/krepel

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Fixing documented bug in env(1)

[Mike Meyer]

Mark Valentine <[EMAIL PROTECTED]> types:
> > From: [EMAIL PROTECTED] (Mike Meyer)
> > Date: Mon 4 Jun, 2001
> > Subject: Re: Fixing documented bug in env(1)
> 
> > "#!/usr/bin/env foobar" will work just fine.
> At the mercy of the user's path...

If you're really worried about that, do "#!/usr/bin/env /usr/local/bin/foobar".
That will also work where "#!/usr/local/bin/foobar" won't.

  http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Fixing documented bug in env(1)

[Mark Valentine]

> From: [EMAIL PROTECTED] (Mike Meyer)
> Date: Mon 4 Jun, 2001
> Subject: Re: Fixing documented bug in env(1)

> "#!/usr/bin/env foobar" will work just fine.

At the mercy of the user's path...

Cheers,

Mark.

-- 
Mark Valentine, Thuvia Labs <[EMAIL PROTECTED]>   
"Tigers will do ANYTHING for a tuna fish sandwich."   Mark Valentine uses
"We're kind of stupid that way."   *munch* *munch*and endorses FreeBSD
  --   

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message