Re: Fdescfs updates--coming to a devfs near you!
On Sun, 17 Sep 2000, Adrian Filipi-Martin wrote: I recently ran into revelant problem with /dev/stdout, while working on some software under linux that expected /dev/stdout as an argument instead of using stdout. Using the device file breaks, if the process is suid to a non-root user. This is because it cannot open /dev/stdout, which is owned by your UID and not the EUID of the process to which the device was passed. My solution was to add the "-" hack and use the existing open descriptor. Um, open on fdesc devices doesn't check either uid. It just checks the access mode. Perhaps the software expected /dev/stdout to for read-write like a tty would be. Then opening /dev/stdout would fail for normal shell output redirection which only opens for writing. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Fdescfs updates--coming to a devfs near you!
On Tue, 19 Sep 2000, Bruce Evans wrote: On Sun, 17 Sep 2000, Adrian Filipi-Martin wrote: I recently ran into revelant problem with /dev/stdout, while working on some software under linux that expected /dev/stdout as an argument instead of using stdout. Using the device file breaks, if the process is suid to a non-root user. This is because it cannot open /dev/stdout, which is owned by your UID and not the EUID of the process to which the device was passed. My solution was to add the "-" hack and use the existing open descriptor. Um, open on fdesc devices doesn't check either uid. It just checks the access mode. Perhaps the software expected /dev/stdout to for read-write like a tty would be. Then opening /dev/stdout would fail for normal shell output redirection which only opens for writing. No, it wasn't a RW/W issue. I dug a little deeper. It looks like the BSD implmentation of /dev/stdout is smarter than the linux version. Linux's is a symlink into /proc and the device ownership is determined by the UID of the invoking user. I guess I wouldn't have have had a problem under BSD. no suprise here. Adrian -- [ [EMAIL PROTECTED] -- Ubergeeks Consulting -- http://www.ubergeeks.com/ ] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: superduperopen(3) (was: Fdescfs updates--coming to a devfs near you!)
On Sat, Sep 16, 2000 at 10:04:47AM +0200, Gerhard Sittig wrote:
crazy mode on
How much sense does it make to think about implementing tee and
select methods this way? Like "open file1 and file2 and write to
both of them whatever I give to you" and "give me data coming in
from whatever file is in this set"? The only problem is to
determine available characters to separate these names. '+' as
well as ':', ',' and ';' are perfectly valid characters for
constructing filenames. '' seems to be too, but could be used
rarely enough. And the split upon these new separators actually
should be done only when the appropriate SDO_ flags are passed.
e.g.
superduperopen("file1file2", "a+", SDO_TEEFILES)
superduperopen("file1file2", "r" , SDO_SELECT)
FILE *superduperopen(char *files[], char *type, int flags);
[snip]
parameters) have to pass certain checks. Nobody should try to
read from "|command". And I cannot see any use for "write to
whatever descriptor is ready to write to first" as would result
from "w" and SDO_SELECT.
But they should be able to read from "command|", ofcourse. That feature
should be in there too :)
I do see a use to "write to whatever descriptor is ready first". It
could be used for a very simple multithreading-like implementation.
Spawn 8 child processes, attach them to one stream with
superduperopen(), and pass single-byte commands to one that is waiting
to handle one. If all 8 are busy, you block, or return something like
EAGAIN. This description is very pseudo-something, btw :)
Feel free to correct the flag's data type. I have the feeling
not all int's have 32bits. :) Some other means of storage might
int works for open, I doubt whether we need more options than open does :)
be more appropriate while still being easy to combine and to pass
to the function. But I feel strings like "STD,PIPE,TEE" are
There's no reason for that. We have a compiler that can parse *unquoted*
strings like STD | PIPE | TEE and create single int's out of that. Ain't
it wonderful :)
harder to parse and single character notation like the "wt" mode
flags are harder to find (think of) and to read (in terms of
eyeballing the source code) for the sdo case.
I do think the "w+" 'n stuff notation in popen sucks. This is our chance
to turn those into bitflags too, for superduperopen anyway.
Greetz, Peter
--
dataloss networks
'/ignore-ance is bliss' - me
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Fdescfs updates--coming to a devfs near you!
On Thu, 14 Sep 2000, Ben Smithurst wrote:
Poul-Henning Kamp wrote:
I must admit that I think in general that /dev/std{in,out,err} and /dev/fd
is bogus. It looks like something which happened "because we can" more
than something which has a legitimate need.
You think adding a hack to every program to support "-" to mean
stdout/stdin is better? It seems to be that saying "/dev/stdin" when
you mean stdin is better than saying "-" and hoping the application
handles that correctly. Of course many programs will read stdin by
default, and write stdout by default, but that doesn't help when you
want to read more than one file, one of which is stdin.
If anything I would propose we ditch it...
And break loads of scripts at the same time?
I recently ran into revelant problem with /dev/stdout, while
working on some software under linux that expected /dev/stdout as an
argument instead of using stdout.
Using the device file breaks, if the process is suid to a non-root
user. This is because it cannot open /dev/stdout, which is owned by your
UID and not the EUID of the process to which the device was passed. My
solution was to add the "-" hack and use the existing open descriptor.
Still, I don't think /dev/stdout and friends are such bad things
that they should be abandoned. They are present in other OS's and it does
help avoid making named pipes and the such when you need the behavior the
special devices provide. I think it would simple create minor poratability
issues for third party software.
Adrian
--
[ [EMAIL PROTECTED] -- Ubergeeks Consulting -- http://www.ubergeeks.com/ ]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: superduperopen(3) (was: Fdescfs updates--coming to a devfs near you!)
On Sun, Sep 17, 2000 at 20:36 +0200, Peter van Dijk wrote:
On Sat, Sep 16, 2000 at 10:04:47AM +0200, Gerhard Sittig wrote:
crazy mode on
[ ... how to find separating chars not used in filenames ... ]
e.g.
superduperopen("file1file2", "a+", SDO_TEEFILES)
superduperopen("file1file2", "r" , SDO_SELECT)
FILE *superduperopen(char *files[], char *type, int flags);
Of course it would be the cleanest thing to do, and I was aware
of this possibility. But that's when the interface is _very_
much different from fopen(3). That's where I'm reluctant to
introduce this hard a change. :) In addition it was not quite
clear how appropriate this semantics would be, at all.
Unless one sees this (yet to be renamed accordingly:) function as
something very different from fopen and "easy adaption of
existing utilities" is not so much of a concern, I still hesitate
to put this much more burdon on the programmer: opening single
files like fopen(3) did before would now mean to handle a "list
of one filenames" instead of passing whatever was there before --
just to have the lib handle stdin recognition.
I could suggest something even more ugly than the above "xy" for
those who want easy adaption:
superduperopen(char *fn, char *mode, int flags, ...);
with the \dots being zero or more filenames, only evaluated when
the flags suggest to do so. But it tears the first and any other
filename apart. The other solution was to provide two functions:
one fopen like plus the flags for when only one filename is
needed and another with a filename list, mode, and flags; being
the first a wrapper for the second (much as IPC::Open2 and
IPC::Open3 are). This would allow for a simple fixsized two
element array handled in the wrapper without the app's need to
care about anything more but the SDO_ flags for STD in the
existing cases we mainly talk about (cat(1) and the like).
After all I'm still not sure how useful this kind of extension
would be. It all started out with the wish for knowing "-" and
"|cmd" / "cmd|" where an interface like
superduperopen(char *fn, char *mode, int flags);
is sufficient.
[snip]
parameters) have to pass certain checks. Nobody should try
to read from "|command". And I cannot see any use for "write
to whatever descriptor is ready to write to first" as would
result from "w" and SDO_SELECT.
But they should be able to read from "command|", ofcourse. That
feature should be in there too :)
That's obvious (isn't it?). But there are definitely
combinations which aren't really useful. And some even shouldn't
be allowed at all.
Which brings me to a completely different topic: How much sense
does it make being able to read(2) directories? Shouldn't be
other functions (like stat, chdir, opendir friends) sufficient
and shouldn't read fail with EISDIR or something similar? I've
been bitten quite often from the garbled output of "head *" with
damaged terminal fonts afterwards. I know Linux had this before
but has been fixed for several years now. I'm aware this could
be a religious topic, but I feel it should have been discussed
before. It's just that I think searching for "read" or
"directory" in the list's archive is not very useful. Where can
I find more information on the reasons to still allow for this
misfeature (it's how I judge this short of knowing any
advantages).
I do see a use to "write to whatever descriptor is ready
first". It could be used for a very simple multithreading-like
implementation. Spawn 8 child processes, attach them to one
stream with superduperopen(), and pass single-byte commands to
one that is waiting to handle one.
Yes, but the same restriction as to "read from whatever is ready
first" apply: The type of data has to be "fixed size and without
problems splittable" or "not really produced in parallel but more
alternatively" as one byte commands are or keystrokes could be.
That's where I see only limited use for these. It heavily
depends on the applications' environments.
virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76
Gerhard Sittig true | mail -s "get gpg key" [EMAIL PROTECTED]
--
If you don't understand or are scared by any of the above
ask your parents or an adult to help you.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
RE: superduperopen(3) (was: Fdescfs updates--coming to a devfs near you!)
I think this thread needs to be killed. Whipping a horse that was dead 3
days ago is way too much. People have expressed thier opposition to PHK's
post and so it should end there.
For the love of cgi scripts, please keep /dev/stdin out so that peoples
web work can be sent to from the masses.
This is posted on NetBSD's web page, "Solutions and not hacks"
Stop trying to hack up a broken idea in order to kinda-sorta make it work
and produce a "Solution"
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Gerhard Sittig
Sent: Sunday, September 17, 2000 3:18 PM
To: [EMAIL PROTECTED]
Subject: Re: superduperopen(3) (was: Fdescfs updates--coming to a devfs
near you!)
On Sun, Sep 17, 2000 at 20:36 +0200, Peter van Dijk wrote:
On Sat, Sep 16, 2000 at 10:04:47AM +0200, Gerhard Sittig wrote:
crazy mode on
[ ... how to find separating chars not used in filenames ... ]
e.g.
superduperopen("file1file2", "a+", SDO_TEEFILES)
superduperopen("file1file2", "r" , SDO_SELECT)
FILE *superduperopen(char *files[], char *type, int flags);
Of course it would be the cleanest thing to do, and I was aware
of this possibility. But that's when the interface is _very_
much different from fopen(3). That's where I'm reluctant to
introduce this hard a change. :) In addition it was not quite
clear how appropriate this semantics would be, at all.
Unless one sees this (yet to be renamed accordingly:) function as
something very different from fopen and "easy adaption of
existing utilities" is not so much of a concern, I still hesitate
to put this much more burdon on the programmer: opening single
files like fopen(3) did before would now mean to handle a "list
of one filenames" instead of passing whatever was there before --
just to have the lib handle stdin recognition.
I could suggest something even more ugly than the above "xy" for
those who want easy adaption:
superduperopen(char *fn, char *mode, int flags, ...);
with the \dots being zero or more filenames, only evaluated when
the flags suggest to do so. But it tears the first and any other
filename apart. The other solution was to provide two functions:
one fopen like plus the flags for when only one filename is
needed and another with a filename list, mode, and flags; being
the first a wrapper for the second (much as IPC::Open2 and
IPC::Open3 are). This would allow for a simple fixsized two
element array handled in the wrapper without the app's need to
care about anything more but the SDO_ flags for STD in the
existing cases we mainly talk about (cat(1) and the like).
After all I'm still not sure how useful this kind of extension
would be. It all started out with the wish for knowing "-" and
"|cmd" / "cmd|" where an interface like
superduperopen(char *fn, char *mode, int flags);
is sufficient.
[snip]
parameters) have to pass certain checks. Nobody should try
to read from "|command". And I cannot see any use for "write
to whatever descriptor is ready to write to first" as would
result from "w" and SDO_SELECT.
But they should be able to read from "command|", ofcourse. That
feature should be in there too :)
That's obvious (isn't it?). But there are definitely
combinations which aren't really useful. And some even shouldn't
be allowed at all.
Which brings me to a completely different topic: How much sense
does it make being able to read(2) directories? Shouldn't be
other functions (like stat, chdir, opendir friends) sufficient
and shouldn't read fail with EISDIR or something similar? I've
been bitten quite often from the garbled output of "head *" with
damaged terminal fonts afterwards. I know Linux had this before
but has been fixed for several years now. I'm aware this could
be a religious topic, but I feel it should have been discussed
before. It's just that I think searching for "read" or
"directory" in the list's archive is not very useful. Where can
I find more information on the reasons to still allow for this
misfeature (it's how I judge this short of knowing any
advantages).
I do see a use to "write to whatever descriptor is ready
first". It could be used for a very simple multithreading-like
implementation. Spawn 8 child processes, attach them to one
stream with superduperopen(), and pass single-byte commands to
one that is waiting to handle one.
Yes, but the same restriction as to "read from whatever is ready
first" apply: The type of data has to be "fixed size and without
problems splittable" or "not really produced in parallel but more
alternatively" as one byte commands are or keystrokes could be.
That's where I see only limited use for these. It heavily
depends on the applications' environments.
virtually yours 82D1
Re: superduperopen(3) (was: Fdescfs updates--coming to a devfs near you!)
using Brian's post since I don't have the original around ...
On Sat, Sep 16, 2000 at 03:49 +0100, Brian Somers wrote:
[ attribution missing, is it Poul-Henning Kamp's text? ]
The majority of these programs could be handled by adding
knowledge of "-" as a magic filename to fopen(3).
[.]
At the same time I would really love if we implemented "|.*"
to mean "do an popen(3)" instead.
The only reasonable way to provide this functionality to apps not
wanting to reinvent it themselves without breaking those who feel
that files should be just that - files - is a _new_ function next
to fopen(3) named some rather alerting way like superduperopen(3)
with flags like SDO_KNOWS_STDIN, SDO_CAN_PIPEFROM,
SDO_CAN_PIPEINTO and whatever other extension you can think of.
32 of these new behaviour patterns should suffice for quite a
while. :)
This will collapse the "-" recognition and handling logic in
existing programs to passing a simple flag to a different
function (with only one more int parameter compared to fopen(3))
and leave those alone who just want to fopen(3) any file. And
when the options set is extended no app will "inherit" unwanted
and unexpected features turning out to be holes. Unless there's
a SDO_DO_ANY_PRESENT_AND_FUTURE_MAGIC flag passed with a value of
0x. But authors doing so will get what they deserve. :
One could even think of switching to the new function "to be
ready" and passing a SDO_DONT_DO_ANY_MAGIC flag.
crazy mode on
How much sense does it make to think about implementing tee and
select methods this way? Like "open file1 and file2 and write to
both of them whatever I give to you" and "give me data coming in
from whatever file is in this set"? The only problem is to
determine available characters to separate these names. '+' as
well as ':', ',' and ';' are perfectly valid characters for
constructing filenames. '' seems to be too, but could be used
rarely enough. And the split upon these new separators actually
should be done only when the appropriate SDO_ flags are passed.
e.g.
superduperopen("file1file2", "a+", SDO_TEEFILES)
superduperopen("file1file2", "r" , SDO_SELECT)
Semantics could be braindead simple: TEE will just dup any data
to every file specified and SELECT will have implicit priorities
since there's no logic doing round robing or something. This
will suffice for randomly filled input channels being fed more
alternatively rather than concurrently.
crazy mode off
Of course the mode parameter from fopen(3) and the magicmask
parameter from superduperopen(3) (i.e. the second and third
parameters) have to pass certain checks. Nobody should try to
read from "|command". And I cannot see any use for "write to
whatever descriptor is ready to write to first" as would result
from "w" and SDO_SELECT.
Feel free to correct the flag's data type. I have the feeling
not all int's have 32bits. :) Some other means of storage might
be more appropriate while still being easy to combine and to pass
to the function. But I feel strings like "STD,PIPE,TEE" are
harder to parse and single character notation like the "wt" mode
flags are harder to find (think of) and to read (in terms of
eyeballing the source code) for the sdo case.
virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76
Gerhard Sittig true | mail -s "get gpg key" [EMAIL PROTECTED]
--
If you don't understand or are scared by any of the above
ask your parents or an adult to help you.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Fdescfs updates--coming to a devfs near you!
On Thu, Sep 14, 2000 at 02:37:06PM +0200, Poul-Henning Kamp wrote: [...] The majority of these programs could be handled by adding knowledge of "-" as a magic filename to fopen(3). At the same time I would really love if we implemented "|.*" to mean "do an popen(3)" instead. This would break POSIX and raise a security flaw in many applications. fopen(3) *never* should perform a fork/exec. Scary. Bjoern -- -BEGIN GEEK CODE BLOCK- GCS d--(+) s++: a- C+++(-) UBOSI$ P+++(-) L---(++) !E W- N+ o+ K- !w !O !M !V PS++ PE- PGP++ t+++ !5 X++ tv- b+++ D++ G e+ h-- y+ --END GEEK CODE BLOCK-- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Fdescfs updates--coming to a devfs near you!
The majority of these programs could be handled by adding knowledge of "-" as a magic filename to fopen(3). [.] I would argue that the programs and the scripts that call them are already broken, but hey... So (just to add fuel to the mass opposition), do this without temporary files: count=$(program | tee /dev/stderr | wc -l) exit $count But then, you also said: At the same time I would really love if we implemented "|.*" to mean "do an popen(3)" instead. so I guess this could result in count=$(program |. cat | wc -l) exit $count (substitute correct "|.*" syntax - whatever that is). -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Fdescfs updates--coming to a devfs near you!
On Thu, 14 Sep 2000, Julian Elischer wrote: I've never thought of a use for fdescfs... I used /dev/fd/1 just yesterday for a third-party precompiled binary that insists on outputting to a file specified on the command line. Slapping in /dev/fd/1 lets me stuff the command in a pipe chain. Same goes for /dev/fd/0. Other file descriptors, I'm less sure about :-) Robert N M Watson [EMAIL PROTECTED] http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Fdescfs updates--coming to a devfs near you!
I've never thought of a use for fdescfs... -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000 --- X_.---._/ presently in: Perth v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Fdescfs updates--coming to a devfs near you!
On Thu, Sep 14, 2000 at 01:12:10AM -0700, Julian Elischer wrote: I've never thought of a use for fdescfs... Well.. just a trivial example - imagine a program which takes a filename as an argument; imagine yourself trying to pipe something into it - passing /dev/fd/0 as a filename to process would do the trick. G'luck, Peter -- .sith ekil ti gnidaer eb d'uoy ,werbeH ni erew ecnetnes siht fI To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Fdescfs updates--coming to a devfs near you!
In message [EMAIL PROTECTED], Peter Pentchev writes
:
On Thu, Sep 14, 2000 at 01:12:10AM -0700, Julian Elischer wrote:
I've never thought of a use for fdescfs...
Well.. just a trivial example - imagine a program which takes a filename
as an argument; imagine yourself trying to pipe something into it -
passing /dev/fd/0 as a filename to process would do the trick.
I must admit that I think in general that /dev/std{in,out,err} and /dev/fd
is bogus. It looks like something which happened "because we can" more
than something which has a legitimate need.
If anything I would propose we ditch it...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Fdescfs updates--coming to a devfs near you!
Poul-Henning Kamp wrote:
I must admit that I think in general that /dev/std{in,out,err} and /dev/fd
is bogus. It looks like something which happened "because we can" more
than something which has a legitimate need.
You think adding a hack to every program to support "-" to mean
stdout/stdin is better? It seems to be that saying "/dev/stdin" when
you mean stdin is better than saying "-" and hoping the application
handles that correctly. Of course many programs will read stdin by
default, and write stdout by default, but that doesn't help when you
want to read more than one file, one of which is stdin.
If anything I would propose we ditch it...
And break loads of scripts at the same time?
--
Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Fdescfs updates--coming to a devfs near you!
In message [EMAIL PROTECTED], Ben Smithurs
t writes:
Poul-Henning Kamp wrote:
I must admit that I think in general that /dev/std{in,out,err} and /dev/fd
is bogus. It looks like something which happened "because we can" more
than something which has a legitimate need.
You think adding a hack to every program to support "-" to mean
stdout/stdin is better?
The majority of these programs could be handled by adding knowledge
of "-" as a magic filename to fopen(3).
At the same time I would really love if we implemented "|.*" to mean
"do an popen(3)" instead.
But of course, this is bikeshed material...
If anything I would propose we ditch it...
And break loads of scripts at the same time?
I would argue that the programs and the scripts that call them are
already broken, but hey...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Fdescfs updates--coming to a devfs near you!
On Thu, Sep 14, 2000 at 02:37:06PM +0200, Poul-Henning Kamp wrote: [snip] The majority of these programs could be handled by adding knowledge of "-" as a magic filename to fopen(3). At the same time I would really love if we implemented "|.*" to mean "do an popen(3)" instead. Heh, and break security on loads of cgi-scripts while we're at it? Greetz, Peter -- dataloss networks '/ignore-ance is bliss' - me To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Fdescfs updates--coming to a devfs near you!
[EMAIL PROTECTED] said: :- The majority of these programs could be handled by adding knowledge of :- "-" as a magic filename to fopen(3). Suppose I *want* a filename called "-"? My tough luck, huh? I *like* /dev/stdin. It's orthogonal! -- Robert Withrow -- (+1 978 288 8256) [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Fdescfs updates--coming to a devfs near you!
[EMAIL PROTECTED] said: :- The majority of these programs could be handled by adding knowledge of :- "-" as a magic filename to fopen(3). Suppose I *want* a filename called "-"? My tough luck, huh? Could you settle for "./-"? Robert Withrow -- (+1 978 288 8256) [EMAIL PROTECTED] --Johnny To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
/proc /dev/std* [Was: Fdescfs updates--coming to a devfs near you!]
Johnny Eriksson wrote:
[EMAIL PROTECTED] said:
:- The majority of these programs could be handled by adding knowledge of
:- "-" as a magic filename to fopen(3).
Suppose I *want* a filename called "-"? My tough luck, huh?
Could you settle for "./-"?
I think any "magic" name is not very good idea. To say more, it breaks POSIX.
File names are a tratitional UNIX way to access character and block devices;
in System V you can access much more via file names, using streams.
Magic numbers are for MS DOS (remember COM1 and LPT1? :-)
I am not sure /proc/any number names are very useful, but
/dev/std{in|out|err} definitely are.
--
* *Konstantin Chuguev - Application Engineer
* * Francis House, 112 Hills Road
* Cambridge CB2 1PQ, United Kingdom
D A N T E WWW:http://www.dante.net
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Fdescfs updates--coming to a devfs near you!
Poul-Henning Kamp writes:
In message [EMAIL PROTECTED], Ben Smithurs
t writes:
Poul-Henning Kamp wrote:
I must admit that I think in general that /dev/std{in,out,err} and /dev/fd
is bogus. It looks like something which happened "because we can" more
than something which has a legitimate need.
You think adding a hack to every program to support "-" to mean
stdout/stdin is better?
The majority of these programs could be handled by adding knowledge
of "-" as a magic filename to fopen(3).
Ugh. So what happens when you *really* want to read a filed called
"-"? Adding magic characters to low-level calls is a bad idea.
I believe /dev/fd originated in Unix v8 (or maybe plan 9) to provide a
uniform mechanism to get a class of process-internal objects where
they can be manipulated by shell scripts. If that's the case, it's
provenance is impeccable.
At the same time I would really love if we implemented "|.*" to mean
"do an popen(3)" instead.
Again, putting magic character recognition in a low-level call is a
bad idea. Worse yet, this kind of thing is really useful in shells
(which don't generally have the ability to manipulate fd's). Consider
trying to use that syntax in the shell?
Which is why modern shells that implement this kind of thing use a
different syntax. Of course, they depend on something like /dev/fd or
named pipes to provide this feature.
But of course, this is bikeshed material...
Most certainly. If you really want to make C programming look like
Perl programming, could you do it by adding new library calls, instead
of changing the semantics of existing ones?
mike
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Fdescfs updates--coming to a devfs near you!
In message [EMAIL PROTECTED], Robert Withro w writes: [EMAIL PROTECTED] said: :- The majority of these programs could be handled by adding knowledge of :- "-" as a magic filename to fopen(3). Suppose I *want* a filename called "-"? My tough luck, huh? ./- Very few programs understand the filename "-" unless it is special cased to mean stdin/stdout -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Fdescfs updates--coming to a devfs near you!
Poul-Henning Kamp wrote:
I must admit that I think in general that /dev/std{in,out,err} and /dev/fd
is bogus. It looks like something which happened "because we can" more
than something which has a legitimate need.
I strongly disagree. I actually have a script that I use daily which requires
a filename as an argument. By handing it /dev/stdin, I can make it take
output as a part of a pipe. A _very_ useful little feature, IMNSHO.
As far as fdescfs, well, Unixware has something very like it, and I believe
that other commercial Unices do as well. I suspect that it's useful to
some, if not to all.
One thing about end users as opposed to engineers, they put this stuff to
uses that we can't even imagine. Never underestimate the sheer ingenuity
of a relatively naive user. :-)
--
Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/
Exit Consulting http://store.exit.com/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Fdescfs updates--coming to a devfs near you!
On Thu, 14 Sep 2000 11:48:58 +0200, Poul-Henning Kamp [EMAIL PROTECTED] said:
I must admit that I think in general that /dev/std{in,out,err} and /dev/fd
is bogus. It looks like something which happened "because we can" more
than something which has a legitimate need.
It's required if we ever get around to supporting secure set-id shell
scripts. (I think this was the rationale for originally introducing
it.) It also helps when bogus programs refuse to read from the
standard input.
-GAWollman
--
Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same
[EMAIL PROTECTED] | O Siem / The fires of freedom
Opinions not those of| Dance in the burning flame
MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Fdescfs updates--coming to a devfs near you!
Garrett Wollman wrote:
[/dev/stdin] also helps when bogus programs refuse to read from the
standard input.
Or if you want to read more than one file, one of which is standard input.
e.g.
gzip -dc oldlogs.*.gz | cat /dev/stdin todays-log | log-analyzer ...
Of course that will work with "-" instead of "/dev/stdin" but I
personally think it's the "-" hack to mean stdin/stdout which should be
abolished, not /dev/std{in,out,err}. No doubt others will disagree.
--
Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Fdescfs updates--coming to a devfs near you!
Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Peter Pentchev writes
:
On Thu, Sep 14, 2000 at 01:12:10AM -0700, Julian Elischer wrote:
I've never thought of a use for fdescfs...
Well.. just a trivial example - imagine a program which takes a filename
as an argument; imagine yourself trying to pipe something into it -
passing /dev/fd/0 as a filename to process would do the trick.
I must admit that I think in general that /dev/std{in,out,err} and /dev/fd
is bogus. It looks like something which happened "because we can" more
than something which has a legitimate need.
How about the fact that the printing chapter in the Handbook uses /dev/fd/0
in its example of setting up a print filter using ghostscript since gs
doesn't read from stdin by default or use '-' for that purpose. Hmmm??
If anything I would propose we ditch it...
Tools, not policy, as you are so fond of saying.
--
John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Fdescfs updates--coming to a devfs near you!
On Thu, 14 Sep 2000, John Baldwin wrote:
Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Peter Pentchev writes
I must admit that I think in general that /dev/std{in,out,err} and /dev/fd
is bogus. It looks like something which happened "because we can" more
than something which has a legitimate need.
How about the fact that the printing chapter in the Handbook uses /dev/fd/0
in its example of setting up a print filter using ghostscript since gs
doesn't read from stdin by default or use '-' for that purpose. Hmmm??
Actually, I think it should be the other way around: if anything should
go, it's the use of '-' in programs/scripts. The only advantage is that
it saves keystrokes.
I agree, /dev/std{in,out} is a very neat and elegant way of working with
stdin/out. If anything is the kludge, it's '-', and it's really vague as
to what it means. With /dev/std{in,out}, there's no doubt as to what's
going on with file ops. Plus, it's the unix way (tm) of doing
things. Almost all Unices have this, don't they? This means there's
likely to be some cross-platform shell scripts that use those things.
- Donn
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Fdescfs updates--coming to a devfs near you!
At 11:48 AM +0200 9/14/00, Poul-Henning Kamp wrote:
I must admit that I think in general that /dev/std{in,out,err}
and /dev/fd is bogus. It looks like something which happened
"because we can" more than something which has a legitimate need.
If anything I would propose we ditch it...
I think it is a reasonable feature to have. It probably won't
be useful all that often, but it could be very useful in some
situations. I know I've hit situations where I wished I could
do something like this, but I couldn't tell you an example
right this minute.
So, I wouldn't want to see fdesfs ditched, but on the other
hand I don't have any clue how to address the loose ends that
Chris mentioned in his initial message. :-)
---
Garance Alistair Drosehn = [EMAIL PROTECTED]
Senior Systems Programmer or [EMAIL PROTECTED]
Rensselaer Polytechnic Institute
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: !.* [ was: Fdescfs updates--coming to a devfs near you! ]
On 14-Sep-00 at 05:37, Poul-Henning Kamp ([EMAIL PROTECTED]) wrote: You think adding a hack to every program to support "-" to mean stdout/stdin is better? The majority of these programs could be handled by adding knowledge of "-" as a magic filename to fopen(3). At the same time I would really love if we implemented "|.*" to mean "do an popen(3)" instead. Isn't that potentially a huge security hole in every program that gets a filename from an external source? But of course, this is bikeshed material... If anything I would propose we ditch it... And break loads of scripts at the same time? I would argue that the programs and the scripts that call them are already broken, but hey... And I would argue that the fdescfs is cleaner than the '-' hack. (Which, by the way, should not be considered a filename hack so much as a command-line-parameter hack; since it was invented before there was a way to say 'use stdin/stdout' on the command-line... You could think of '/dev/stdin' as "'-' version 2") -Pat To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Fdescfs updates--coming to a devfs near you!
In message [EMAIL PROTECTED] Garrett Wollman writes: : It's required if we ever get around to supporting secure set-id shell : scripts. (I think this was the rationale for originally introducing : it.) It also helps when bogus programs refuse to read from the : standard input. I'd like to see us enable that. It would remove the need to have setuid perl, for example. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Fdescfs updates--coming to a devfs near you!
Over the past few months, I've been working on the /dev/fd file system
("fdescfs"). After weeks of occasionally-hacking and putting it off, I've
finalized a patch for fdescfs.
What this patch changes:
+ fdesc_allocvp() becomes curproc-free as a `struct proc' pointer is passed
as the new fourth parameter.
+ All usage of the `DTYPE' open file type macros are removed. Anything
whose fo_stat() operation does not return proper fdesc information is
broken. The checks for DTYPE_VNODE (for determining whether setattr()
will do anything) are replaced by getvnode() so that if the method for
determining a vnode from a file entry changes, (hopefully) that's the
only place it will happen.
There is one loose end I'm not sure I know just how to tie up yet. I'm
having trouble modifying src/sys/kern/sys_pipe.c:pipe_stat() to return the
right st_mode flags based on various conditions. I'd appreciate it if
someone else who knows about the pipe code could point me in the right
direction as to what conditions permit reading and what conditions permit
writing (and what makes them fail).
The patch is available at
http://people.FreeBSD.org/~chris/fdesc-dtype.patch,
Documentation for it is available at
http://people.FreeBSD.org/~chris/fdesc/
all in one page:
http://people.FreeBSD.org/~chris/fdesc/article.html
|Chris Costello [EMAIL PROTECTED]
|Press [ESC] to detonate or any other key to explode.
`
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
