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>
pdc@otter.hple.hp.com (Damian Cugley) (09/22/88)
/ otter:comp.unix.questions / dean@usceast.UUCP (Dean Karres) / 7:25 pm Sep 21, 1988 / > Ok, this isn't really a "Unix joke" but I am curious... Under Data > General's AOS and AOS/VS operating systems (pre rev 7, my DG knowledge > stops before then) a user could type `xyzzy' and get the response > `Nothing happens'. > Now for my question, does this happen under the Unix environment(s)? Well, occasionally I have it set up to `cd project-directory' for me (but often since I started using window systems). pdc
gwyn@smoke.ARPA (Doug Gwyn ) (09/23/88)
In article <813@philmds.UUCP>, leo@philmds.UUCP (Leo de Wit) writes: - 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!): The program did NOT behave okay. However, since you did not test your printf/fprintf return status, you didn't discover that. More carefully written applications would FAIL when writing to a closed file descriptor. The Bourne shell closes the file descriptor for >&- etc.
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!
nat@bales.UUCP (Nathaniel Stitt) (09/23/88)
Re: How to simulate "command > /dev/null" without a /dev/null. How about: command | grep i_hope_this_does_not_appear_in_the_output -- Nathaniel Stitt | This life is a test. It is only a test. Had Guidelines Software, Inc. | this been an actual life, you would have received ucbvax!ucbcad!z!nat | further instructions as to what to do and where (415) 376-1395 | to go.
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-----|
anw@nott-cs.UUCP (09/23/88)
In article <1414@star.cs.vu.nl> maart@cs.vu.nl (Maarten Litmaath) writes: > [ how to simulate ] > command > /dev/null > [ without using /dev/null ? ] Silly season strikes again? But there are many near-solutions: command | grep -v '' # or adjust flags as necessary command | tail -0 # or use sed or awk or ... command | tr -cds '' command | [ ] command | # if at end of script each of which is deficient in ways I'll leave others to find and correct. -- Andy Walker, Maths Dept., Nott'm Univ., UK. anw@maths.nott.ac.uk
debra@alice.UUCP (Paul De Bra) (09/24/88)
In article <192@bales.UUCP> nat@bales.UUCP (Nathaniel Stitt) writes: >Re: How to simulate "command > /dev/null" without a /dev/null. > >How about: > > command | grep i_hope_this_does_not_appear_in_the_output > Try this for the command "cat" with your message as input. Doesn't work, right? :-) Won't work with this reply either.
ark@alice.UUCP (Andrew Koenig) (09/24/88)
In article <8236@alice.UUCP>, debra@alice.UUCP (Paul De Bra) writes: >In article <192@bales.UUCP> nat@bales.UUCP (Nathaniel Stitt) writes: >>Re: How to simulate "command > /dev/null" without a /dev/null. >> >>How about: >> >> command | grep i_hope_this_does_not_appear_in_the_output >> >Try this for the command "cat" with your message as input. >Doesn't work, right? :-) > >Won't work with this reply either. > How about this one? command | grep -v '^' -- --Andrew Koenig ark@europa.att.com
kyriazis@rpics (George Kyriazis) (09/24/88)
In article <192@bales.UUCP> nat@bales.UUCP (Nathaniel Stitt) writes: >Re: How to simulate "command > /dev/null" without a /dev/null. > >How about: > > command | grep i_hope_this_does_not_appear_in_the_output > Hmm.. What about command | vax or even better command | make -s with an appropriate null Makefile... George Kyriazis kyriazis@turing.cs.rpi.edu ------------------------------
gwyn@smoke.ARPA (Doug Gwyn ) (09/24/88)
In article <1247@imagine.PAWL.RPI.EDU> kyriazis@turing.cs.rpi.edu (George Kyriazis) writes: > command | vax No, the pipe will constipate since the "vax" command (equivalent to :) does not read its input.
ron@topaz.rutgers.edu (Ron Natalie) (09/24/88)
I managed to destroy the password file on an earlier version of unix by closing down file descriptor 1 before executing it. What happens is that the password file is opened and since 1 is the lowest unused file descriptor, it gets used. The program then does something to stdout and plouie. Most setuid programs these days are carefull to avoid people playing around like that. -Ron This blasted PS2 is ruining me for real keyboards.
eirik@tekcrl.TEK.COM (Eirik Fuller) (09/24/88)
In article <192@bales.UUCP> nat@bales.UUCP (Nathaniel Stitt) writes: > How about: > > command | grep i_hope_this_does_not_appear_in_the_output Sorry, I prefer command | grep -v '^'
jim@fsc2086.UUCP (Jim O'Connor) (09/25/88)
In article <192@bales.UUCP>, nat@bales.UUCP (Nathaniel Stitt) writes: > Re: How to simulate "command > /dev/null" without a /dev/null. > > How about: > > command | grep i_hope_this_does_not_appear_in_the_output > If you've got lex, you don't have to hope. Just build a program using the lex instructions: %% \n | .* ; %% which if I recall from my manual, should not print anything. (i.e. all input is matched and discarded). Now that I think about it. This is probably more effiecient #include <stdio.h> main() { while (getchar() != EOF) ; } --- James B. O'Connor +1 615 821 4090 x651 Filtration Sciences Corp. UUCP: uunet!fsc2086!jim 105 West 45th Street or jim@fsc2086.UUCP Chattanooga, TN 37411
jfh@rpp386.Dallas.TX.US (The Beach Bum) (09/26/88)
In article <8572@smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >In article <1247@imagine.PAWL.RPI.EDU> kyriazis@turing.cs.rpi.edu (George Kyriazis) writes: >> command | vax > >No, the pipe will constipate since the "vax" command (equivalent to :) >does not read its input. No, the command will abort with SIGPIPE. the vax command will exit, leaving no reader on the pipe. the first time command goes to write to its stdout, a SIGPIPE will result. (one may presume command will eventually write, otherwise what was there to send to /dev/null?) -- John F. Haugh II (jfh@rpp386.Dallas.TX.US) HASA, "S" Division "Why waste negative entropy on comments, when you could use the same entropy to create bugs instead?" -- Steve Elias
kyriazis@rpics (George Kyriazis) (09/26/88)
In article <7104@rpp386.Dallas.TX.US> jfh@rpp386.Dallas.TX.US (The Beach Bum) writes: >In article <8572@smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >>In article <1247@imagine.PAWL.RPI.EDU> kyriazis@turing.cs.rpi.edu (George Kyriazis) writes: >>> command | vax >> >>No, the pipe will constipate since the "vax" command (equivalent to :) >>does not read its input. > >No, the command will abort with SIGPIPE. the vax command will exit, >leaving no reader on the pipe. the first time command goes to write >to its stdout, a SIGPIPE will result... I tried that command with 'ls' like 'ls | vax' and it worked; it gave no output. Nor it gave any error. George Kyriazis kyriazis@turing.cs.rpi.edu ------------------------------
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.
peter@ficc.uu.net (Peter da Silva) (09/28/88)
command | sed '1,$d' Someone suggested command | make -s I suspect this would terminate you with an EPIPE. For a more exciting life try: command | true command | false command | rm -rf / -- Peter da Silva `-_-' Ferranti International Controls Corporation. "Have you hugged U your wolf today?" peter@ficc.uu.net
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".
map@raphel.UUCP (Mike Pearce) (09/28/88)
I have used to following alias file as a joke on some people around here. It gives even less unix functionality for the ksh novice. # alias unalias="/bin/echo - >/dev/null" alias type="/bin/echo - >/dev/null" alias ls="cd /tmp; /bin/ls" alias cd="/bin/echo - >/dev/null" alias pwd="/bin/echo \/tmp" alias kill="/bin/echo - >/dev/null" alias ps="sleep 5000;echo - >/dev/null" alias alias="/bin/echo \"chmod=/bin/chmod echo=print - false=let 0 hash=alias -t history=fc -l integer=typeset -i ls=/bin/ls mv=/bin/mv pwd=print - \"$\"PWD r=fc -e - true=let 1 type=whence -v vi=/usr/bin/vi\"" # Mike Pearce att!ctsmain!raphel!map
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...
greywolf@unisoft.UUCP (The Grey Wolf) (09/29/88)
In article <7104@rpp386.Dallas.TX.US> jfh@rpp386.Dallas.TX.US (The Beach Bum) writes: # In article <8572@smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: # >In article <1247@imagine.PAWL.RPI.EDU> kyriazis@turing.cs.rpi.edu (George Kyriazis) writes: # >> command | vax # > # >No, the pipe will constipate since the "vax" command (equivalent to :) # >does not read its input. # # No, the command will abort with SIGPIPE. the vax command will exit, # leaving no reader on the pipe. the first time command goes to write # to its stdout, a SIGPIPE will result. (one may presume command will # eventually write, otherwise what was there to send to /dev/null?) Funny, I don't have any problems with piping something like cat /etc/passwd | /bin/true... no errors, no bad status, no nothing. except for one extra newline, if that counts... # -- # John F. Haugh II (jfh@rpp386.Dallas.TX.US) HASA, "S" Division # # "Why waste negative entropy on comments, when you could use the same # entropy to create bugs instead?" -- Steve Elias -- " "Does anyone have a spare 40 Gig board for my mind?" Roan Anderson, Software Engineer^H^H^H^H^H^H^H^HRejiggerer, UniSoft Corp. Emeryville, CA (415) 420-6400 /* the above views are not company policy, they are my opinions */
gwyn@smoke.ARPA (Doug Gwyn ) (10/03/88)
In article <7104@rpp386.Dallas.TX.US> jfh@rpp386.Dallas.TX.US (The Beach Bum) writes: -In article <8572@smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: ->In article <1247@imagine.PAWL.RPI.EDU> kyriazis@turing.cs.rpi.edu (George Kyriazis) writes: ->> command | vax ->No, the pipe will constipate since the "vax" command (equivalent to :) ->does not read its input. -No, the command will abort with SIGPIPE. Oops, exactly what happens depends on the relative process speeds but indeed SIGPIPE is the eventual outcome some time after constipation.