Bug#606821: mksh: bash-style process substitution
Hi,
do these have to be pipes? That got me wondering.
Otherwise, I could do a tree-level transform (except the IOREDIR
cases are again slightly more complex). Something like this:
• if (command2) is contained in command1:
‣ allocate a tempfile
⇒ attach the tempfile to the list of cleanups of command1
‣ run the command2
⇒ redirect its stdout to the tempfile
⇒ keep stderr and (?) stdin
⇒ throw away $? (?)
‣ replace (command2) with the name of the tempfile
‣ repeat for any further occurrences
• if (command3) is contained in command1:
‣ allocate a tempfile
⇒ attach the tempfile to the list of cleanups of command3
‣ replace (command3) with the name of the tempfile on command1
‣ change the TCOM tree command1 to a sequence
{ command1 ; tmpvar=$? ; command3 ; return $tmpvar ; }
‣ for any further occurrences command4, … append to the new
command sequence before the return
Of course, this needs much more careful checking. What does
GNU bash do to stdin, stderr, and the exit codes of the
substituted processes? (Though, strictly spoken, we could
do the above and test it quickly, then change the tempfile
mechanism to spit out FIFOs instead; I’ve done the last step
in an experimental branch already somewhere, so it’s easy.)
bye,
//mirabilos
--
I want one of these. They cost 720 € though… good they don’t have the HD hole,
which indicates 3½″ floppies with double capacity… still. A tad too much, atm.
‣ http://www.floppytable.com/floppytable-images-1.html
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606821: mksh: bash-style process substitution
Thorsten Glaser wrote: Hi, do these have to be pipes? That got me wondering. Yes, for most use cases I have run into they do need to be pipes and not tempfiles. I do think =(...) is neat, too, but it is a distinct feature. Thanks, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606821: mksh: bash-style process substitution
Thorsten Glaser wrote: Jonathan Nieder dixit[1]: ( ... )- runs ... in a subshell in the background, with its output connected to a pipe. [...] On Linux and similar OSes this is typically implemented using /proc/fd. A more portable implementation would use FIFOs. I don’t know whether this works on all mksh target OSes, but that can surely be investigated. [...] (…) is already on the wishlist – if you want to submit a patch, you’re welcome ;-) it should work on DEC ULTRIX 4.5, DEC OSF/1 V2.0, Minix 3, Haiku, Cygwin, UWIN, etc. though, and, if possible, Plan 9. ☺ Ha. mkfifo was part of POSIX.1-1988, so it should be fairly portable. - Ultrix and OSF/1 2.0:has mkfifo. - Minix 3: ought to have mkfifo (claims POSIX compliance). - Haiku: has mkfifo - Cygwin: has /proc/self/fd - UWIN:complicated? The ast-ast library supports /dev/fd, but native Windows apps obviously don't. - Plan 9: has devdup[2]. bind #d /dev/fd and you're good to go. It's on my list now. :) This construct is also handy when one wants to update the current environment downstream from some other process. process | while IFS= read -pr line; do … done Nice. I had been hoping for something like that. A side note, I’d like to track upstream feature requests *not* inside the Debian BTS. We usually use the MirBSD mailing list Thanks for a pointer. I'll report straight here from now on (perhaps along with reports to Debian with an appropriate Forwarded: pseudo-header). [1] http://bugs.debian.org/606821 [2] http://plan9.bell-labs.com/magic/man2html/3/dup -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606821: mksh: bash-style process substitution
Package: mksh Version: 39.3.20101101-1 Severity: wishlist Tags: upstream Hi Thorsten, Recently I found myself debugging a pipeline with tee. Unfortunately the logs grew large very quickly, so as a stopgap measure I used a compressor. mkfifo backflow ... backflow | tee (xz -1 log-one.xz) | ... | tee (xz -1 log-two.xz) | ... | tee (xz -1 log-three.xz) backflow This construct is also handy when one wants to update the current environment downstream from some other process. while read -r line do ... something interesting with line ... accum=$(updated result) done (upstream process) : print result printf %s\n $accum The semantics: ( ... )- runs ... in a subshell in the background, with its output connected to a pipe. The ( ... ) expression evaluates to a filename that can be opened to read from that pipe. ( ... )- runs ... in a subshell in the background, with its input connected to a pipe. The ( ... ) evaluates to a filename that can be opened to write to that pipe. On Linux and similar OSes this is typically implemented using /proc/fd. A more portable implementation would use FIFOs. What do you think? Is it worth implementing in mksh? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606821: mksh: bash-style process substitution
Jonathan Nieder dixit: This construct is also handy when one wants to update the current environment downstream from some other process. process | while IFS= read -pr line; do … done ↑ is the proper ksh idiom for that. ( ... )- runs ... in a subshell in the background, with its output connected to a pipe. Ah, interesting. I would have thought it ran the stuff first, wrote it to a temporary file and then passed that to the other process, sort of like a dynamic here document, from when I first read about it. (Didn’t know (…) existed.) On Linux and similar OSes this is typically implemented using /proc/fd. A more portable implementation would use FIFOs. I don’t know whether this works on all mksh target OSes, but that can surely be investigated. What do you think? Is it worth implementing in mksh? (…) is already on the wishlist – if you want to submit a patch, you’re welcome ;-) it should work on DEC ULTRIX 4.5, DEC OSF/1 V2.0, Minix 3, Haiku, Cygwin, UWIN, etc. though, and, if possible, Plan 9. ☺ A side note, I’d like to track upstream feature requests *not* inside the Debian BTS. We usually use the MirBSD mailing list for that, although there’s now a Launchpad project associated with mksh which can be used if desired. bye, //mirabilos -- ch you introduced a merge commit│mika % g rebase -i HEAD^^ mika sorry, no idea and rebasing just fscked │mika Segmentation ch should have cloned into a clean repo │ fault (core dumped) ch if I rebase that now, it's really ugh │mika:#grml wuahh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
