peter@ontmoh.UUCP (Peter Renzland) (05/15/89)
bph@buengc.BU.EDU (Blair P. Houghton) writes: > ... > I just can't seem to get sed(1) to print lines 110 through 115 of > a file. It seems the most basic of things, but sed(1) insists on > printing the whole file, no matter what I do... > > What is the proper one-liner syntax for that? sed -n 110,115p -- Peter Renzland @ Ontario Ministry of Health 416/964-9141 peter@ontmoh.UUCP
leo@philmds.UUCP (Leo de Wit) (05/18/89)
In article <611213677.29680@ontmoh.UUCP> peter@ontmoh.UUCP (Peter Renzland) writes: |bph@buengc.BU.EDU (Blair P. Houghton) writes: | |> ... |> I just can't seem to get sed(1) to print lines 110 through 115 of |> a file. It seems the most basic of things, but sed(1) insists on |> printing the whole file, no matter what I do... |> |> What is the proper one-liner syntax for that? | | sed -n 110,115p Make that sed -n -e 110,115p -e 115q and you even avoid reading the rest of the file. Leo.
dhesi@bsu-cs.bsu.edu (Rahul Dhesi) (05/19/89)
In article <1031@philmds.UUCP> leo@philmds.UUCP (Leo de Wit) writes: > sed -n -e 110,115p -e 115q > >and you even avoid reading the rest of the file. Careful! If sed was reading from a pipe, this will cause an EPIPE ("broken pipe") error. -- Rahul Dhesi <dhesi@bsu-cs.bsu.edu> UUCP: ...!{iuvax,pur-ee}!bsu-cs!dhesi
leo@philmds.UUCP (Leo de Wit) (05/19/89)
In article <7298@bsu-cs.bsu.edu> dhesi@bsu-cs.bsu.edu (Rahul Dhesi) writes: |In article <1031@philmds.UUCP> leo@philmds.UUCP (Leo de Wit) writes: |> sed -n -e 110,115p -e 115q |> |>and you even avoid reading the rest of the file. | |Careful! If sed was reading from a pipe, this will cause an EPIPE |("broken pipe") error. So what? I see SIGPIPE as a legitimate means to tell the input process: thank you, we don't need your service anymore. Are you implying that each filter should read all its input ?? Leo. P.S. /usr/new/csh in Ultrix seems overzealous in this respect to: try ls -la|head (on a fairly large directory).
dhesi@bsu-cs.bsu.edu (Rahul Dhesi) (05/20/89)
In article <1033@philmds.UUCP> leo@philmds.UUCP (Leo de Wit) writes: >Are you >implying that each filter should read all its input ?? Yes, unless it knows that a process providing that input is prepared to gracefully handle the situation when writing to stdout causes an error. From the user's point of view, % mypgm | myfilter ... output from myfilter ... mypgm: error writing to stdout: broken pipe % is not a friendly situation, because it makes it seem that something went wrong. Compare this with: % mypgm | myfilter ... output from myfilter ... % -- Rahul Dhesi <dhesi@bsu-cs.bsu.edu> UUCP: ...!{iuvax,pur-ee}!bsu-cs!dhesi
dhesi@bsu-cs.bsu.edu (Rahul Dhesi) (05/20/89)
In article <7320@bsu-cs.bsu.edu> I wrote: >>Are you >>implying that each filter should read all its input ?? > >Yes, unless it knows that a process providing that input is prepared to >gracefully handle the situation when writing to stdout causes an >error. Reconsidering this, I realize that the SIGPIPE that occurs when the process writes to a broken pipe ought to abort it silently. The user will not see the "broken pipe" message unless the process catches SIGPIPE and prints the message. Unfortunately, I have come across programs that do catch SIGPIPE and print an error message. Further, it's quite conceivable that a process that is writing to its standard output will (a) finish writing and then (b) do some cleanup. Unless such a process catches SIGPIPE, it will simply abort without cleaning up. So I still think that filters should read all their input. -- Rahul Dhesi <dhesi@bsu-cs.bsu.edu> UUCP: ...!{iuvax,pur-ee}!bsu-cs!dhesi
leo@philmds.UUCP (Leo de Wit) (05/22/89)
In article <7320@bsu-cs.bsu.edu> dhesi@bsu-cs.bsu.edu (Rahul Dhesi) writes: |In article <1033@philmds.UUCP> leo@philmds.UUCP (Leo de Wit) writes: |>Are you |>implying that each filter should read all its input ?? | |Yes, unless it knows that a process providing that input is prepared to |gracefully handle the situation when writing to stdout causes an |error. From the user's point of view, | | % mypgm | myfilter | ... output from myfilter ... | mypgm: error writing to stdout: broken pipe | % | |is not a friendly situation, because it makes it seem that something |went wrong. Compare this with: | | % mypgm | myfilter | ... output from myfilter ... | % Unless mypgm catches SIGPIPE and tries to be clever about writing to stdout, the first situation will not occur. Note that the default setting for SIGPIPE will cause that process to be terminated. I would call a program that did mypgm: error writing to stdout: broken pipe broken, or at least unable to treat this gracefully. The problem is in the input filter, not in the output filter that decides it has read enough. The correct treatment of SIGPIPE is to cleanup, then exit. Since many simple filters even don't need to cleanup (e.g. remove tmp files), they don't bother to catch the signal; the default action is sufficient. B.T.W Try mypgm | more , then hit 'q' at the first --More-- prompt. Are you going to complain about more getting its I/O wrong when you get mypgm: error writing to stdout: broken pipe ? Leo.
rbj@dsys.icst.nbs.gov (Root Boy Jim) (05/23/89)
? From: Rahul Dhesi <dhesi@bsu-cs.bsu.edu>
? In article <7320@bsu-cs.bsu.edu> I wrote:
? >>Are you
? >>implying that each filter should read all its input ??
? >
? >Yes, unless it knows that a process providing that input is prepared to
? >gracefully handle the situation when writing to stdout causes an
? >error.
[stuff deleted]
? So I still think that filters should read all their input.
Me too! I'm still waiting for `yes | <whatever>' to finish :-)
And of course I would expect `more' (and myself) to wait patiently for
cat /x11r3.tar/core.src/core.tar.Z.a? | zcat | tar tvf - | more
to complete when I typed `q'.
By now, we've all seen so many Broken Pipes that most of us don't
even see them anymore. If a program that is producing data really
needs to clean up after itself, it simply must catch SIGPIPES. Any
other behavior is sloppy coding.
? Rahul Dhesi <dhesi@bsu-cs.bsu.edu>
? UUCP: ...!{iuvax,pur-ee}!bsu-cs!dhesi
Root Boy Jim is what I am
Are you what you are or what?yakker@ucrmath.UCR.EDU (matt robinson) (11/10/89)
In article 20515 yahoo@unix.cis.pitt.edu (Kenneth L Moore) writes: >In article 9 chuckb@lotex.UUCP (Chuck Bentley) writes: >==>In article <20486@unix.cis.pitt.edu==> yahoo@unix.cis.pitt.edu >==>(Kenneth L Moore) writes: > >==>RTFM. Try reading _something_ relating to UNIX before posting. >==>Also, do you >==>have any idea how much bandwidth your signature uses? >==> >==> Chuck... ..!moray!lotex!chuckb >What does RTFM mean? Read The F***ing Manual. It's a figure of speech one of our old systems administrators used to give to C.S. students asking dumb quick questions. ---------------------------------------*-------------------------------------- "Behold, God, is my salvation, I | Internet: yakker@ucrmath.ucr.edu will trust, and not be afraid.." |+| UUCP: ...ucsd!ucrmath!yakker |+|+| "What lies behind you and what lies |+|+| The University of California before you pales insignificant when |+| at Riverside compared to what lies within you.." | Department of Computer Science ---------------------------------------*--------------------------------------