Re: pipes (a response to a VERY SMALL part of: Re: 4-year Pr…

Top Page
Attachments:
Message as email
+ (text/plain)
+ (text/html)
+ (text/plain)
Delete this message
Reply to this message
Author: David Schwartz via PLUG-discuss
Date:  
To: Main PLUG discussion list
CC: David Schwartz
Subject: Re: pipes (a response to a VERY SMALL part of: Re: 4-year Programing and Analytics degree from Mesa CC)
Hi, Rusty.

Yes, I know about tee, but those pipes really only allow one flow.

I’ve used tee to save off a snapshot of the data at different points of the process, but then you have to come back later and run another pipeline to process each one separately.

I learned all of this stuff at Moto working on a Unix System V Rel III port to the 68020, and I was quite amazed that all of the commands in a pipe ran in parallel. I could run the pipe in a bg process (with <ctrl>-Z) and then run top and see all of the commands in the pipe running simultaneously.

When you do that in Windows, they’re totally synchronous: it’s like running one command after another in a batch file, saving the results of one to a temp file before passing it as input to the next command.

Running ‘man tee’ in a Mac shell says you can just send the output to a file. It’s dated 1993, so clearly it hasn’t been updated in 30 years.

It would be nice to be able to run a command from a tee that implements a separate pipeline, no?

-David Schwartz



> On Dec 25, 2022, at 1:45 PM, Rusty Carruth via PLUG-discuss <> wrote:
>
> Hi, David!
>
> I'd like to respond to a single thought in your entire message. The message was interesting, but I'm only going to tackle this one thing:
>
> On 12/25/22 00:20, David Schwartz via PLUG-discuss wrote:
>> We saw it first employed in Unix systems with the command shell that lets you create “pipes” by connecting various commands together. The command shell implements a fairly simple language that’s hard to say is either imperative or declarative. Some would argue it’s more of a functional language.
>>
>> But you can see more contemporary evolutions of this approach in Zapier and IFTTT.
>>
>> The problem with this linear “pipeline” approach is that you have to have some way to divert feeds off of the main data stream to drive displays, and that’s not something we see implemented much. Usually the end of a Zapier “zap” goes into some kind of rendering widget, or a spreadsheet or DB.
>>
>> Anybody who’s tried to use a single Unix pipe command to display multiple views of the data going through it knows this is one of it’s major weaknesses.
>
> Well, yes, but I've used 'tee' to great effect here to grab off parts of the flow of a pipe for later use. So you can grab views of the data as it flows, but yes I'll agree command pipelines don't make it trivial.
>
>
> Well, since I'm sending a message, I'll add "Merry Christmas to all, and to all a good night!" ;-)
>
> ---------------------------------------------------
> PLUG-discuss mailing list:
> To subscribe, unsubscribe, or to change your mail settings:
> https://lists.phxlinux.org/mailman/listinfo/plug-discuss


---------------------------------------------------
PLUG-discuss mailing list:
To subscribe, unsubscribe, or to change your mail settings:
https://lists.phxlinux.org/mailman/listinfo/plug-discuss