I noticed that I need a pseudodevice that opens normally but blocks all
reads (and writes). The only way out would be through a signal. Neither
/dev/zero nor /dev/null block, but is there some other standard device
that would do the job?
If there isn't, writing such a pseudodevice would be trivial. What
should it be called? Any chance of including that in the kernel?
Marko
--
Marko Rauhamaa mailto:[email protected] http://www.pacujo.nu/marko/
> I noticed that I need a pseudodevice that opens normally but blocks all
> reads (and writes). The only way out would be through a signal. Neither
Try using a pipe
On Mon, 29 Oct 2001, Marko Rauhamaa wrote:
>
> I noticed that I need a pseudodevice that opens normally but blocks all
> reads (and writes). The only way out would be through a signal. Neither
> /dev/zero nor /dev/null block, but is there some other standard device
> that would do the job?
>
> If there isn't, writing such a pseudodevice would be trivial. What
> should it be called? Any chance of including that in the kernel?
/dev/never
On Monday 29 October 2001 22:45, Hugh Dickins wrote:
> On Mon, 29 Oct 2001, Marko Rauhamaa wrote:
> > I noticed that I need a pseudodevice that opens normally but blocks
> > all reads (and writes). The only way out would be through a signal.
> > Neither /dev/zero nor /dev/null block, but is there some other
> > standard device that would do the job?
> >
> > If there isn't, writing such a pseudodevice would be trivial. What
> > should it be called? Any chance of including that in the kernel?
>
> /dev/never
sorry, the bait was too obvious: /dev/microsoft
--
ElkOS: 12:01am up 6 days, 9:32, 3 users, load average: 2.54, 2.40, 2.27
bofhX: appears to be a Slow/Narrow SCSI-0 Interface problem
On Tue, Oct 30, 2001 at 12:03:42AM +0100, elko wrote:
> On Monday 29 October 2001 22:45, Hugh Dickins wrote:
> > On Mon, 29 Oct 2001, Marko Rauhamaa wrote:
> > > I noticed that I need a pseudodevice that opens normally but blocks
> > > all reads (and writes). The only way out would be through a signal.
> > > Neither /dev/zero nor /dev/null block, but is there some other
> > > standard device that would do the job?
> > >
> > > If there isn't, writing such a pseudodevice would be trivial. What
> > > should it be called? Any chance of including that in the kernel?
> >
> > /dev/never
>
> sorry, the bait was too obvious: /dev/microsoft
No,
cat /dev/microsoft > /dev/never
;)
> > I noticed that I need a pseudodevice that opens normally but blocks all
> > reads (and writes). The only way out would be through a signal. Neither
>
> Try using a pipe
You're right. This is what I wanted to do:
while true
do
ssh -R a:b:c host
sleep 10
done </dev/never >/dev/null
But I could do it like this:
while true
do
sleep 100000
done |
while true
do
ssh -R a:b:c host
sleep 10
done >/dev/null
Thank you.
Marko
PS Are /dev/null and /dev/zero also redundant?
--
Marko Rauhamaa mailto:[email protected] http://www.pacujo.nu/marko/
On Mon, 29 Oct 2001, Marko Rauhamaa wrote:
> > > I noticed that I need a pseudodevice that opens normally but blocks all
> > > reads (and writes). The only way out would be through a signal. Neither
> >
> > Try using a pipe
>
> You're right. This is what I wanted to do:
>
> while true
> do
> ssh -R a:b:c host
> sleep 10
> done </dev/never >/dev/null
>
> But I could do it like this:
>
> while true
> do
> sleep 100000
> done |
> while true
> do
> ssh -R a:b:c host
> sleep 10
> done >/dev/null
Highly elegant :)
How bout just `mkfifo /tmp/blockme`
and read on /tmp/blockme - just don't write to it!
--
TimC -- http://www.physics.usyd.edu.au/~tcon/
> cat ~/.signature
CPU time limit exceeded (core dumped)
> How bout just `mkfifo /tmp/blockme`
> and read on /tmp/blockme - just don't write to it!
I don't think that will work, not the same way anyway. The problem is it
will block on open(2) and will never get to read(2).
Marko
--
Marko Rauhamaa mailto:[email protected] http://www.pacujo.nu/marko/
Hi Marko.
> PS Are /dev/null and /dev/zero also redundant?
I regularly use both...
1. Find a download that doesn't appear where one expected it...
find / -name "wanted-but-lost-download" 2> /dev/null
2. Create a loop-mounted partition to populate as a CD image before
burning the CD in question.
dd if=/dev/zero bs=1048576 count=750 of=/tmp/cd.img
mke2fs /tmp/cd.img
mount -o loop /tmp/cd.img /img/cd
3. Create a loop-mounted partition to populate as a floppy image.
dd if=/dev/zero bs=1024 count=1440 of=/tmp/floppy.img
mke2fs /tmp/floppy.img
mount -o loop /tmp/floppy.img /img/floppy
Neither has alternatives that make sense as far as I can see.
Best wishes from Riley.
On Wed, Oct 31, 2001 at 12:51:29AM +0000, you [Riley Williams] claimed:
> Hi Marko.
>
> > PS Are /dev/null and /dev/zero also redundant?
>
> I regularly use both...
>
> 1. Find a download that doesn't appear where one expected it...
>
> find / -name "wanted-but-lost-download" 2> /dev/null
>
> 2. Create a loop-mounted partition to populate as a CD image before
> burning the CD in question.
>
> dd if=/dev/zero bs=1048576 count=750 of=/tmp/cd.img
> mke2fs /tmp/cd.img
> mount -o loop /tmp/cd.img /img/cd
>
> 3. Create a loop-mounted partition to populate as a floppy image.
>
> dd if=/dev/zero bs=1024 count=1440 of=/tmp/floppy.img
> mke2fs /tmp/floppy.img
> mount -o loop /tmp/floppy.img /img/floppy
>
> Neither has alternatives that make sense as far as I can see.
Certainly have in the sense that you could theoretically do that in user
space.
find / -name "wanted-but-lost-download" | eat
zerofill | head -c 1440k > /tmp/floppy.img
ssh foo@bar | block
etc.
(Implementation of eat, block and zerofill is left as an exercise...)
-- v --
[email protected]
Hi Ville.
>>> PS Are /dev/null and /dev/zero also redundant?
>> I regularly use both...
>>
>> 1. Find a download that doesn't appear where one expected it...
>>
>> find / -name "wanted-but-lost-download" 2> /dev/null
>>
>> 2. Create a loop-mounted partition to populate as a CD image before
>> burning the CD in question.
>>
>> dd if=/dev/zero bs=1048576 count=750 of=/tmp/cd.img
>> mke2fs /tmp/cd.img
>> mount -o loop /tmp/cd.img /img/cd
>>
>> 3. Create a loop-mounted partition to populate as a floppy image.
>>
>> dd if=/dev/zero bs=1024 count=1440 of=/tmp/floppy.img
>> mke2fs /tmp/floppy.img
>> mount -o loop /tmp/floppy.img /img/floppy
>>
>> Neither has alternatives that make sense as far as I can see.
> Certainly have in the sense that you could theoretically do that in
> user space.
Are you sure?
> find / -name "wanted-but-lost-download" | eat
Doesn't work - you're piping the stdin there, not stderr as per my
example above. AFAIK, there's no way to pipe stderr without also piping
stdout, hence this sort of solution just doesn't work.
AFAICS, there is no sane alternative to /dev/null in userspace.
> zerofill | head -c 1440k > /tmp/floppy.img
How does zerofill know when to stop writing zeros out? After all, if it
doesn't write enough out for the head call, then it's no longer an
equivalent to /dev/zero, and it could easily be called with just about
ANY positive number of bytes, including an infinite number, as in...
zerofill | tr '\0' '@' > /dev/ttyS1
...which sends an infinite stream of 0x40 bytes to the serial port.
However...
zerofill 750M > /tmp/img.cd
zerofill 1440k > /tmp/img.floppy
...would be a reasonable userspace equivalent to examples (2) and (3)
respectively, so that certainly could be done in userspace.
> ssh foo@bar | block
Which of my examples is this an equivalent to? I don't recognise it.
> (Implementation of eat, block and zerofill is left as an
> exercise...)
I'll leave that to somebody with more unwanted time than I have...
Best wishes from Riley.
Riley Williams <[email protected]> writes:
> Are you sure?
>
> > find / -name "wanted-but-lost-download" | eat
>
> Doesn't work - you're piping the stdin there, not stderr as per my
> example above. AFAIK, there's no way to pipe stderr without also piping
> stdout, hence this sort of solution just doesn't work.
The Bourne shell is more perverse than you realize:
$ exec 3>&1; find / -name "wanted-but-lost-download" 2>&1 1>&3 3>&- | eat
[stolen from "Csh Programming Considered Harmful" by Tom Christiansen]
Horrible, but does work. ;)
> > zerofill | head -c 1440k > /tmp/floppy.img
>
> How does zerofill know when to stop writing zeros out?
Easy, it gets EPIPE on the write (or gets killed by SIGPIPE if it's
stupid).
> > ssh foo@bar | block
>
> Which of my examples is this an equivalent to? I don't recognise it.
None; he's referring to the /dev/block example that started the
thread.
I'm still happy to keep /dev/null and /dev/zero. ;)
-Doug
--
Let us cross over the river, and rest under the shade of the trees.
--T. J. Jackson, 1863
On Wed, Oct 31, 2001 at 11:13:22PM +0000, you [Riley Williams] claimed:
> Hi Ville.
>
>
> > Certainly have in the sense that you could theoretically do that in
> > user space.
>
> Are you sure?
In theory, yes.
> > find / -name "wanted-but-lost-download" | eat
>
> Doesn't work - you're piping the stdin there, not stderr as per my
> example above.
Sorry, I wasn't careful enough.
> AFAIK, there's no way to pipe stderr without also piping
> stdout, hence this sort of solution just doesn't work.
One could argue that is a fault of the shell - which again is a userland
thing.
If anything else fails, you could do
% touch y; rm -f x
% ls x y
ls: x: No such file or directory
y
% mkfifo f
% ls x y 2> f & wc -c f
y
33 f
rm f
Which of course isn't pretty, but it's doable. Of course, I'm not arguing
that we should get rid of /dev/null and /dev/zero, but that in theory you
could implement them in userspace.
Come to think of it, the biggest gain from /dev/null and /dev/zero comes
propably when you do memmaps. I'm not actually sure whether you could all
tath without /dev/null and /dev/zero - or you could, but with performance
loss.
> AFAICS, there is no sane alternative to /dev/null in userspace.
Sane is relative...
> > zerofill | head -c 1440k > /tmp/floppy.img
>
> How does zerofill know when to stop writing zeros out? After all, if it
> doesn't write enough out for the head call, then it's no longer an
> equivalent to /dev/zero, and it could easily be called with just about
> ANY positive number of bytes, including an infinite number, as in...
>
> zerofill | tr '\0' '@' > /dev/ttyS1
>
> ...which sends an infinite stream of 0x40 bytes to the serial port.
Of course it writes infinitely. When head terminates the pipe, it exits.
Just try
yes | head -c 10
Or with any characters. It gets SIGPIPE when the other end closes the pipe.
> However...
>
> zerofill 750M > /tmp/img.cd
> zerofill 1440k > /tmp/img.floppy
>
> ...would be a reasonable userspace equivalent to examples (2) and (3)
> respectively, so that certainly could be done in userspace.
That's equivalent to
zerofill | head -c 750M > /tmp/img.cd
Unless I missed something.
-- v --
[email protected]
On Wed, Oct 31, 2001 at 07:11:47PM -0500, you [Doug McNaught] claimed:
> Riley Williams <[email protected]> writes:
>
> The Bourne shell is more perverse than you realize:
>
> $ exec 3>&1; find / -name "wanted-but-lost-download" 2>&1 1>&3 3>&- | eat
>
> [stolen from "Csh Programming Considered Harmful" by Tom Christiansen]
Wow. I actually played a minute with zsh, but didn't find a way... I was
pretty sure, though, that it was doable.
> Horrible, but does work. ;)
>
> > > zerofill | head -c 1440k > /tmp/floppy.img
> >
> > How does zerofill know when to stop writing zeros out?
>
> Easy, it gets EPIPE on the write (or gets killed by SIGPIPE if it's
> stupid).
Stupid... Or lazy ;).
> > > ssh foo@bar | block
> >
> > Which of my examples is this an equivalent to? I don't recognise it.
>
> None; he's referring to the /dev/block example that started the
> thread.
Yep.
> I'm still happy to keep /dev/null and /dev/zero. ;)
So am I. Perhaps it is better to let this thread die...
-- v --
[email protected]
Doug McNaught wrote:
>
> Riley Williams <[email protected]> writes:
>
> > Are you sure?
> >
> > > find / -name "wanted-but-lost-download" | eat
> >
> > Doesn't work - you're piping the stdin there, not stderr as per my
> > example above. AFAIK, there's no way to pipe stderr without also piping
> > stdout, hence this sort of solution just doesn't work.
>
> The Bourne shell is more perverse than you realize:
>
> $ exec 3>&1; find / -name "wanted-but-lost-download" 2>&1 1>&3 3>&- | eat
>
> [stolen from "Csh Programming Considered Harmful" by Tom Christiansen]
>
> Horrible, but does work. ;)
$ find / -name "wanted-but-lost-download" 2>&1 1>&0 | eat
is simpler although dependent on stdin being a tty
--
Abramo Bagnara mailto:[email protected]
Opera Unica Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy
ALSA project http://www.alsa-project.org
It sounds good!
Hi Doug.
>> Are you sure?
>>> find / -name "wanted-but-lost-download" | eat
>> Doesn't work - you're piping the stdin there, not stderr as per my
>> example above. AFAIK, there's no way to pipe stderr without also
>> piping stdout, hence this sort of solution just doesn't work.
> The Bourne shell is more perverse than you realize:
>
> $ exec 3>&1; find / -name "wanted-but-lost-download" 2>&1 1>&3 3>&- | eat
>
> [stolen from "Csh Programming Considered Harmful" by Tom Christiansen]
>
> Horrible, but does work. ;)
Are you sure that works with BASH ? I've seen it listed (without the
`exec 3>&1;` at the beginning) as a CSH method for doing this, but I've
never had it work under bash, so presume the exec at the beginning is
needed for bash to be able to do this. Is that right?
Also, even if it's true, is that also true with all other possible
shells? Redirecting to /dev/null is independant of the shells, but
piping hacks like that aren't.
I'm not on bash at the moment, and don't have it available, but I'll try
it when I get home...
>>> zerofill | head -c 1440k > /tmp/floppy.img
>> How does zerofill know when to stop writing zeros out?
> Easy, it gets EPIPE on the write (or gets killed by SIGPIPE if it's
> stupid).
So it should be deliberately written to write them out in an infinite
loop? Makes a bizarre sort of sense, but not something I would ever do.
Also, as I've had pointed out to me, one sometimes needs to tell a
program to take input other than stdin from /dev/zero and that often
can't be done using pipes. The friend who pointed this out to me
recently had reason to do precicely this. The following isn't exactly
what he needed, but is similar...
Q> ebcdic2ascii < /dev/ttyS1 | tr A-Z a-z | bindiff /dev/zero /dev/stdin
...and I would be very interested in a shell script to duplicate that
using the `zerofill` program referred to above.
>>> ssh foo@bar | block
>> Which of my examples is this an equivalent to? I don't recognise it.
> None; he's referring to the /dev/block example that started the
> thread.
> I'm still happy to keep /dev/null and /dev/zero. ;)
So am I.
Best wishes from Riley.
On Thu, Nov 01, 2001 at 11:51:39PM +0000, you [Riley Williams] claimed:
(Piping only stderr to a program)
> Also, even if it's true, is that also true with all other possible
> shells?
I think the point is it can be made to work in userland, not that a
particular shell isn't able to do that. In fact, I'm a bit dissapointed
that shells such as zsh and bash seem to lack an easy way to do that. But
really, this is theoretical, I think nobody is really advocating getting rid
of /dev/null and /dev/zero.
> Redirecting to /dev/null is independant of the shells, but piping hacks
> like that aren't.
The way I see it piping is independent from shells just because it can be
accomplished in userland using the present linux system calls.
> So it should be deliberately written to write them out in an infinite
> loop? Makes a bizarre sort of sense, but not something I would ever do.
Why is that? I see nothing bizarre in that.
> Also, as I've had pointed out to me, one sometimes needs to tell a
> program to take input other than stdin from /dev/zero and that often
> can't be done using pipes. The friend who pointed this out to me
> recently had reason to do precicely this. The following isn't exactly
> what he needed, but is similar...
>
> Q> ebcdic2ascii < /dev/ttyS1 | tr A-Z a-z | bindiff /dev/zero /dev/stdin
Again, I think it can be done in userland. Some shells even give you
convenient syntax for that. This works in zsh:
head -2 <(yes) <(uname)
==> /proc/self/fd/11 <==
y
y
==> /proc/self/fd/12 <==
Linux
So you can pipe arbitrary program output as a filename argument.
I guess you example could be written as
ebcdic2ascii < /dev/ttyS1 | tr A-Z a-z | bindiff <(zerofill) /dev/stdin
but I'm not sure since I have no idea your example does ;) ;).
> > I'm still happy to keep /dev/null and /dev/zero. ;)
>
> So am I.
-- v --
[email protected]
On Thursday 01 November 2001 18:51, Riley Williams wrote:
> Hi Doug.
>
> >> Are you sure?
> >>
> >>> find / -name "wanted-but-lost-download" | eat
> >>
> >> Doesn't work - you're piping the stdin there, not stderr as per my
> >> example above. AFAIK, there's no way to pipe stderr without also
> >> piping stdout, hence this sort of solution just doesn't work.
> >
> > The Bourne shell is more perverse than you realize:
> >
> > $ exec 3>&1; find / -name "wanted-but-lost-download" 2>&1 1>&3 3>&- |
> > eat
> >
> > [stolen from "Csh Programming Considered Harmful" by Tom Christiansen]
> >
> > Horrible, but does work. ;)
You really do take the hard way. Try this to pipe just stderr:
command_that_outputs_on_1_and_2 2>/dev/stdout 1>/dev/null | eat
On Fri, Nov 02, 2001 at 04:04:13PM -0400, you [John Adams] claimed:
> > >
> > > $ exec 3>&1; find / -name "wanted-but-lost-download" 2>&1 1>&3 3>&- |
> > > eat
> > >
> > > [stolen from "Csh Programming Considered Harmful" by Tom Christiansen]
> > >
> > > Horrible, but does work. ;)
>
> You really do take the hard way. Try this to pipe just stderr:
> command_that_outputs_on_1_and_2 2>/dev/stdout 1>/dev/null | eat
Hmm.
The initial question was how to do
find / -name foo 2> /dev/null
or similar if /dev/null is not present. (Eat is a place holder for a
imaginary progrom acting as /dev/null replacement).
I guess
find / -name foo 2>/dev/stdout 1>/dev/stderr | eat
would (kinda) work, but it fails if you want to do
find / -name foo 2> /dev/null | less
Can be done with named pipes, though.
-- v --
[email protected]
I think that
find / -name foo 2>&-
should do the trick (under ksh, anyway, and
probably zsh or bash as well). Csh variants
IIRC don't have the concept of closing a
file descriptor...
tw
>>
>> The initial question was how to do
>>
>> find / -name foo 2> /dev/null
>>
>> or similar if /dev/null is not present. (Eat is a place holder for a
>> imaginary progrom acting as /dev/null replacement).
>>
>> I guess
>>
>> find / -name foo 2>/dev/stdout 1>/dev/stderr | eat
>>
>> would (kinda) work, but it fails if you want to do
>>
>> find / -name foo 2> /dev/null | less
>>
>> Can be done with named pipes, though.
>>
>>
>> -- v --
>>
>> [email protected]
>> -
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
End of included message
--
+--------------------------+------------------------------+
| Tim Walberg | [email protected] |
| 830 Carriage Dr. | http://www.concentric.net/~twalberg |
| Algonquin, IL 60102 | |
+--------------------------+------------------------------+
Tim Walberg <[email protected]> writes:
|> I think that
|>
|> find / -name foo 2>&-
|>
|> should do the trick (under ksh, anyway, and
|> probably zsh or bash as well).
This is different since the process now gets an error when trying to write
to fd 2, and a good implementation with check for errors.
Andreas.
--
Andreas Schwab "And now for something
[email protected] completely different."
SuSE Labs, SuSE GmbH, Schanz?ckerstr. 10, D-90443 N?rnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5