Re: sh: aliases in command substitutions

2020-04-20 Thread shwaresyst
Yes, I do have an idea, since I was on those phone calls. It is your comments that are ill founded. The first unquoted newline terminates the recognition phase/lookahead's mentioned. Substitutions occur afterwards to determine final token classifications, not during this initial pass. That

Re: sh: aliases in command substitutions

2020-04-20 Thread Robert Elz
Date:Mon, 20 Apr 2020 21:17:12 + (UTC) From:shwaresyst Message-ID: <1050536090.3716059.1587417432...@mail.yahoo.com> | No, those are attempts at speed optimizations; I'm sad to have to reply like this, but do you have any idea at all what you're talking about?

Re: sh: aliases in command substitutions

2020-04-20 Thread shwaresyst
No, those are attempts at speed optimizations; the description before the numbered list of XCU 2.3 has line delimiting comes first as the logical model to determine tokenizing mode. This is continued in list items 4. and 5., that substitutions shall not occur during recognition. This makes

Re: sh: aliases in command substitutions

2020-04-20 Thread shwaresyst
It seems to me that what is missing, in XCU 2.3.1, is a statement that use of keywords in alias bodies is unspecified behavior. Even outside double quotes an initial scan collecting tokens to form a logical line distinct from a potential io-here body will have to treat an alias name as a

Re: sh: aliases in command substitutions

2020-04-20 Thread Robert Elz
Date:Mon, 20 Apr 2020 19:09:13 +0200 From:Joerg Schilling Message-ID: <5e9dd739.mzznyjmgko8+pliv%joerg.schill...@fokus.fraunhofer.de> | Whether it works to use the alias switch=case is a different thing. | If you like this to work, you need to have a lexer that

Re: sh: aliases in command substitutions

2020-04-20 Thread Joerg Schilling
Robert Elz wrote: > (lines 74718-22, Issue 7 TC2 - 2018 edition) says ... > > The input characters within the quoted string that are also enclosed > between "$(" and the matching ')' shall not be affected by the > double-quotes, but rather shall define that command whose output >

Re: aliases in command substitutions

2020-04-20 Thread Robert Elz
Date:Mon, 20 Apr 2020 10:59:12 -0400 From:Chet Ramey Message-ID: <6802459a-6b68-5bd6-b535-401d5ec6b...@case.edu> | He's right, and it happened 30 years ago: Ah, OK, thanks - so it was originally for that purpose, but isn't needed for that any more (but is retained

Re: aliases in command substitutions

2020-04-20 Thread Chet Ramey
On 4/20/20 9:34 AM, Robert Elz wrote: > | but I've always understood the > | case xxx in > | (pattern) ...;; > | esac > | > | (fully parenthesized pattern) syntax to have been invented precisely > | to allow case statements in $() subshell notation, > > First, $()

Re: aliases in command substitutions

2020-04-20 Thread Robert Elz
Date:Mon, 20 Apr 2020 07:12:03 + From:"Schwarz, Konrad" Message-ID: <38be7e5d52c74c9dac140f7de5105...@siemens.com> | Not sure if I understand your problem, I suspect probably not. | but I've always understood the | case xxx in | (pattern) ...;; |

Re: XCU 2.14: Exit status by no-argument `return' in shell trap handlers

2020-04-20 Thread Koichi Murase
2020-04-20 1:42 Robert Elz : > Probably not, bosh is derived from that shell (more or less) and it is > also A > > [...] > > So are the FreeBSD and NetBSD shells (which is not surprising, as like > dash, they're descendants of ash). > > You can also add zsh to A: Thank you for the information. I