Deutsch English Français Italiano |
<vf2hi4$3en6a$1@news.xmission.com> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!news.snarked.org!xmission!nnrp.xmission!.POSTED.shell.xmission.com!not-for-mail From: gazelle@shell.xmission.com (Kenny McCormack) Newsgroups: comp.unix.shell Subject: coprocs - again (Was: Different variable assignments) Date: Sun, 20 Oct 2024 09:12:36 -0000 (UTC) Organization: The official candy of the new Millennium Message-ID: <vf2hi4$3en6a$1@news.xmission.com> References: <lmt83dFsvbvU3@mid.individual.net> <vf1942$1uso$1@dont-email.me> <vf1dfl$3e4c7$1@news.xmission.com> <vf239t$9ikn$1@dont-email.me> Injection-Date: Sun, 20 Oct 2024 09:12:36 -0000 (UTC) Injection-Info: news.xmission.com; posting-host="shell.xmission.com:166.70.8.4"; logging-data="3628234"; mail-complaints-to="abuse@xmission.com" X-Newsreader: trn 4.0-test77 (Sep 1, 2010) Originator: gazelle@shell.xmission.com (Kenny McCormack) Bytes: 4864 Lines: 85 In article <vf239t$9ikn$1@dont-email.me>, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote: >On 20.10.2024 00:56, Kenny McCormack wrote: >> In article <vf1942$1uso$1@dont-email.me>, >> Lawrence D'Oliveiro <ldo@nz.invalid> wrote: >>> On Sat, 19 Oct 2024 14:52:01 +0200, Janis Papanagnou wrote: >>> >>>> Also, if above code is how to use co-processes in Bash, I consider that >>>> extremely clumsy (if compared to, say, Ksh). >> >> "extremely" seems more than a bit over the top. Maybe somewhat clumsy, but >> hardly "extremely". > >I don't think it makes much sense to discuss subjective valuations. >But okay. It has to do with certain habits/conventions that Usenet posters have fallen into. One sees this frequently, where words like "very" and "extremely" are dropped into one's phrasing for no particularly good reason. You (Janis) are hardly alone in this habit, but it is something that has frequently annoyed me about Usenet parlance. There is a story on this subject (having to do with the journalistic over-use of the word "very"), which I frequently quote in real life conversations, attributed to Mark Twain. I may yet end up telling that story on this thread, but not right now. >Mine stems from a "per-feature level" (and is no absolute). It was >based on LDO's suggestion (which was a bit more complex than your >version) that used; (1) a [new] keyword, (2) command grouping (not >sure it's necessary[*] in the first place?), (3) using an explicit >descriptor through (4) a variable, (5) using an array instead of a >scalar element, and (6) using 'wait' (I'm also not sure this is >necessary in the first place or just the poster not knowing better?). My opinion, which I have stated consistently in this thread, is that it doesn't add up to much difference - hence my criticism of your use of the word "extremely". Addressing each of your points: 1) So what? |& vs. coproc. Who cares? I explained in another post why (IMHO) they did it this way. As both me and LDO have noted, bash supports multiple concurrent coprocs, so doing it this way is necessary. 2) It is necessary. The syntax is admittedly a bit weird and not well documented. If the thing you are launching as a coproc is anything other than a single word command, then it has to be enclosed in {}. For quite a while, I didn't know this, so as a workaround, I'd write a function (say: foo()) then do: coproc foo 3&4&5) Necessary because bash supports multiple concurrent coprocs. Also, as I've noted, you don't actually have to use array notation to get the "read output from the coproc" fd. 6) Not necessary, and I've never used it in my code. As I have mentioned in another post, I think LDO was being intentionally pedantically complete in his example. >For a simple feature that's really a lot compared to e.g. ksh's way. >(YMMV. But if "somewhat clumsy" triggers less emotions then I'm fine >with that.) I think there is no significant difference at all (*). See above. (*) Other than that bash does support multiple concurrent coprocs (if you are willing to recompile bash). .... >(Yes, '|' is different than '|&', which is more like '&' since it >separates commands where the pipe connects them. But that was not >the point here.) As noted elsethread, bash took |& from csh (*). So, they had to come up with something else for coprocs. (*) I don't think this was a particularly bright move on their part, BTW. I never use it; I always use the more normal "2>&1" syntax. .... No comment on the rest, other than to say that you seem to claim that ksh does support multiple concurrent coprocs, which I think is wrong, but I think we may not be talking about the same thing (so probably not much point in continuing in that vein). -- Conservatives want smaller government for the same reason criminals want fewer cops.