Mike Meyer stated:
: [EMAIL PROTECTED] types:
: > At 29 Jan 2001 11:49:36 +0100,
: > Dag-Erling Smorgrav <[EMAIL PROTECTED]> wrote:
: > > No. Mergemaster doesn't care about the contents of the file, only
: > > about its $FreeBSD$ tag. As long as this stays the same, it'll leave
: > > the file alon
[EMAIL PROTECTED] types:
> At 29 Jan 2001 11:49:36 +0100,
> Dag-Erling Smorgrav <[EMAIL PROTECTED]> wrote:
> > No. Mergemaster doesn't care about the contents of the file, only
> > about its $FreeBSD$ tag. As long as this stays the same, it'll leave
> > the file alone. If you remove the $FreeBSD$
At 29 Jan 2001 11:49:36 +0100,
Dag-Erling Smorgrav <[EMAIL PROTECTED]> wrote:
> No. Mergemaster doesn't care about the contents of the file, only
> about its $FreeBSD$ tag. As long as this stays the same, it'll leave
> the file alone. If you remove the $FreeBSD$ tag in the installed file
> or some
On Mon, 29 Jan 2001 11:31:32 -0500 (EST)
Garrett Wollman <[EMAIL PROTECTED]> wrote:
GW> I would rather have a single file, located in a directory intended for
GW> configuration files. Perhaps we could call it ``/etc/shells'' which
GW> seems to be popular.
As you wish. I have no axe to g
On Mon, Jan 29, 2001 at 11:31:32AM -0500, Garrett Wollman wrote:
> < said:
> > I would rather that a separate configuration file be read, for example,
> > with a list of shells(5) format files to consult.
>
> I would rather have a single file, located in a directory intended for
> configuration f
< said:
> I would rather that a separate configuration file be read, for example,
> with a list of shells(5) format files to consult.
I would rather have a single file, located in a directory intended for
configuration files. Perhaps we could call it ``/etc/shells'' which
seems to be popular.
Vadim Belman <[EMAIL PROTECTED]> writes:
> On Sun, Jan 28, 2001 at 11:53:50PM -0500, Louis A. Mamakos wrote:
> > It doesn't seem unreasonable to have a single file with a list of allowable
> > shells.
> It does if you think of mergemaster, for example. With any upgrade
> it consider /etc/she
On Sun, Jan 28, 2001 at 11:53:50PM -0500, Louis A. Mamakos wrote:
> Does this capability really need to exist (e.g., supporting many files)? It
> would seem like the additional complexity would be not what you want for what's
> essentially a security policy mechansim. Who gets to own these incl
/etc/shells is such a simple file, I don't see much of point in
polluting it. There is not much of difference having a port install:
target edit /etc/shells verses editing /usr/local/etc/shells. It
should just edit /etc/shells.
-M
On Sun, 28 Jan 2001 23:53:50 -0500
"Louis A. Mamakos" <[EMAIL PROTECTED]> wrote:
LM> It doesn't seem unreasonable to have a single file with a list of allowable
LM> shells.
One thing - it is kind of cute having the allowable shells match
the mounted shells.
To Unsubscribe: send mail t
On Sun, 28 Jan 2001 22:19:29 -0800 (PST)
John Baldwin <[EMAIL PROTECTED]> wrote:
JB> People whine about the problem though, so having no solution doesn't
JB> help either. Since #include is syntatically a comment, it shouldn't
JB> mess up other programs, though the idea is that they will all use
On 29-Jan-01 Louis A. Mamakos wrote:
>> On Sun, Jan 28, 2001 at 10:13:49AM +0100, Steve O'Hara-Smith wrote:
>> >Hi,
>> >
>> >Asbestos suit on, round two.
>> >
>> >The patch below changes getusershell to support a #include syntax
>> > in /etc/shells.
>>
>> I guess this is what I ob
> On Sun, Jan 28, 2001 at 10:13:49AM +0100, Steve O'Hara-Smith wrote:
> > Hi,
> >
> > Asbestos suit on, round two.
> >
> > The patch below changes getusershell to support a #include syntax
> > in /etc/shells.
>
> I guess this is what I object to. I don't particularly like having
On Sun, Jan 28, 2001 at 10:13:49AM +0100, Steve O'Hara-Smith wrote:
> Hi,
>
> Asbestos suit on, round two.
>
> The patch below changes getusershell to support a #include syntax
> in /etc/shells.
I guess this is what I object to. I don't particularly like having a
new direct
Hi,
Asbestos suit on, round two.
The patch below changes getusershell to support a #include syntax
in /etc/shells. It is against RELENG_4 and may require a bit of fiddling
to apply to -current (because of nsdispatch()).
Everything that I can find is using it (wel
15 matches
Mail list logo