Extreme Piping™ syntax

[Frozenfire92]

My initial thought was

sourceCmd ||| cmd1 | cmd2 | cmd3 ||| destinationCmd

the output from sourceCmd would be the input of cmd1, cmd2, cmd3 the output from cmd1 would be argv[1] of destinationCmd the output from cmd2 would be argv[2] of destinationCmd the output from cmd3 would be argv[3] of destinationCmd

[DylanYoung]

Mine too On Oct 21, 2014 4:44 PM, "Joel Kuntz" notifications@github.com wrote:

My initial thought was

sourceCmd ||| cmd1 | cmd2 | cmd3 ||| destinationCmd

the output from sourceCmd would be the input of cmd1, cmd2, cmd3 the output from cmd1 would be argv[1] of destinationCmd the output from cmd2 would be argv[2] of destinationCmd the output from cmd3 would be argv[3] of destinationCmd

— Reply to this email directly or view it on GitHub https://github.com/Glavin001/MrShell/issues/4#issuecomment-59986520.

[Glavin001]

Could we have a more concrete example?

[Glavin001]

Here's how we can create our C worker queue threads.

http://stackoverflow.com/questions/2156353/how-do-you-query-a-pthread-to-see-if-it-is-still-running

[Glavin001]

We can use pthread_create and pass it a struct that has multiple arguments: http://stackoverflow.com/questions/1352749/multiple-arguments-to-function-called-by-pthread-create

[Glavin001]

It would be much better if our extreme piping delimiters were both different, and the start != end delimiter. This would enable nested parallel piping.

For instance:

sourceCmd ||| cmd1 | cmd2 | cmd3 ||| destinationCmd
``

Would become:

```bash
sourceCmd <|| cmd1 | cmd2 | cmd3 ||> destinationCmd

Such that the following would work:

sourceCmd <|| cmd1 | <|| cmd2 | cmd 3 ||> | cmd3 ||> destinationCmd

<|| and ||> are just examples. It will be a simple thing to change it later.

[Glavin001]

Helpful links:

• Grabbing output from exec
• C Read stdout from multiple exec called from fork

[Glavin001]

We should implement this recursively, and such that tasks that can be in parallel are in executed in their own processes.

Take the sample above:

sourceCmd <|| cmd1 | cmd2 <|| cmd3 | cmd4 ||> | cmd5 ||> destinationCmd

Assuming the | in this case does not represent the usage pipe and is instead a separator for the sub-task commands.

Recursively

We should initially break it down into, sourceCmd which is piped into 3 tasks, [cmd1, cmd2 <|| cmd3 | cmd 4 ||>, cmd5]. When piped into the second task, cmd2 <|| cmd3 | cmd4 ||>, another multi-pipe is recognized and so the result of cmd2 is piped into both cmd3 and cmd4. Et cetera, recursively, left-side-first / top-down parser fashion.

Parallelism

Furthermore, the sub-task commands can be executed in parallel! By recursively passing the nested command line down through each task, and using wait(), we can develop this Shell with a synchronous code flow. A parent (mrsh) can have children (sub-tasks such as cmd1 or cmd1, cmd2 <|| cmd3 | cmd4 ||>) and it's children can have children (sub-tasks such as cmd 3 | cmd4). The result will bubble up to the top and feed into the top-level tasks that require that input.

Types of Pipes

• | (Single pipe) - Synchronous, 1-1 piping. ls | grep, where ls feeds input into grep directly and synchronously.
• || (OR operator) - This is a logical OR operator.
• <|| / ||> (extreme pipe!) - Takes in single input and pipes to multiple sub-tasks that can have their own sub-tasks, and so forth. This is parallelized! Using multiple processes.

Note: For obvious reasons, | cannot be our separator for the extreme piping syntax. Also, we can change <|| and ||> to whatever; I strongly recommend that we have distinct start and end identifiers for this syntax and I am sure you will agree.

Thoughts on the above? :smile:

[Frozenfire92]

After examination I agree with all of the proposed features. The recursive approach allows for some interesting commands. The single bar problem could be easily fixed. What do guys you like out of these?

sourceCmd <|| cmd1 # cmd2 <|| cmd3 # cmd4 ||> # cmd5 ||> destinationCmd
sourceCmd <|| cmd1 % cmd2 <|| cmd3 % cmd4 ||> % cmd5 ||> destinationCmd
sourceCmd <|| cmd1 $ cmd2 <|| cmd3 $ cmd4 ||> $ cmd5 ||> destinationCmd
sourceCmd <|| cmd1 * cmd2 <|| cmd3 * cmd4 ||> * cmd5 ||> destinationCmd
sourceCmd <|| cmd1 + cmd2 <|| cmd3 + cmd4 ||> + cmd5 ||> destinationCmd
sourceCmd <|| cmd1 . cmd2 <|| cmd3 . cmd4 ||> . cmd5 ||> destinationCmd

For the extreme pipe I was thinking of these

source <] cmd1 # cmd2 [> destination
source <} cmd1 # cmd2 {> destination
source <) cmd1 # cmd2 (> destination
source <)) cmd1 # cmd2 ((> destination
source <<] cmd1 # cmd2 [>> destination
source <:: cmd1 # cmd2 ::> destination

[Glavin001]

Extreme Pipe Separate - Single Bar Replacement

I'd like to keep the syntax close to bash for the basics, so conversion from Bash to MrShell is straightforward and simply provides an additional Extreme Piping feature. With that in mind, here are my current thoughts:

• I think # is a comment.
• $ is a variable (in usage, not when setting)
• . will recognize
• the reset are mathematical operators

What about using :: (double :) as separator?

Extreme Pipe

I like using the < and > characters coupled with either : or {/}, as this both looks nice and more important the user is already holding shift for < and can continue to hold shift and press the nearby buttons : or { with the same hand / fingers. For that matter, : is even better because it is inline with how most (proper) typists for QWERTY type, so they can therefore type it quickly! I really like the <:: / ::> syntax: just feels nice and fast and looks good to me. :smiley:

Summary

:: for Extreme Piping separator and <:: and ::> for beginning and ending syntax.

Example

sourceCmd <:: cmd1 :: cmd2 <:: cmd3 :: cmd4 ::> :: cmd5 ::> destinationCmd

Thoughts?

Update: Alternatively, single : for separator could even work.

sourceCmd <:: cmd1 : cmd2 <:: cmd3 : cmd4 ::> : cmd5 ::> destinationCmd

[Frozenfire92]

the user is already holding shift for < and can continue to hold shift and press the nearby buttons :

I think that has sold me. I'm a really big fan of

sourceCmd <:: cmd1 : cmd2 <:: cmd3 : cmd4 ::> : cmd5 ::> destinationCmd

[Glavin001]

Excellent! Yeah, I like that most, too.

[Glavin001]

The outputs (stdout) from the commands in the extreme pipe (cmd1, cmd2, etc) are implicitly appended as arguments to the destinationCmd, such that destinationCmd $1 $2 $3 where $1 is the stdout of cmd1, et cetera.

[Glavin001]

• Pipes the Easy Way!
• Pipe, Fork, Exec and Related Topics
• Passing a pipe as a parameter in exec

[Frozenfire92]

• pipe man pages