Kevin Way [EMAIL PROTECTED] types:
You can even do this in userland with an nfs server API if you
want it to be portable.
Novel idea. I'll file it into the maybe pile.
Old idea. I first saw an ftp version of this in '91 or '92. Last time
I went looking for source code, I couldn't find it,
Chris Costello wrote:
On Friday, August 31, 2001, Michael Sinz wrote:
I too have been hoping for (and building internal tools) that work
this way. I really wish you could just do:
open(nfs://server.name.dom/directory/file.txt)
and have it work. That would be nice. (Replace
Paul Chvostek wrote:
On Fri, Aug 31, 2001 at 02:15:09PM -0400, Michael Sinz wrote:
I too have been hoping for (and building internal tools) that work
this way. I really wish you could just do:
open(nfs://server.name.dom/directory/file.txt)
NAME
amd - automatically
Anyway, the point is that a file that I can access should be a file I
can access via VI or MORE or EMACS or GREP or any other tool without
having those tools each having FTP and HTTP and SSH support built in to
them. The OS should handle it.
Yes, this should be nice. There's a similar
What I was trying to say is that there is no reason that I should care
if the file is local or not.
You do need to know if the file is local or not. You need to know
for security. You need to know because files behave differently on
different machines. You need to know because file structures
Sansonetti Laurent wrote:
Anyway, the point is that a file that I can access should be a file I
can access via VI or MORE or EMACS or GREP or any other tool without
having those tools each having FTP and HTTP and SSH support built in to
them. The OS should handle it.
Yes, this
On 04-Sep-01 Michael Sinz wrote:
Sansonetti Laurent wrote:
Anyway, the point is that a file that I can access should be a file I
can access via VI or MORE or EMACS or GREP or any other tool without
having those tools each having FTP and HTTP and SSH support built in to
them. The OS
Charlie Root wrote:
What I was trying to say is that there is no reason that I should care
if the file is local or not.
You do need to know if the file is local or not. You need to know
for security. You need to know because files behave differently on
different machines. You need to
All of this started with the quest for URIs being useable everywhere.
It's a stupid quest, for reasons others have pointed out.
When this isn't possible or
reasonable, it's not only difficult but *wrong* to abstract.
I never said this was trivial. We (which includes me) tried to start
What strikes me in this thread is that a lot of people are stupid and lazy
and want FreeBSD's kernel (or libc) to do stupid things with URLs the same
way you can throw a URL anywhere in Windows and have it mean something.
Here's some news for you: It shouldn't, and probably won't, happen.
If
NAME
amd - automatically mount file systems
...
DESCRIPTION
Amd is a daemon that automatically mounts filesystems whenever a file or
directory within that filesystem is accessed. Filesystems are automati-
cally unmounted when they appear to be quiescent.
Ahh,
If you're really lazy and want to be able to do:
telnet smtp://localhost
I suggest you look into this relatively new invention called
'/etc/services' and read some manual pages. You'll find you can do
something quite similar, and much saner.
I'm quite sure that Mr. Sinz wasn't
Kevin Way [EMAIL PROTECTED] types:
If you're really lazy and want to be able to do:
telnet smtp://localhost
I suggest you look into this relatively new invention called
'/etc/services' and read some manual pages. You'll find you can do
something quite similar, and much saner.
I'm
On Tue, Sep 04, 2001 at 07:08:44PM -0500, Mike Meyer wrote:
Kevin Way [EMAIL PROTECTED] types:
I'm quite sure that Mr. Sinz wasn't suggesting that telnet smtp://localhost
should do something useful. Nor do I consider his idea lazy. I do think
that he was suggesting, and I concur, that
On Fri, Aug 31, 2001 at 03:34:09PM -0700, David O'Brien wrote:
On Thu, Aug 30, 2001 at 11:21:09PM +0100, Steve Roome wrote:
ping http://www.myserver.wherever/
instead of telnet wherever 80, just to see if I get a connected or
not ?
Do you have *ANY* clue how ping works? Ping uses
Oh god, as everybody else is saying, I can't believe I'm getting involved
in this, but...
On Fri, Aug 31, 2001 at 09:58:21AM -0700, a little birdie told me
that Richard Hodges remarked
Why not parse it literally? For instance, http://www.ufp.org
would imply TCP, dest port 80, and host
On Fri, Aug 31, 2001 at 12:11:30AM +0400, [EMAIL PROTECTED] wrote:
Laurence Berland writes:
Optimally, you could write a urlsh or something, and leave everyone else
alone. The shell could do substitutions on URLs just like they do on
wildcards etc, and the applications would not need to
On Fri, 31 Aug 2001, David O'Brien wrote:
On Fri, Aug 31, 2001 at 09:58:21AM -0700, Richard Hodges wrote:
On the other hand, what exactly is http://www.ufp.org supposed to be useful
for when www.ufp.org is the same thing.
Why not parse it literally? For instance, http://www.ufp.org
On Sat, 1 Sep 2001, Matthew D. Fuller wrote:
For traceroute, I want to send a series of TCP SYN packets to
www.ufp.org, port 80 with increasing TTL values. Perhaps this
No, it doesn't.
http://www.ufp.org/ does NOT mean TCP port 80.
www.ufp.org:80 means port 80, I don't know of any
Greg Black [EMAIL PROTECTED] types:
| On Fri, Aug 31, 2001 at 10:36:44AM +1000, Greg Black wrote:
| Why not do it the Unix way? Create a new application, e.g.,
| url(1), to parse the URLs and use it like so:
| Sometimes the solution is so obvious. :-) Well, part of it. I'm
| thinking
Leo Bicknell writes:
On Fri, Aug 31, 2001 at 10:36:44AM +1000, Greg Black wrote:
Why not do it the Unix way? Create a new application, e.g.,
url(1), to parse the URLs and use it like so:
Sometimes the solution is so obvious. :-) Well, part of it. I'm
thinking it's worth creating
--On Thursday, August 30, 2001 16:15:05 +0100 Ceri [EMAIL PROTECTED]
wrote:
On Thu, Aug 30, 2001 at 11:10:18AM -0400, Leo Bicknell said:
I ran into a pair of all too common annoyances this morning that
got me thinking. Via the magic of cut and paste I ended up with
the following two sorts
On Fri, Aug 31, 2001 at 12:28:44PM +0100, Paul Richards wrote:
On the other hand, what exactly is http://www.ufp.org supposed to be useful
for when www.ufp.org is the same thing.
The specific problem I ran into that started this is that the 'copy link
location' option in browers (correctly)
On Fri, 31 Aug 2001, Paul Richards wrote:
A URI is a Universial Resource Indicator, it's not a web browser address.
On the other hand, what exactly is http://www.ufp.org supposed to be useful
for when www.ufp.org is the same thing.
Why not parse it literally? For instance,
--On Friday, August 31, 2001 09:58:21 -0700 Richard Hodges
[EMAIL PROTECTED] wrote:
On Fri, 31 Aug 2001, Paul Richards wrote:
A URI is a Universial Resource Indicator, it's not a web browser address.
On the other hand, what exactly is http://www.ufp.org supposed to be
useful for when
On Fri, Aug 31, 2001 at 09:28:22AM -0400, Leo Bicknell wrote:
In any case if all the info needed wasn't there, the command would fail,
a-la mutt http://www.ufp.org (no user portion).
I believe that http://www.ufp.org is a valid local email address.
--
Ben
An art scene of delight
I
Steve Roome wrote:
On Thu, Aug 30, 2001 at 11:17:08AM -0400, Keith Stevenson wrote:
Ick. If I wanted this kind of integration I would run Windows, KDE, or GNOME
instead of my nice, stable, predictable, lightweight desktop environment.
This entire email is very IMHO
Why? a URI is by
On Fri, Aug 31, 2001 at 02:15:09PM -0400, Michael Sinz wrote:
open(nfs://server.name.dom/directory/file.txt)
and have it work. That would be nice. (Replace the above with
ftp: or http: or whatever other protocol would provide read and/or write
access.)
Anyway, I don't see it
On Friday, August 31, 2001, Michael Sinz wrote:
I too have been hoping for (and building internal tools) that work
this way. I really wish you could just do:
open(nfs://server.name.dom/directory/file.txt)
and have it work. That would be nice. (Replace the above with
ftp: or
On Friday, August 31, 2001, Joseph Mallett wrote:
Check out ftpfs in the HURD. That might be a better way to do it.
No, I think that we're better off with NFS...
--
+---+--+
| Chris Costello| Help support helpless victims
On Fri, Aug 31, 2001 at 01:52:33PM -0500, Chris Costello wrote:
Whatever happened to not distinguishing different types of file
systems from one another in pathnames? And are you suggesting that
we add network overhead (I'd still imagine lo0 can't help speeding
things up...) to file
On Friday, August 31, 2001, Leo Bicknell wrote:
Presumably 'file:/etc/passwd' would not go through lo0.
I understood his statement (`the network includes the local
machine') to imply that he wants to do nfs://localhost/etc/passwd
rather than file:/etc/passwd.
--
On Fri, Aug 31, 2001 at 02:08:14PM -0500, Chris Costello wrote:
I understood his statement (`the network includes the local
machine') to imply that he wants to do nfs://localhost/etc/passwd
rather than file:/etc/passwd.
I would expect both to work, with differing levels of performance.
If
On Thu, Aug 30, 2001 at 11:21:09PM +0100, Steve Roome wrote:
ping http://www.myserver.wherever/
instead of telnet wherever 80, just to see if I get a connected or
not ?
Do you have *ANY* clue how ping works? Ping uses ICMP packets; not TCP,
not UDP -- thus there is NO concept of ports.
On Fri, Aug 31, 2001 at 09:58:21AM -0700, Richard Hodges wrote:
On the other hand, what exactly is http://www.ufp.org supposed to be useful
for when www.ufp.org is the same thing.
Why not parse it literally? For instance, http://www.ufp.org
would imply TCP, dest port 80, and host
David O'Brien wrote:
Do you know how traceroute works?? For one, the destination host cannot
be listening on the port used. And you know that each progressive
traceroute packet sent out bumps the destination port by one, to help
trace the ICMP time exceeded / port unreachable responses.
If memory serves me right, Hroi Sigurdsson wrote:
David O'Brien wrote:
Do you know how traceroute works?? For one, the destination host cannot
be listening on the port used. And you know that each progressive
traceroute packet sent out bumps the destination port by one, to help
trace
On Fri, Aug 31, 2001 at 06:34:55PM -0700, Bruce A. Mah wrote:
People are proposing to do various hacks to existing utilities and
applications without having any real idea of the impact of their ideas,
or even in some cases what semantic sense these hacks have.
For what it's worth, my original
On Thu, Aug 30, 2001 at 11:10:18AM -0400, Leo Bicknell wrote:
I ran into a pair of all too common annoyances this morning that
got me thinking. Via the magic of cut and paste I ended up with
the following two sorts of command lines:
mutt mailto:[EMAIL PROTECTED]
traceroute
Ceri writes:
On Thu, Aug 30, 2001 at 11:10:18AM -0400, Leo Bicknell said:
I ran into a pair of all too common annoyances this morning that
got me thinking. Via the magic of cut and paste I ended up with
the following two sorts of command lines:
mutt mailto:[EMAIL PROTECTED]
Optimally, you could write a urlsh or something, and leave everyone else
alone. The shell could do substitutions on URLs just like they do on
wildcards etc, and the applications would not need to be rewritten, plus
you wouldn't add bloat to those of us who don't want this in the system...
Leo Bicknell([EMAIL PROTECTED])@2001.08.30 11:10:18 +:
I ran into a pair of all too common annoyances this morning that
got me thinking. Via the magic of cut and paste I ended up with
the following two sorts of command lines:
mutt mailto:[EMAIL PROTECTED]
traceroute
Ceri writes:
On Thu, Aug 30, 2001 at 05:27:00PM +0200, Raymond Wiker said:
Ceri writes:
On Thu, Aug 30, 2001 at 11:10:18AM -0400, Leo Bicknell said:
I ran into a pair of all too common annoyances this morning that
got me thinking. Via the magic of cut and paste I ended up
Laurence Berland writes:
Optimally, you could write a urlsh or something, and leave everyone else
alone. The shell could do substitutions on URLs just like they do on
wildcards etc, and the applications would not need to be rewritten, plus
you wouldn't add bloat to those of us who don't want
On Thu, Aug 30, 2001 at 11:17:08AM -0400, Keith Stevenson wrote:
Ick. If I wanted this kind of integration I would run Windows, KDE, or GNOME
instead of my nice, stable, predictable, lightweight desktop environment.
This entire email is very IMHO
Why? a URI is by name a Uniform Resource
Leo Bicknell wrote:
| I ran into a pair of all too common annoyances this morning that
| got me thinking. Via the magic of cut and paste I ended up with
| the following two sorts of command lines:
|
| mutt mailto:[EMAIL PROTECTED]
| traceroute http://www.ufp.org/
|
| These of course come from
On Fri, Aug 31, 2001 at 10:36:44AM +1000, Greg Black wrote:
Why not do it the Unix way? Create a new application, e.g.,
url(1), to parse the URLs and use it like so:
Sometimes the solution is so obvious. :-) Well, part of it. I'm
thinking it's worth creating liburl, with parse routines, and
47 matches
Mail list logo
