maart@cs.vu.nl (Maarten Litmaath) (09/19/88)
If one wants to run a command with output getting discarded, the obvious
solution is:
command > /dev/null
But what would you do if you happened to have no such device? :-)
Is the intended still possible?
Yes! (Better use the Bourne shell.)
command 1< /etc/passwd 2<&1
:-)
--
Alles klar, |Maarten Litmaath @ Free U Amsterdam:
Herr Kommissar? |maart@cs.vu.nl, mcvax!botter!maartroberto@cwi.nl (Rob ten Kroode) (09/19/88)
In article <1414@star.cs.vu.nl> maart@cs.vu.nl (Maarten Litmaath) writes: #If one wants to run a command with output getting discarded, the obvious #solution is: # # command > /dev/null # #But what would you do if you happened to have no such device? :-) This is impossible, you need the bitbucket for byte allocation, remember? #-- # Alles klar, |Maarten Litmaath @ Free U Amsterdam: # Herr Kommissar? |maart@cs.vu.nl, mcvax!botter!maart Jawohl! -- | The two rules of Rob: Rob ten Kroode (roberto@cwi.nl) | rule #1 : I am _always_ right. | rule #2 : If I am not right, apply rule #1. "I'm your icecream man; stop me when I'm passin' by..." Van Halen
leo@philmds.UUCP (Leo de Wit) (09/20/88)
In article <1414@star.cs.vu.nl> maart@cs.vu.nl (Maarten Litmaath) writes: >If one wants to run a command with output getting discarded, the obvious >solution is: > > command > /dev/null > >But what would you do if you happened to have no such device? :-) >Is the intended still possible? > >Yes! (Better use the Bourne shell.) > > > command 1< /etc/passwd 2<&1 > >:-) Maybe I'm missing something here, but this redirection also screws up your input (is that the joke perhaps 8-). Try cat for command. After the first line has been typed (from your terminal), the command finishes. But if you run the Bourne shell, you can also do something like: command >&- or command 2>&- which closes the standard output, resp. the standard error for 'command'. Or you can even do exec >&- 2>&- and don't have to worry about output anymore ;-) ! This one's nice too: exec <&- And now I give back the pipe to Maarten (a Dutch phrase that sounds like redirection 8-). Leo.
dhesi@bsu-cs.UUCP (Rahul Dhesi) (09/20/88)
># command > /dev/null ># >#But what would you do if you happened to have no such device? :-) My Microport System V/AT once lost /dev/null. I began seeing strange diagnostics from some programs and it took me while to figure out what was happening. A thorough check in the manual revealed no information about the major/minor device number for /dev/null so I couldn't use mknod to re-create it. I finally restored /dev/null from a backup disk. Now how's that for an ironical situation? I had never before realized how important it is to keep a safe backup copy of /dev/null. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi
gwyn@smoke.ARPA (Doug Gwyn ) (09/21/88)
In article <811@philmds.UUCP> leo@philmds.UUCP (Leo de Wit) writes: >> command > /dev/null > command >&- But that is not equivalent. In particular, an error will occur when output is attempted to fd#1.
ron@topaz.rutgers.edu (Ron Natalie) (09/22/88)
When BRL brought up 4.3 the first time, we bootstrapped it off the running 4.2 rather than loading in the tape from scratch. The system came up, printed all the configuration information, but rather than giving the shell prompt it just seemed to go into a loop. Stopping the machine and booting off the 4.2 disk yielded the answer to the problem. I forgot to make the /dev nodes. There was a regular file called "console" that had so intersting stuff in it from init bletching. -Ron
ron@topaz.rutgers.edu (Ron Natalie) (09/22/88)
Better to load /dev/null from a back up disk than to do what one of the Unipress people did. They got the minor number wrong and used the one for /dev/mem. It's amazing what happens when programs that aren't expecting any input suddenly get some (especially binary stuff like /dev/mem). -Ron
leo@philmds.UUCP (Leo de Wit) (09/22/88)
In article <8541@smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >In article <811@philmds.UUCP> leo@philmds.UUCP (Leo de Wit) writes: >>> command > /dev/null >> command >&- > >But that is not equivalent. In particular, an error will occur when >output is attempted to fd#1. Yes, that would be the result to be expected, wouldn't it? The file descriptor is closed, and cannot be accessed anymore. However, it seems like the shell is doing something like redirecting to a /dev/null device (who can comment on that one?), since the following program behaved OK (look Ma, no core!): ----------------- s t a r t s h e r e ----------------- /* iotest */ #include <stdio.h> main() { int i; for (i = 0; i < 3; i++) { printf("stdout: %d\n",i); fflush(stdout); fprintf(stderr,"stderr: %d\n",i); fflush(stderr); /* not really needed */ } } ----------------- e n d s h e r e ----------------- $ iotest stdout: 0 stderr: 0 stdout: 1 stderr: 1 stdout: 2 stderr: 2 $ iotest >&- stderr: 0 stderr: 1 stderr: 2 $ iotest 2>&- stdout: 0 stdout: 1 stdout: 2 $ iotest >&- 2>&- $ So to me it seems possible after all... Leo.
aegl@root.co.uk (Tony Luck) (09/22/88)
In article <1414@star.cs.vu.nl> maart@cs.vu.nl (Maarten Litmaath) writes: >If one wants to run a command with output getting discarded, the obvious >solution is: > > command > /dev/null > >But what would you do if you happened to have no such device? :-) >Is the intended still possible? > >Yes! (Better use the Bourne shell.) > > > command 1< /etc/passwd 2<&1 > >:-) This won't work with a well written 'command' as file descriptors 1 and 2 will be open for *reading* not for *writing*. And we all know how careful programs are to check that their writes succeed ... main() { printf("Hello, world\n"); } Oh well perhaps there might be one or two utilities that don't check :-( -Tony Luck (UniSoft Ltd.) <aegl@root.co.uk>
merlyn@intelob.intel.com (Randal L. Schwartz @ Stonehenge) (09/23/88)
In article <813@philmds.UUCP>, leo@philmds (Leo de Wit) writes: | Yes, that would be the result to be expected, wouldn't it? The file | descriptor is closed, and cannot be accessed anymore. However, it seems | like the shell is doing something like redirecting to a /dev/null | device (who can comment on that one?), since the following program | behaved OK (look Ma, no core!): | [program deleted...] I am amazed that people think that any program that doesn't dump core is behaving OK, and vice versa. The shell is *closing* the file descriptors in question. The write calls in your program are getting errors, but you are ignoring them. (Try accessing the value of errno to see the difference.) If you don't try to dump core on purpose because of your bad error return, your program will go merrily on its way. Some better-designed programs, however, *will* notice the difference between a closed file-descriptor and a file descriptor pointing at "/dev/null", and not be happy. Be C-ing you... -- Randal L. Schwartz, Stonehenge Consulting Services (503)777-0095 on contract to BiiN Technical Information Services (for now :-), in a former Intel building in Hillsboro, Oregon, USA <merlyn@intelob.intel.com> or ...!tektronix!inteloa[!intelob]!merlyn Standard disclaimer: I *am* my employer!
levy@ttrdc.UUCP (Daniel R. Levy) (09/23/88)
In article <Sep.21.15.24.00.1988.4097@topaz.rutgers.edu>, ron@topaz.rutgers.edu (Ron Natalie) writes: < Better to load /dev/null from a back up disk than to do what one of < the Unipress people did. They got the minor number wrong and used < the one for /dev/mem. It's amazing what happens when programs that < aren't expecting any input suddenly get some (especially binary stuff < like /dev/mem). Not to mention programs which dump unwanted output TO /dev/null (thus, with the above mistake, scribbling over low memory, which usually contains the kernel... OUCH). -- |------------Dan Levy------------| THE OPINIONS EXPRESSED HEREIN ARE MINE ONLY | Bell Labs Area 61 (R.I.P., TTY)| AND ARE NOT TO BE IMPUTED TO AT&T. | Skokie, Illinois | |-----Path: att!ttbcad!levy-----|
damm@freja.dk (Kristian Damm Jensen) (09/26/88)
maart@cs.vu.nl (Maarten Litmaath) writes: >If one wants to run a command with output getting discarded, the obvious >solution is: > command > /dev/null Poor guy! On this machine we've got a user named null! He just had the bad luck to be christened Niels Ull.
sean@cadre.dsl.PITTSBURGH.EDU (Sean McLinden) (09/28/88)
In article <4092@freja.dk> damm@freja.dk (Kristian Damm Jensen) writes: >maart@cs.vu.nl (Maarten Litmaath) writes: > >>If one wants to run a command with output getting discarded, the obvious >>solution is: > >> command > /dev/null > >Poor guy! On this machine we've got a user named null! He just had the bad >luck to be christened Niels Ull. He'd be worse off if his SysOP put his home directory in "/dev".
maart@cs.vu.nl (Maarten Litmaath) (09/28/88)
In article <4092@freja.dk> damm@freja.dk (Kristian Damm Jensen) writes:
\Poor guy! On this machine we've got a user named null! He just had the bad
\luck to be christened Niels Ull.
Aha! So you gave him /dev/null for a home directory!
--
Alles klar, |Maarten Litmaath @ Free U Amsterdam:
Herr Kommissar? |maart@cs.vu.nl, mcvax!botter!maartchet@pirate.CWRU.EDU (Chet Ramey) (09/29/88)
In article <4092@freja.dk> damm@freja.dk (Kristian Damm Jensen) writes: >maart@cs.vu.nl (Maarten Litmaath) writes: > >>If one wants to run a command with output getting discarded, the obvious >>solution is: >> command > /dev/null >Poor guy! On this machine we've got a user named null! He just had the bad >luck to be christened Niels Ull. The guy that runs the Computer Science department machines here is named Dev (he's Indian). Many's the time we've talked about surprising him with a new home directory (/dev/garg). We have to get these two together... Chet | Chet Ramey chet@cwjcc.CWRU.EDU chet@alpha.CES.CWRU.EDU | | Just another jerk takin' pride in his work...