Parag Patel wrote:
>
> I said:
>
> >Anyway, command-line apps have been obsolete for years, so I guess we
> >should go on and find better things to argue about. :)
>
> I guess people missed the ":)" so I'd better explain.
>
> Most computers are embedded and becoming both more ubiquitous and
>
Parag Patel wrote:
>
> I said:
>
> >Anyway, command-line apps have been obsolete for years, so I guess we
> >should go on and find better things to argue about. :)
>
> I guess people missed the ":)" so I'd better explain.
>
> Most computers are embedded and becoming both more ubiquitous and
>
On Tue, Sep 14, 1999 at 03:54:50PM -0700, Parag Patel wrote:
> Anyway, command-line apps have been obsolete for years, so I guess we
> should go on and find better things to argue about. :)
Heh.
So far, I've only found one GUI that I would really miss without X
Windows: SWAT in netscape.
--
Do
On Tue, Sep 14, 1999 at 03:54:50PM -0700, Parag Patel wrote:
> Anyway, command-line apps have been obsolete for years, so I guess we
> should go on and find better things to argue about. :)
Heh.
So far, I've only found one GUI that I would really miss without X
Windows: SWAT in netscape.
--
D
I said:
>Anyway, command-line apps have been obsolete for years, so I guess we
>should go on and find better things to argue about. :)
I guess people missed the ":)" so I'd better explain.
Most computers are embedded and becoming both more ubiquitous and
invisble. Most of these don't even *hav
I said:
>Anyway, command-line apps have been obsolete for years, so I guess we
>should go on and find better things to argue about. :)
I guess people missed the ":)" so I'd better explain.
Most computers are embedded and becoming both more ubiquitous and
invisble. Most of these don't even *ha
On Tue, 14 Sep 1999, Parag Patel wrote:
> Anyway, command-line apps have been obsolete for years,
According to whom, Microsoft? I would claim that any functionality that
is not fully supported by a command line interface (except, perhaps, for
specifically graphical functionality) is not fully su
On Tue, 14 Sep 1999, Parag Patel wrote:
> Anyway, command-line apps have been obsolete for years,
According to whom, Microsoft? I would claim that any functionality that
is not fully supported by a command line interface (except, perhaps, for
specifically graphical functionality) is not fully s
On Tue, 14 Sep 1999 23:44:50 +0200, Oliver Fromme wrote:
>It _is_ in one place if it's in a library. And personally
>I think that's exatly where it belongs. Does libedit ring
>a bell...?
Yes, I know about libedit and libreadline. My point is I shouldn't have
to alter any command-line app to l
On Tue, 14 Sep 1999 23:44:50 +0200, Oliver Fromme wrote:
>It _is_ in one place if it's in a library. And personally
>I think that's exatly where it belongs. Does libedit ring
>a bell...?
Yes, I know about libedit and libreadline. My point is I shouldn't have
to alter any command-line app to li
Parag Patel wrote in list.freebsd-hackers:
> On Tue, 14 Sep 1999 17:39:34 BST, Dominic Mitchell wrote:
> >It gets complicated very quickly.
>
> Oh I agree - but I still think it should only need to be in one place
> rather than in a library or in each individual app.
It _is_ in one place if
Parag Patel wrote in list.freebsd-hackers:
> On Tue, 14 Sep 1999 17:39:34 BST, Dominic Mitchell wrote:
> >It gets complicated very quickly.
>
> Oh I agree - but I still think it should only need to be in one place
> rather than in a library or in each individual app.
It _is_ in one place if
On Tue, 14 Sep 1999 17:39:34 BST, Dominic Mitchell wrote:
>Would that allow for the flexibility of, say zsh's programmable
>completion? And then combined with my right hand side prompt?
>
>It gets complicated very quickly.
Oh I agree - but I still think it should only need to be in one place
ra
On Tue, 14 Sep 1999 17:39:34 BST, Dominic Mitchell wrote:
>Would that allow for the flexibility of, say zsh's programmable
>completion? And then combined with my right hand side prompt?
>
>It gets complicated very quickly.
Oh I agree - but I still think it should only need to be in one place
rat
On Mon, Sep 13, 1999 at 08:34:59PM -0700, Parag Patel wrote:
> On Mon, 13 Sep 1999 09:23:36 BST, Dominic Mitchell wrote:
> >
> >On Fri, Sep 10, 1999 at 11:15:12AM -0700, Parag Patel wrote:
> >> Growing up programming on a KL-10, I still think the correct place for
> >> line-editing is in the drive
On Mon, Sep 13, 1999 at 08:34:59PM -0700, Parag Patel wrote:
> On Mon, 13 Sep 1999 09:23:36 BST, Dominic Mitchell wrote:
> >
> >On Fri, Sep 10, 1999 at 11:15:12AM -0700, Parag Patel wrote:
> >> Growing up programming on a KL-10, I still think the correct place for
> >> line-editing is in the driver
On Mon, 13 Sep 1999 09:23:36 BST, Dominic Mitchell wrote:
>
>On Fri, Sep 10, 1999 at 11:15:12AM -0700, Parag Patel wrote:
>> Growing up programming on a KL-10, I still think the correct place for
>> line-editing is in the driver. Hell - it's already doing basic
>> erase/kill line editing as it is.
> On Fri, Sep 10, 1999 at 11:15:12AM -0700, Parag Patel wrote:
> > Growing up programming on a KL-10, I still think the correct place for
> > line-editing is in the driver. Hell - it's already doing basic
> > erase/kill line editing as it is. Then you don't have to hack every
> > command-line
> On Fri, Sep 10, 1999 at 11:15:12AM -0700, Parag Patel wrote:
> > Growing up programming on a KL-10, I still think the correct place for
> > line-editing is in the driver. Hell - it's already doing basic
> > erase/kill line editing as it is. Then you don't have to hack every
> > command-line a
On Fri, Sep 10, 1999 at 11:15:12AM -0700, Parag Patel wrote:
> Growing up programming on a KL-10, I still think the correct place for
> line-editing is in the driver. Hell - it's already doing basic
> erase/kill line editing as it is. Then you don't have to hack every
> command-line app to get l
On Fri, Sep 10, 1999 at 11:15:12AM -0700, Parag Patel wrote:
> Growing up programming on a KL-10, I still think the correct place for
> line-editing is in the driver. Hell - it's already doing basic
> erase/kill line editing as it is. Then you don't have to hack every
> command-line app to get li
On Fri, 10 Sep 1999, Matthew N. Dodd wrote:
> > Okay. If that's the plan, then I don't have any objections.
> >
> > I do hate the idea of having to reimplement samba because of the licensing
> > though - it already does quite a good job at SMB serving, it seems a waste
> > to duplicate the effort
On Fri, 10 Sep 1999, Kris Kennaway wrote:
> > Thats the idea. Once Boris gets a chance to finish cifsfs the plan is to
> > import it into the tree the same as the Netware client stuff.
>
> Okay. If that's the plan, then I don't have any objections.
>
> I do hate the idea of having to reimplement
On Fri, 10 Sep 1999, Matthew N. Dodd wrote:
> On Fri, 10 Sep 1999, Kris Kennaway wrote:
> > I tend to agree. If we bring in all of this stuff (even though I
> > appreciate it's very useful) we should also bring in samba into the
> > base tree by symmetry.
>
> Thats the idea. Once Boris gets a ch
On Fri, 10 Sep 1999, Matthew N. Dodd wrote:
> > Okay. If that's the plan, then I don't have any objections.
> >
> > I do hate the idea of having to reimplement samba because of the licensing
> > though - it already does quite a good job at SMB serving, it seems a waste
> > to duplicate the effor
On Fri, 10 Sep 1999, Kris Kennaway wrote:
> > Thats the idea. Once Boris gets a chance to finish cifsfs the plan is to
> > import it into the tree the same as the Netware client stuff.
>
> Okay. If that's the plan, then I don't have any objections.
>
> I do hate the idea of having to reimplemen
On Fri, 10 Sep 1999, Matthew N. Dodd wrote:
> On Fri, 10 Sep 1999, Kris Kennaway wrote:
> > I tend to agree. If we bring in all of this stuff (even though I
> > appreciate it's very useful) we should also bring in samba into the
> > base tree by symmetry.
>
> Thats the idea. Once Boris gets a c
On Fri, 10 Sep 1999, Kris Kennaway wrote:
> I tend to agree. If we bring in all of this stuff (even though I
> appreciate it's very useful) we should also bring in samba into the
> base tree by symmetry.
Thats the idea. Once Boris gets a chance to finish cifsfs the plan is to
import it into the t
On Fri, 10 Sep 1999, Kris Kennaway wrote:
> I tend to agree. If we bring in all of this stuff (even though I
> appreciate it's very useful) we should also bring in samba into the
> base tree by symmetry.
Thats the idea. Once Boris gets a chance to finish cifsfs the plan is to
import it into the
On Fri, 10 Sep 1999, Ruslan Ermilov wrote:
> > Is there any reason to not have it as a port?
> >
> IMHO, only the basic IPX/SPX functionality should be included into the
> source tree. Anything else could be available as ports/net/nw-utils.
I tend to agree. If we bring in all of this stuff (eve
And thus spake Matthew N. Dodd, on Fri, Sep 10, 1999 at 02:07:12PM -0400:
> Clean it up and add perl bindings to it. Thats something that perl sorely
> misses. Come to think of it, libedit could use perl bindings... Hummm...
>
> Kevin? :)
Bleah, one thing at a time :) Once I finish with my c
In message <37d93d65.627a...@dons.net.au> "Daniel O'Connor" writes:
: > Thats like suggesting we make the 'ipfw' command a port and leave the
: > kernel bits in the tree. Since all this stuff depends on being in sync,
: > the only reasonable way to do this is to put it in the tree.
:
: Why? What
On Fri, Sep 10, 1999 at 02:07:12PM -0400, Matthew N. Dodd wrote:
> Clean it up and add perl bindings to it. Thats something that perl sorely
> misses. Come to think of it, libedit could use perl bindings... Hummm...
/usr/ports/devel/p5-ReadLine-Gnu
Also /usr/ports/devel/p5-ReadLine-Perl, whic
On Fri, 10 Sep 1999, Ruslan Ermilov wrote:
> > Is there any reason to not have it as a port?
> >
> IMHO, only the basic IPX/SPX functionality should be included into the
> source tree. Anything else could be available as ports/net/nw-utils.
I tend to agree. If we bring in all of this stuff (ev
On Fri, 10 Sep 1999 14:07:12 EDT, "Matthew N. Dodd" wrote:
>
>Clean it up and add perl bindings to it. Thats something that perl sorely
>misses. Come to think of it, libedit could use perl bindings... Hummm...
Gaah - another big line-editing library! My editor's even smaller than
libedit!
On Fri, 10 Sep 1999, Parag Patel wrote:
> I have an (as yet still incomplete) full-screen text-editor library I
> wrote a long time ago - in C++ even - that supports (on a terminal using
> termlib but not curses) full-screen editing, simultaneous "live"
> multiple overlapping windows/views of buffe
And thus spake Matthew N. Dodd, on Fri, Sep 10, 1999 at 02:07:12PM -0400:
> Clean it up and add perl bindings to it. Thats something that perl sorely
> misses. Come to think of it, libedit could use perl bindings... Hummm...
>
> Kevin? :)
Bleah, one thing at a time :) Once I finish with my
On Sat, 11 Sep 1999 03:08:40 +0930, "Daniel O'Connor" wrote:
>
>"Matthew N. Dodd" wrote:
>> You want to take the anti-bloatist stance you'll have to do better than
>> that. Try libreadline for starters. :)
>
>Bah like I care enough to care ;)
Yow! I had no idea it was so large!
I have an (as
"Matthew N. Dodd" wrote:
> > Why? What kernel code does this need?
> The ncpfs kernel code for one.
> We're talking about less than 500k of code here.
> You want to take the anti-bloatist stance you'll have to do better than
> that. Try libreadline for starters. :)
Bah like I care enough to care
In message <[EMAIL PROTECTED]> "Daniel O'Connor" writes:
: > Thats like suggesting we make the 'ipfw' command a port and leave the
: > kernel bits in the tree. Since all this stuff depends on being in sync,
: > the only reasonable way to do this is to put it in the tree.
:
: Why? What kernel cod
On Fri, Sep 10, 1999 at 02:07:12PM -0400, Matthew N. Dodd wrote:
> Clean it up and add perl bindings to it. Thats something that perl sorely
> misses. Come to think of it, libedit could use perl bindings... Hummm...
/usr/ports/devel/p5-ReadLine-Gnu
Also /usr/ports/devel/p5-ReadLine-Perl, whi
On Sat, 11 Sep 1999, Daniel O'Connor wrote:
> "Matthew N. Dodd" wrote:
> > > The only possible candidate for contrib'ifying I could see would be
> > > mount_nwfs because building it without the kernel source could be a
> > > problem, but the rest of it could be a port I think :)
> > Thats like sugg
On Fri, 10 Sep 1999 14:07:12 EDT, "Matthew N. Dodd" wrote:
>
>Clean it up and add perl bindings to it. Thats something that perl sorely
>misses. Come to think of it, libedit could use perl bindings... Hummm...
Gaah - another big line-editing library! My editor's even smaller than
libedit!
"Matthew N. Dodd" wrote:
> > The only possible candidate for contrib'ifying I could see would be
> > mount_nwfs because building it without the kernel source could be a
> > problem, but the rest of it could be a port I think :)
> Thats like suggesting we make the 'ipfw' command a port and leave t
On Fri, 10 Sep 1999, Parag Patel wrote:
> I have an (as yet still incomplete) full-screen text-editor library I
> wrote a long time ago - in C++ even - that supports (on a terminal using
> termlib but not curses) full-screen editing, simultaneous "live"
> multiple overlapping windows/views of buff
On Sat, 11 Sep 1999 03:08:40 +0930, "Daniel O'Connor" wrote:
>
>"Matthew N. Dodd" wrote:
>> You want to take the anti-bloatist stance you'll have to do better than
>> that. Try libreadline for starters. :)
>
>Bah like I care enough to care ;)
Yow! I had no idea it was so large!
I have an (as
> On Fri, 10 Sep 1999, Daniel O'Connor wrote:
>
> > Is there any reason to not have it as a port?
> >
> > The only possible candidate for contrib'ifying I could see would be
> > mount_nwfs
> > because building it without the kernel source could be a problem, but the
> > rest
> > of it could be
"Matthew N. Dodd" wrote:
> > Why? What kernel code does this need?
> The ncpfs kernel code for one.
> We're talking about less than 500k of code here.
> You want to take the anti-bloatist stance you'll have to do better than
> that. Try libreadline for starters. :)
Bah like I care enough to car
On Sat, 11 Sep 1999, Daniel O'Connor wrote:
> "Matthew N. Dodd" wrote:
> > > The only possible candidate for contrib'ifying I could see would be
> > > mount_nwfs because building it without the kernel source could be a
> > > problem, but the rest of it could be a port I think :)
> > Thats like sug
"Matthew N. Dodd" wrote:
> > The only possible candidate for contrib'ifying I could see would be
> > mount_nwfs because building it without the kernel source could be a
> > problem, but the rest of it could be a port I think :)
> Thats like suggesting we make the 'ipfw' command a port and leave
On Fri, 10 Sep 1999, Marcel Moolenaar wrote:
> > Currently I'm trying to determine a reasonable set of NetWare
> > utilities which should be included in the source tree.
>
> Is it possible to have utilities to query and modify NDS?
I'm working on this (currently only queries). ND
"Matthew N. Dodd" wrote:
> On Fri, 10 Sep 1999, Daniel O'Connor wrote:
> > On 10-Sep-99 Boris Popov wrote:
> > > mount_nwfs - similar to mount_nfs
> > > ncplogin- creates permanent connection to a NetWare server
> > > without an actual mount,
> On Fri, 10 Sep 1999, Daniel O'Connor wrote:
>
> > Is there any reason to not have it as a port?
> >
> > The only possible candidate for contrib'ifying I could see would be mount_nwfs
> > because building it without the kernel source could be a problem, but the rest
> > of it could be a port I
On Fri, 10 Sep 1999, Daniel O'Connor wrote:
> On 10-Sep-99 Boris Popov wrote:
> > mount_nwfs - similar to mount_nfs
> > ncplogin- creates permanent connection to a NetWare server
> > without an actual mount,
> > ncplogo
On Fri, 10 Sep 1999, Marcel Moolenaar wrote:
> > Currently I'm trying to determine a reasonable set of NetWare
> > utilities which should be included in the source tree.
>
> Is it possible to have utilities to query and modify NDS?
I'm working on this (currently only queries). N
"Matthew N. Dodd" wrote:
> On Fri, 10 Sep 1999, Daniel O'Connor wrote:
> > On 10-Sep-99 Boris Popov wrote:
> > > mount_nwfs - similar to mount_nfs
> > > ncplogin- creates permanent connection to a NetWare server
> > > without an actual mount,
On Fri, 10 Sep 1999, Daniel O'Connor wrote:
> On 10-Sep-99 Boris Popov wrote:
> > mount_nwfs - similar to mount_nfs
> > ncplogin- creates permanent connection to a NetWare server
> > without an actual mount,
> > ncplog
Boris Popov wrote:
> Currently I'm trying to determine a reasonable set of NetWare
> utilities which should be included in the source tree.
Is it possible to have utilities to query and modify NDS?
> ncpurge - purge specified salvagable files,
On Fri, 10 Sep 1999, Peter Wemm wrote:
> > Yes, that's acceptable. But mount_nwfs require libncp.so and this
> > means that ncp library sources will be also required. So KLD, mount_nwfs
> > and libncp should go into source tree and other utilities can be a port.
> >
> > Other thoughts ?
Boris Popov wrote:
> Currently I'm trying to determine a reasonable set of NetWare
> utilities which should be included in the source tree.
Is it possible to have utilities to query and modify NDS?
> ncpurge - purge specified salvagable files,
>From a user perspective,
On Fri, 10 Sep 1999, Peter Wemm wrote:
> > Yes, that's acceptable. But mount_nwfs require libncp.so and this
> > means that ncp library sources will be also required. So KLD, mount_nwfs
> > and libncp should go into source tree and other utilities can be a port.
> >
> > Other thoughts ?
Boris Popov wrote:
> On Fri, 10 Sep 1999, Daniel O'Connor wrote:
>
> > Is there any reason to not have it as a port?
> >
> > The only possible candidate for contrib'ifying I could see would be mount_n
wfs
> > because building it without the kernel source could be a problem, but the r
est
On Fri, Sep 10, 1999 at 05:24:00PM +0700, Boris Popov wrote:
> On Fri, 10 Sep 1999, Ruslan Ermilov wrote:
>
> > > An IPX/SPX stack is already in the tree and past year made it more
> > > or less functional.
> > >
> > Read: I fully agree with Daniel.
>
> Daniel also left mount_nwfs :)
>
On Fri, 10 Sep 1999, Ruslan Ermilov wrote:
> > An IPX/SPX stack is already in the tree and past year made it more
> > or less functional.
> >
> Read: I fully agree with Daniel.
Daniel also left mount_nwfs :)
>
> Forgive me my ignorance, but I'd like a quick response: what about mult
Boris Popov wrote:
> On Fri, 10 Sep 1999, Daniel O'Connor wrote:
>
> > Is there any reason to not have it as a port?
> >
> > The only possible candidate for contrib'ifying I could see would be mount_n
wfs
> > because building it without the kernel source could be a problem, but the r
est
On Fri, Sep 10, 1999 at 04:58:52PM +0700, Boris Popov wrote:
> On Fri, 10 Sep 1999, Ruslan Ermilov wrote:
>
> > > Is there any reason to not have it as a port?
> > >
> > IMHO, only the basic IPX/SPX functionality should be included into the
> > source tree. Anything else could be available as po
On Fri, 10 Sep 1999, Ruslan Ermilov wrote:
> > Is there any reason to not have it as a port?
> >
> IMHO, only the basic IPX/SPX functionality should be included into the
> source tree. Anything else could be available as ports/net/nw-utils.
An IPX/SPX stack is already in the tree and pa
On Fri, 10 Sep 1999, Daniel O'Connor wrote:
> Is there any reason to not have it as a port?
>
> The only possible candidate for contrib'ifying I could see would be mount_nwfs
> because building it without the kernel source could be a problem, but the rest
> of it could be a port I think :)
On Fri, Sep 10, 1999 at 05:24:00PM +0700, Boris Popov wrote:
> On Fri, 10 Sep 1999, Ruslan Ermilov wrote:
>
> > > An IPX/SPX stack is already in the tree and past year made it more
> > > or less functional.
> > >
> > Read: I fully agree with Daniel.
>
> Daniel also left mount_nwfs :)
>
On Fri, 10 Sep 1999, Ruslan Ermilov wrote:
> > An IPX/SPX stack is already in the tree and past year made it more
> > or less functional.
> >
> Read: I fully agree with Daniel.
Daniel also left mount_nwfs :)
>
> Forgive me my ignorance, but I'd like a quick response: what about mul
On Fri, Sep 10, 1999 at 06:29:57PM +0930, Daniel O'Connor wrote:
>
> On 10-Sep-99 Boris Popov wrote:
> > mount_nwfs - similar to mount_nfs
> > ncplogin- creates permanent connection to a NetWare server
> > without an actual mount,
On Fri, Sep 10, 1999 at 04:58:52PM +0700, Boris Popov wrote:
> On Fri, 10 Sep 1999, Ruslan Ermilov wrote:
>
> > > Is there any reason to not have it as a port?
> > >
> > IMHO, only the basic IPX/SPX functionality should be included into the
> > source tree. Anything else could be available as p
On Fri, 10 Sep 1999, Ruslan Ermilov wrote:
> > Is there any reason to not have it as a port?
> >
> IMHO, only the basic IPX/SPX functionality should be included into the
> source tree. Anything else could be available as ports/net/nw-utils.
An IPX/SPX stack is already in the tree and p
On 10-Sep-99 Boris Popov wrote:
> mount_nwfs - similar to mount_nfs
> ncplogin- creates permanent connection to a NetWare server
> without an actual mount,
> ncplogout - destroy permanent connection,
> ncpl
On Fri, 10 Sep 1999, Daniel O'Connor wrote:
> Is there any reason to not have it as a port?
>
> The only possible candidate for contrib'ifying I could see would be mount_nwfs
> because building it without the kernel source could be a problem, but the rest
> of it could be a port I think :)
Hello,
Currently I'm trying to determine a reasonable set of NetWare
utilities which should be included in the source tree.
ncplib isn't just a NetWare file system. It also provides services
similar to original NetWare client from Novell. Below I'll put a short
descriptio
On Fri, Sep 10, 1999 at 06:29:57PM +0930, Daniel O'Connor wrote:
>
> On 10-Sep-99 Boris Popov wrote:
> > mount_nwfs - similar to mount_nfs
> > ncplogin- creates permanent connection to a NetWare server
> > without an actual mount,
On 10-Sep-99 Boris Popov wrote:
> mount_nwfs - similar to mount_nfs
> ncplogin- creates permanent connection to a NetWare server
> without an actual mount,
> ncplogout - destroy permanent connection,
> ncp
Hello,
Currently I'm trying to determine a reasonable set of NetWare
utilities which should be included in the source tree.
ncplib isn't just a NetWare file system. It also provides services
similar to original NetWare client from Novell. Below I'll put a short
descripti
79 matches
Mail list logo
