Re: $? behaviour after comsub in same command

2023-04-11 Thread Chet Ramey via austin-group-l at The Open Group
On 4/10/23 7:02 PM, Robert Elz wrote: Date:Mon, 10 Apr 2023 10:30:08 -0400 From:Chet Ramey Message-ID: <78038281-f431-775e-6d60-a44126d1d...@case.edu> | The different semantics are that the standard specifies the status of the | simple command in terms of

Re: $? behaviour after comsub in same command

2023-04-10 Thread Robert Elz via austin-group-l at The Open Group
Date:Mon, 10 Apr 2023 10:30:08 -0400 From:Chet Ramey Message-ID: <78038281-f431-775e-6d60-a44126d1d...@case.edu> | The different semantics are that the standard specifies the status of the | simple command in terms of the command substitution that's part of the

Re: $? behaviour after comsub in same command

2023-04-10 Thread Chet Ramey via austin-group-l at The Open Group
On 4/6/23 5:59 PM, Robert Elz wrote: Date:Wed, 5 Apr 2023 10:35:58 -0400 From:"Chet Ramey via austin-group-l at The Open Group" Message-ID: | A variant with slightly different semantics: | | (exit 8) | a=4 b=$(exit 42) c=$? | echo status:$? c=$c

Re: $? behaviour after comsub in same command

2023-04-10 Thread Chet Ramey via austin-group-l at The Open Group
On 4/6/23 5:43 PM, Robert Elz wrote: Hence we got that absurd PATH search rule for builtins, that no shell of the time did anything like, "because a user might want to override a builtin with a version in their own bin directory, earlier in PATH than where the standard version of the command

Re: $? behaviour after comsub in same command

