10 comments

[ 2.9 ms ] story [ 12.3 ms ] thread
as long as we don't run out of PIDs... spoken like a true hero
Wow man that's awesome! Congratulations..
On a related note, it took me years of playing with *nix to notice that the notations '&' and '|' were chosen to mimic series and parallel operations. These days we tend to think of '&' as a backgrounding operation, and it's almost always the final token in a command:

  $ some_background_command &
I suspect it was originally intended to run commands in parallel:

  $ command1 & command2
I saw that second notation in some stack overflow answer and had the same epiphany. Cute notations like this make shell scripting fun (and convenient for so many use cases).

This article is great for having both a nontrivial FIFO and a nontrivial circuit discussion in the same guide—both things for which I've had difficulty finding good self-contained tutorials.

I don't know, whether '&' was there from the day one? Something semantically equal should have present in McIlroy's mind certainly, but implementation?

> "Somewhere at that time I talked of a macro as a 'switchyard for data streams,' and there's a paper hanging in Brian Kernighan's office, which he dredged up from somewhere, where I talked about screwing together streams like a garden hose"

> "And over a period from 1970 to 1972, I'd from time to time say, 'How about making something like this?', and I'd put up another proposal, another proposal, another proposal. And one day I came up with a syntax for the shell that went along with the piping"

> "I remember the preposterous syntax, the ">,>" or whatever the syntax that everyone came up with, and then all of a sudden there was the vertical bar '|' and just everything clicked at that point," he said. The bar was the syntax that made pipes work"

https://web.archive.org/web/20001214172500/http://www.bell-l...

E.g. stderr had not been implemented from the start - http://minnie.tuhs.org/pipermail/tuhs/2017-September/010406....

Also don't forget && and ||, which only run the next prog on return of a zero exit status or non-zero exit status respectively.

Also, ; between commands is the equivalent of running each command on a seperate line (command independent of previous command exit status).

& = run in background

; = execute sequentially

&& = AND operator

|| = OR operator

! = NOT operator

&&-|| = ANDOR operator

{} = combine command operator

() = precedence operator

=~ = regex operator

http://www.gnu.org/software/bash/manual/bashref.html#Conditi...

To me (Unix guy since 1980) the & character has always been "submit this command .. AND .. <the next thing I type>" .. so yeah, it seems like it actually did fulfil what you consider its 'original intention' - which was to allow you to submit a command, AND .. another one ..
This is brilliance - epiphany for sure. I will try this.

All the folks out there working with arduinos and the like and having to diagram/proto the pins and their control, particular I2C might find this useful...which is what im going to try use it for.