Path: csiph.com!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: iso646.h Date: Thu, 01 Feb 2024 05:17:34 -0800 Organization: A noiseless patient Spider Lines: 56 Message-ID: <86sf2c9vdd.fsf@linuxsc.com> References: <87jznu1c4v.fsf@nosuchdomain.example.com> <86zfwnc34o.fsf@linuxsc.com> <86il3bb7rb.fsf@linuxsc.com> <865xzaas3m.fsf@linuxsc.com> <20240131124332.00002c05@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: dont-email.me; posting-host="e0e985b0c186ff2246e59878011e515e"; logging-data="2198413"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX199Ms7kEd4zYo6QsfQl1w5hjgum1O0aL74=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:av9UHxDUCFBtuDaR82ssFhuoP90= sha1:riGZb9hfVdEOJ0Nzpc9GqMXTJBc= Xref: csiph.com comp.lang.c:381455 Michael S writes: > On Tue, 30 Jan 2024 23:18:21 -0800 > Tim Rentsch wrote: [..on sending binary to standard out..] >> Simple example (disclaimer: not tested): >> >> ssh foo 'cd blah ; tar -cf - . | gzip -c' | \ >> (mkdir foo.blah ; cd foo.blah ; gunzip -c | tar -xf -) >> >> Of the five main programs in this command, four are using >> standard out to send binary data: >> >> tar -cf - . >> gzip -c >> ssh foo [...] >> gunzip -c >> >> The tar -xf - at the end reads binary data on standard in >> but doesn't output any (or anything else for that matter). >> >> It is FAR more cumbersome to accomplish what this command >> is doing without sending binary data through standard out. > > If I am not mistaken, tar, gzip and gunzip do not write binary > data to standard output by default. [...] What I think you mean is that these programs don't send their primary processing output to standard out unless specifically directed to do so. Well sure. I don't think that takes away from the point that it is useful to use standard out for a binary output stream. >> Anyone who doesn't understand this doesn't understand Unix. > > Frankly, Unix redirection racket looks like something hacked > together rather than designed as result of the solid thinking > process. As long as there were only standard input and output it > was sort of logical. But when they figured out that it is > insufficient, they had chosen a quick hack instead of > constructing a solution that wouldn't offend engineering senses > of any non-preconditioned observer. First I think you are being too harsh on the people who originally came up the pipe/redirection mechanism. Considering the historical context it was a big step forward, and a good match to available processing resources at the time. That said, no one is claiming that the single pipe/redirection mechanism is the be-all and end-all, or that it solves all the world's problems. But it does do a good job of solving a significant subclass of the world's problems, and in that context provides a good motivating example for using standard out for binary data as well as textual data.