2023-04-06 Thread Robert Elz via austin-group-l at The Open Group
Date:Fri, 7 Apr 2023 05:38:16 +0300 From:=?UTF-8?B?T8SfdXo=?= Message-ID: | a=${b#prefix} a=${a%suffix} | | is common enough a pattern to consider despite having no benefit other than | looking organized. Most shells interpret it the way average user

Re: $? behaviour after comsub in same command

2023-04-06 Thread Oğuz via austin-group-l at The Open Group
7 Nisan 2023 Cuma tarihinde Robert Elz via austin-group-l at The Open Group yazdı: > My guess (no more than that) is that sometimes it is easier to > give in to the desires of the masses rather than maintain the > correct approach. > > To people who don't understand sh syntax, > > a=1

Re: $? behaviour after comsub in same command

2023-04-06 Thread Robert Elz via austin-group-l at The Open Group
Date:Fri, 07 Apr 2023 03:14:47 +0200 From:Steffen Nurpmeso Message-ID: <20230407011447.ptyvc%stef...@sdaoden.eu> | There i say I'll omit the quotes from the standard... | So everything should be handled sequentially, making it a bug. >From where do you get

Re: $? behaviour after comsub in same command

2023-04-06 Thread Steffen Nurpmeso via austin-group-l at The Open Group
Robert Elz wrote in <6906.1680741...@jacaranda.noi.kre.to>: ... |The issue here is that people tend to think of | a=1 |as a command. It isn't (not as people think of it anyway). |But with that mindset they treat | a=1 b=$a c=$b |as 3 commands, one after the other. It isn't. To come

Re: $? behaviour after comsub in same command

2023-04-06 Thread Harald van Dijk via austin-group-l at The Open Group
On 05/04/2023 18:05, Harald van Dijk via austin-group-l at The Open Group wrote: On 05/04/2023 17:44, Oğuz wrote: 5 Nisan 2023 Çarşamba tarihinde Harald van Dijk > yazdı:     I am not sure which other ash based shells you were looking at, /bin/sh on NetBSD and FreeBSD

Re: $? behaviour after comsub in same command

2023-04-06 Thread Robert Elz via austin-group-l at The Open Group
Date:Wed, 5 Apr 2023 10:35:58 -0400 From:"Chet Ramey via austin-group-l at The Open Group" Message-ID: | A variant with slightly different semantics: | | (exit 8) | a=4 b=$(exit 42) c=$? | echo status:$? c=$c | | The standard is clear about what $?

Re: $? behaviour after comsub in same command

2023-04-06 Thread Robert Elz via austin-group-l at The Open Group
Date:Thu, 6 Apr 2023 11:17:43 -0400 From:"Chet Ramey via austin-group-l at The Open Group" Message-ID: <023c0028-e682-e1b6-99db-c8a596cdf...@case.edu> | My question is why they would choose something other than | what the so-called reference implementations

Re: $? behaviour after comsub in same command

2023-04-06 Thread Harald van Dijk via austin-group-l at The Open Group
On 06/04/2023 20:03, Chet Ramey via austin-group-l at The Open Group wrote: On 4/6/23 1:55 PM, Harald van Dijk wrote: One additional data point: in schily-2021-09-18, Jörg's last release, obosh, the legacy non-POSIX shell that is just there for existing scripts and for portability testing,

Re: $? behaviour after comsub in same command

2023-04-06 Thread Chet Ramey via austin-group-l at The Open Group
On 4/6/23 1:55 PM, Harald van Dijk wrote: One additional data point: in schily-2021-09-18, Jörg's last release, obosh, the legacy non-POSIX shell that is just there for existing scripts and for portability testing, prints 0 (using `` rather than $()), whereas pbosh and sh, the minimal and

Re: $? behaviour after comsub in same command

2023-04-06 Thread Harald van Dijk via austin-group-l at The Open Group
On 06/04/2023 16:17, Chet Ramey wrote: On 4/5/23 12:36 PM, Harald van Dijk wrote: On 05/04/2023 15:35, Chet Ramey via austin-group-l at The Open Group wrote: On 4/5/23 9:06 AM, Martijn Dekker via austin-group-l at The Open Group wrote: Consider: false || echo $(true) $? dash, mksh and

Re: $? behaviour after comsub in same command

2023-04-06 Thread Chet Ramey via austin-group-l at The Open Group
On 4/5/23 12:36 PM, Harald van Dijk wrote: On 05/04/2023 15:35, Chet Ramey via austin-group-l at The Open Group wrote: On 4/5/23 9:06 AM, Martijn Dekker via austin-group-l at The Open Group wrote: Consider: false || echo $(true) $? dash, mksh and yash print 1. bash, ksh93 and zsh print

Re: $? behaviour after comsub in same command

2023-04-06 Thread Oğuz via austin-group-l at The Open Group
5 Nisan 2023 Çarşamba tarihinde Harald van Dijk yazdı: > There is a legitimate benefit to this: swapping variables without an > additional helper variable actually works in that implementation. Good point, thanks -- Oğuz

Re: $? behaviour after comsub in same command

2023-04-05 Thread Robert Elz via austin-group-l at The Open Group
Date:Wed, 5 Apr 2023 18:25:32 +0300 From:"=?UTF-8?B?T8SfdXo=?= via austin-group-l at The Open Group" Message-ID: | Outliers are ash based shells; they apply | assignments concurrently but it isn't useful at all. No we don't, to do it concurrently we'd need to

Re: $? behaviour after comsub in same command

2023-04-05 Thread Steffen Nurpmeso via austin-group-l at The Open Group
Steffen Nurpmeso wrote in <20230405193451.u9bfz%stef...@sdaoden.eu>: |Harald van Dijk wrote in | <32a27194-a5ff-68d6-3a87-9120e34d8...@gigawatt.nl>: ||On 05/04/2023 17:44, Oğuz wrote: ||> 5 Nisan 2023 Çarşamba tarihinde Harald van Dijk > yazdı: ||> ||> I am

Re: $? behaviour after comsub in same command

2023-04-05 Thread Steffen Nurpmeso via austin-group-l at The Open Group
Harald van Dijk wrote in <32a27194-a5ff-68d6-3a87-9120e34d8...@gigawatt.nl>: |On 05/04/2023 17:44, Oğuz wrote: |> 5 Nisan 2023 Çarşamba tarihinde Harald van Dijk > yazdı: |> |> I am not sure which other ash based shells you were looking at, |> |> /bin/sh on

Re: $? behaviour after comsub in same command

2023-04-05 Thread Harald van Dijk via austin-group-l at The Open Group
On 05/04/2023 17:44, Oğuz wrote: 5 Nisan 2023 Çarşamba tarihinde Harald van Dijk > yazdı: I am not sure which other ash based shells you were looking at, /bin/sh on NetBSD and FreeBSD Thanks. I indeed see the same results as you on a recent version of FreeBSD

Re: $? behaviour after comsub in same command

2023-04-05 Thread Oğuz via austin-group-l at The Open Group
5 Nisan 2023 Çarşamba tarihinde Harald van Dijk yazdı: > I am not sure which other ash based shells you were looking at, /bin/sh on NetBSD and FreeBSD -- Oğuz

Re: $? behaviour after comsub in same command

2023-04-05 Thread Harald van Dijk via austin-group-l at The Open Group
On 05/04/2023 16:25, Oğuz via austin-group-l at The Open Group wrote: 5 Nisan 2023 Çarşamba tarihinde Chet Ramey via austin-group-l at The Open Group > yazdı: but should it be set fron the command substitution for the assignment to c? I think

Re: $? behaviour after comsub in same command

2023-04-05 Thread Harald van Dijk via austin-group-l at The Open Group
On 05/04/2023 15:35, Chet Ramey via austin-group-l at The Open Group wrote: On 4/5/23 9:06 AM, Martijn Dekker via austin-group-l at The Open Group wrote: Consider: false || echo $(true) $? dash, mksh and yash print 1. bash, ksh93 and zsh print 0. Which is right? I believe dash, mksh,

Re: $? behaviour after comsub in same command

2023-04-05 Thread Chet Ramey via austin-group-l at The Open Group
On 4/5/23 11:25 AM, Oğuz wrote: 5 Nisan 2023 Çarşamba tarihinde Chet Ramey via austin-group-l at The Open Group mailto:austin-group-l@opengroup.org>> yazdı: but should it be set fron the command substitution for the assignment to c? I think it'd be practical, is there a reason why

Re: $? behaviour after comsub in same command

2023-04-05 Thread Oğuz via austin-group-l at The Open Group
5 Nisan 2023 Çarşamba tarihinde Chet Ramey via austin-group-l at The Open Group yazdı: > but should it > be set fron the command substitution for the assignment to c? I think it'd be practical, is there a reason why it shouldn't? And while we're at it, is there a reason why assignments in a

Re: $? behaviour after comsub in same command

2023-04-05 Thread Chet Ramey via austin-group-l at The Open Group
On 4/5/23 9:06 AM, Martijn Dekker via austin-group-l at The Open Group wrote: Consider:     false || echo $(true) $? dash, mksh and yash print 1. bash, ksh93 and zsh print 0. Which is right? A variant with slightly different semantics: (exit 8) a=4 b=$(exit 42) c=$? echo status:$? c=$c

$? behaviour after comsub in same command

2023-04-05 Thread Martijn Dekker via austin-group-l at The Open Group
Consider: false || echo $(true) $? dash, mksh and yash print 1. bash, ksh93 and zsh print 0. Which is right? My hunch says dash, mksh and yash are right, as 'true' is executed in a command substitution (a subshell) within the same command, so 'false' should still be the "most recent