Re: More issues with pattern matching

On 05/08/2020 15:54, Geoff Clare via austin-group-l at The Open Group wrote: Harald van Dijk wrote, on 31 Jul 2020: Take the previous example glibc's cy_GB.UTF-8 locale, but with a different collating element: in this locale, "dd" is a single collating element too. Therefore,

Re: [1003.1(2016/18)/Issue7+TC2 0001384]: Subshell of an interactive shell is effectively non-interactive

On 11/01/2021 16:45, Austin Group Bug Tracker via austin-group-l at The Open Group wrote: shall be set to the default action.If the shell is interactive, the subshell shall behave as a non-interactive shell in all respects except:The expansion of the special parameter '-' and the output of set

Re: utilities and write errors

On 04/07/2021 21:54, Robert Elz wrote: Date:Sun, 4 Jul 2021 19:26:25 +0100 From:Harald van Dijk Message-ID: <40fc0b0c-364f-8ff8-0613-a76c887d4...@gigawatt.nl> | P.S.: The fact that the underlying file descriptor of standard output is | fd 1 rather than

Re: utilities and write errors

On 04/07/2021 18:32, Robert Elz via austin-group-l at The Open Group wrote: Date:Thu, 1 Jul 2021 11:45:40 +0100 From:"Geoff Clare via austin-group-l at The Open Group" Message-ID: <20210701104540.GA4023@localhost> | it just requires pwd to write the

Re: utilities and write errors

On 30/06/2021 16:56, Chet Ramey via austin-group-l at The Open Group wrote: On 6/30/21 11:49 AM, Joerg Schilling via austin-group-l at The Open Group wrote: Erm, yes. For some reason, I assumed the OP wrote &> instead of >& which have the same meaning in GNU bash (but &> is the parse-trouble

Re: sh: Assignments to PATH and XCU 2.9.1

On 19/03/2021 16:41, Robert Elz via austin-group-l at The Open Group wrote: In note 5287 to bug 1460 (an innocuous change to the hash command) ( https://austingroupbugs.net/view.php?id=1460#c5287 ) Geoff said: [...] that statement about PATH is pointing out a normative requirement from

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

On 12/04/2021 21:57, Robert Elz wrote: Date:Mon, 12 Apr 2021 18:42:03 +0100 From:Harald van Dijk Message-ID: | No, not anything. It still has to be shell start-up activity. And your definition of what is a shell start-up activity comes from ? When

Re: execve(2) optimisation for last command

On 15/04/2021 21:36, Martijn Dekker via austin-group-l at The Open Group wrote: My question: why is this? I would have thought that a script is a script and that it should make no essential difference whether a script is taken from a -c argument or loaded from a file. What makes the

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

On 12/04/2021 20:22, (Joerg Schilling) wrote: Harald van Dijk wrote: On 12/04/2021 12:47, (Joerg Schilling) wrote: Do you have a private variant og ksh93v? I get the same behavior from ksh88, the ksh93 from OpenSolaris and ksh93v. I don't. I was testing with ksh built from

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

On 12/04/2021 00:25, Robert Elz wrote: Date:Sun, 11 Apr 2021 22:27:19 +0100 From:Harald van Dijk Message-ID: <79b98e30-46ba-d468-153f-c1a2a0416...@gigawatt.nl> | Okay, but that is a technicality. The pre-seeding is only permitted at | startup time, No,

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

On 12/04/2021 12:47, (Joerg Schilling) wrote: Harald van Dijk wrote: If they are mistakes, they are widespread mistakes. As hinted in the links, with PATH=/bin:/usr/bin, /bin/gcc and /usr/bin/gcc both existing as files with execute permission, but /bin/gcc as a text file containing #!/bad so

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

On 13/04/2021 14:43, Chet Ramey wrote: On 4/13/21 5:16 AM, Harald van Dijk via austin-group-l at The Open Group wrote: Please note again that POSIX's Command Search and Execution doesn't say "continue until execve() doesn't fail". It says "Otherwise, the command shall be sea

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

On 11/04/2021 13:02, Joerg Schilling via austin-group-l at The Open Group wrote: "Harald van Dijk via austin-group-l at The Open Group" wrote: If they are mistakes, they are widespread mistakes. As hinted in the links, with PATH=/bin:/usr/bin, /bin/gcc and /usr/bin/gcc both existin

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

On 10/04/2021 17:08, Robert Elz via austin-group-l at The Open Group wrote: Date:Sat, 10 Apr 2021 11:54:34 +0200 From:"Jan Hafer via austin-group-l at The Open Group" Message-ID: <15c15a5b-2808-3c14-7218-885e704cc...@rwth-aachen.de> | my inquiry is a

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

On 11/04/2021 16:33, Robert Elz wrote: Date:Sun, 11 Apr 2021 13:25:46 +0100 From:Harald van Dijk Message-ID: | > My tests show that ksh, bash, yash, mksh do not find gcc in that case. | | Huh. My tests with ksh were with 93v, it's possible different

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

On 11/04/2021 17:09, shwaresyst via austin-group-l at The Open Group wrote: No, it's not nonsense. The definition of comment has all characters, including '!', shall be ignored until newline or end-of-file being conforming. Then tokenization which might discover an operator, keyword or command

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

On 11/04/2021 17:50, Robert Elz wrote: Date:Sun, 11 Apr 2021 17:04:05 +0100 From:Harald van Dijk Message-ID: <92113e70-5605-10f4-8e57-47c9f64cd...@gigawatt.nl> | This only applies when a remembered location exists at all, though. Yes, but in the examples I

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

On 11/04/2021 21:17, shwaresyst wrote: The requirement explicitly specified behavior shall be implemented as specified takes priority. Some conforming script authors may simply want the first line to be a # IMPORTANT USAGE NOTE headline, or

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

On 11/04/2021 22:05, Robert Elz wrote: Date:Sun, 11 Apr 2021 19:46:36 +0100 From:Harald van Dijk Message-ID: <9ab286f9-125d-55a4-a65f-08d4af04d...@gigawatt.nl> | Sure, that's why I then switched to a different example that did not | have an earlier

Re: [1003.1(2008)/Issue 7 0000249]: Add standard support for $'...' in shell

On 06/02/2021 23:38, Robert Elz via austin-group-l at The Open Group wrote: Date:Sat, 06 Feb 2021 21:55:19 +0100 From:Steffen Nurpmeso Message-ID: <20210206205519.43rln%stef...@sdaoden.eu> | Fiddling with bytes is something completely different. But how is

Re: [1003.1(2016/18)/Issue7+TC2 0001454]: Conflict between "case" description and grammar

On 19/02/2021 16:21, Geoff Clare via austin-group-l at The Open Group wrote: It may be prudent to clarify matters by rearranging things in the grammar so that it ends up saying "Do not apply rule 4" when a '(' has just been seen, like it does when a '|' has just been seen. That sounds good. I

Re: [1003.1(2016/18)/Issue7+TC2 0001454]: Conflict between "case" description and grammar

On 21/02/2021 18:17, Joerg Schilling via austin-group-l at The Open Group wrote: "Harald van Dijk via austin-group-l at The Open Group" wrote: On 21/02/2021 17:18, Joerg Schilling via austin-group-l at The Open Group wrote: "Harald van Dijk via austin-group-l at The Open

Re: [1003.1(2016/18)/Issue7+TC2 0001454]: Conflict between "case" description and grammar

On 21/02/2021 17:18, Joerg Schilling via austin-group-l at The Open Group wrote: "Harald van Dijk via austin-group-l at The Open Group" wrote: That is neither what the standard says nor what shells do, though. case x in ( (x) echo match ;; esac is rejected because that firs

Re: [1003.1(2016/18)/Issue7+TC2 0001454]: Conflict between "case" description and grammar

On 22/02/2021 09:51, Geoff Clare via austin-group-l at The Open Group wrote: I think your suggestion works, but having a separate production to add the ')' seems unnecessary. I'd also rename "pattern" since it is really just WORD that constitutes a pattern to be matched. So how about this:

Re: [1003.1(2016/18)/Issue7+TC2 0001454]: Conflict between "case" description and grammar

On 19/02/2021 15:04, Geoff Clare via austin-group-l at The Open Group wrote: Harald van Dijk wrote, on 19 Feb 2021: On 19/02/2021 09:59, Geoff Clare via austin-group-l at The Open Group wrote: How about changing that problem sentence in 2.10.1 to: When a TOKEN is seen where one

Re: [1003.1(2016/18)/Issue7+TC2 0001454]: Conflict between "case" description and grammar

On 19/02/2021 09:59, Geoff Clare via austin-group-l at The Open Group wrote: How about changing that problem sentence in 2.10.1 to: When a TOKEN is seen where one of those annotated productions could be used to reduce the symbol, the applicable rule shall be applied to convert

Re: [1003.1(2016/18)/Issue7+TC2 0001454]: Conflict between "case" description and grammar

On 19/02/2021 15:33, Geoff Clare via austin-group-l at The Open Group wrote: Harald van Dijk wrote, on 19 Feb 2021: On 19/02/2021 15:04, Geoff Clare via austin-group-l at The Open Group wrote: Harald van Dijk wrote, on 19 Feb 2021: On 19/02/2021 09:59, Geoff Clare via austin-group-l

Re: [1003.1(2016/18)/Issue7+TC2 0001454]: Conflict between "case" description and grammar

On 19/02/2021 17:56, Robert Elz wrote: Date:Fri, 19 Feb 2021 15:11:58 + From:"Harald van Dijk via austin-group-l at The Open Group" Message-ID: <4b4f2cbf-2a2e-f0bf-34ca-a7357f99c...@gigawatt.nl> | Observe that rule 4 is applied fo

Re: [1003.1(2016/18)/Issue7+TC2 0001454]: Conflict between "case" description and grammar

On 22/02/2021 13:13, Joerg Schilling via austin-group-l at The Open Group wrote: "Harald van Dijk via austin-group-l at The Open Group" wrote: $ bosh -c 'case x in ( (x) echo match ;; esac' bosh: syntax error at line 1: `(' unexpected It may be that you are missinterpreting t

Re: $? in a simple command with no command name

On 01/09/2021 17:22, Geoff Clare via austin-group-l at The Open Group wrote: Harald van Dijk wrote, on 01 Sep 2021: The second problem is the redirection. Based on the above, command substitutions in a redirection are supposed to affect the exit status just as any other command substitution

Re: $? in a simple command with no command name

Hi, On 01/09/2021 14:38, Oğuz via austin-group-l at The Open Group wrote: Consider the following: true a=$? b=`exit 1` b=$? >`echo /dev/null; exit 2` echo $? $a $b Having read the relevant sections of the standard a couple times, I would expect the output to be `1 0 0'; I agree.

Re: shell: swapping var values in one command, plus some here doc stuff

On 03/09/2021 13:23, Robert Elz via austin-group-l at The Open Group wrote: and ksh93 did: ksh93 $ cat < It looks like ksh93 fails to properly handle backslash-newline pairs that occur during determination of whether the current line is the heredoc delimiter, so any backslash-newline after a

Re: $? in a simple command with no command name

On 01/09/2021 18:48, Robert Elz via austin-group-l at The Open Group wrote: Date:Wed, 1 Sep 2021 16:38:00 +0300 From:"=?UTF-8?B?T8SfdXo=?= via austin-group-l at The Open Group" Message-ID: | true | a=$? b=`exit 1` b=$? >`echo /dev/null; exit 2` |

Re: Adding %n$ conversions to the printf utility (printf(1))

On 10/09/2021 22:14, (Joerg Schilling) wrote: Harald van Dijk wrote: Not correct: ksh93 prints the same as bosh Indeed, something went wrong with the copying there. > and pleasew note that my example is > using an integer format instead of a string format. Irrelevant. You wrote: >

Re: Adding %n$ conversions to the printf utility (printf(1))

On 10/09/2021 21:34, (Joerg Schilling) wrote: Harald van Dijk wrote: No, it isn't. The second command prints ksh93: c a d zsh: printf: 3: argument specifier out of range c a bosh: c a d Not correct: ksh93 prints the same as bosh Indeed, something went wrong

Re: Adding %n$ conversions to the printf utility (printf(1))

On 10/09/2021 20:27, Joerg Schilling via austin-group-l at The Open Group wrote: "O?uz via austin-group-l at The Open Group" wrote: Wouldn't it be more useful if, in printf(1), `n' in `%n$' referred to the nth argument in the current set of arguments being processed? For example, the

Re: Adding %n$ conversions to the printf utility (printf(1))

On 10/09/2021 22:54, Joerg Schilling via austin-group-l at The Open Group wrote: "Harald van Dijk via austin-group-l at The Open Group" wrote: Either the distinction matters or it doesn't. If it matters, then it was important to switch back to talk about what O?uz wrote. If it does

Re: shell: swapping var values in one command, plus some here doc stuff

On 08/09/2021 08:15, Oğuz via austin-group-l at The Open Group wrote: Sorry for butting in, but according to the standard, is there really a syntax error in the following? sh -c ': << do | for x in xxx do do echo $x done' busybox sh, dash, gwsh, netbsd sh, and freebsd sh complain about a

Re: [1003.1(2016/18)/Issue7+TC2 0001440]: Calling `system("-some-tool")` fails (although it is a valid `sh` command)

On 31/10/2021 01:21, Wayne Pollock via austin-group-l at The Open Group wrote: Is it guaranteed that on conforming systems nohup (and friends) must not accept or delete the first "--"?  For the example to work, nohup must not discard the "--". But might it? For context, the example was .

Re: wait and stopped jobs

On 28/02/2022 23:20, Robert Elz via austin-group-l at The Open Group wrote: It is worth pointing out though that testing this in interactive shells is somewhat of a weird case - it should probably be done in a script instead. That's because of the effect of the (implicit) jobs command before

wait and stopped jobs

Hi, wait is specified as: If one or more pid operands are specified that represent known process IDs, the wait utility shall wait until all of them have terminated. In no shell does the wait utility appear to behave this way. To test this, in an interactive shell, I tried: sleep 10 &

Re: how do to cmd subst with trailing newlines portable (was: does POSIX mandate whether the output…)

On 27/01/2022 17:43, Geoff Clare via austin-group-l at The Open Group wrote: Harald van Dijk wrote, on 27 Jan 2022: On 27/01/2022 12:44, Geoff Clare via austin-group-l at The Open Group wrote: Christoph Anton Mitterer wrote, on 26 Jan 2022: 3) Does POSIX define anywhere which values a shell

Re: how do to cmd subst with trailing newlines portable (was: does POSIX mandate whether the output…)

On 27/01/2022 16:06, Chet Ramey via austin-group-l at The Open Group wrote: Wow, that seems like a bug. Environment variables can contain sequences of arbitrary non-NULL bytes, and, as long as the portion before the `=' is a valid NAME, the shell is required to create a variable with the

Re: how do to cmd subst with trailing newlines portable (was: does POSIX mandate whether the output…)

On 28/01/2022 01:48, Christoph Anton Mitterer wrote: On Thu, 2022-01-27 at 15:18 +, Harald van Dijk via austin-group-l at The Open Group wrote: The benefit of this that when the shell's locale changes, variables still hold their original text (as opposed to their original bytes

Re: how do to cmd subst with trailing newlines portable (was: does POSIX mandate whether the output…)

On 28/01/2022 01:49, Christoph Anton Mitterer wrote: And hasn't it always been the case that stdout/in can contain arbitrary binary data? This is done by gazillions of tools, including such standardised by POSIX (cat, tr, even printf via \ooo sequences). Yes, but it has also been the case that

Re: how do to cmd subst with trailing newlines portable (was: does POSIX mandate whether the output…)

On 28/01/2022 01:49, Christoph Anton Mitterer wrote: On Thu, 2022-01-27 at 17:07 +, Harald van Dijk via austin-group-l at The Open Group wrote: That is not what POSIX says. It says "The value of an environment variable is a string of characters" (8.1 Environment Variable

Re: how do to cmd subst with trailing newlines portable (was: does POSIX mandate whether the output…)

On 27/01/2022 12:44, Geoff Clare via austin-group-l at The Open Group wrote: Christoph Anton Mitterer wrote, on 26 Jan 2022: 3) Does POSIX define anywhere which values a shell variable is required to be able to store? I only found that NUL is excluded, but that alone doesn't mean that

Re: [1003.1(2016/18)/Issue7+TC2 0001558]: require [^...] in addition to [!...] for bracket expression negation

On 24/01/2022 08:51, Austin Group Bug Tracker via austin-group-l at The Open Group wrote: The following issue has been SUBMITTED. == https://www.austingroupbugs.net/view.php?id=1558

Re: [Issue 8 drafts 0001564]: clariy on what (character/byte) strings pattern matching notation should work

[accidentally replied privately, re-sending to list] On 22/04/2022 10:54, Geoff Clare via austin-group-l at The Open Group wrote: Harald van Dijk wrote, on 15 Apr 2022: For the most part(*), those shells that support locales appear to already be in agreement that single bytes that do not form

Re: [Issue 8 drafts 0001564]: clariy on what (character/byte) strings pattern matching notation should work

On 15/04/2022 04:57, Christoph Anton Mitterer wrote: On Fri, 2022-04-15 at 00:44 +0100, Harald van Dijk via austin-group-l at The Open Group wrote: Hmm, I would. I like that :-D This would have been the preferred alternative I've asked for to look at, in the ticket. Shells

Re: [Issue 8 drafts 0001564]: clariy on what (character/byte) strings pattern matching notation should work

On 19/04/2022 01:52, Harald van Dijk via austin-group-l at The Open Group wrote: On 15/04/2022 04:57, Christoph Anton Mitterer wrote: On Fri, 2022-04-15 at 00:44 +0100, Harald van Dijk via austin-group-l at The Open Group wrote: If there is interest in getting this standardised, I can spend

Re: POSIX bind_textdomain_codeset(): some invalid codeset arguments

On 12/05/2022 23:10, Steffen Nurpmeso wrote: Harald van Dijk wrote in : |On 12/05/2022 18:19, Steffen Nurpmeso via austin-group-l at The Open |Group wrote: |> Bruno Haible wrote in |> <4298913.vrqWZg68TM@omega>: |>|Steffen Nurpmeso wrote: |>|> ... |>|>| [.] "UTF-7"." |>|>

Re: [Issue 8 drafts 0001564]: clariy on what (character/byte) strings pattern matching notation should work

On 19/05/2022 02:46, Christoph Anton Mitterer wrote: On Sun, 2022-05-15 at 16:14 +0100, Harald van Dijk wrote: Please see the tests and results here. So dash/ash/mksh/posh/pdksh,... and every other shell that doesn't handle locales at all (and thus works in the C locale)... is anyway always

Re: POSIX bind_textdomain_codeset(): some invalid codeset arguments

On 13/05/2022 14:28, Steffen Nurpmeso wrote: You again strip content of follow-up RFCs. In my previous message, I quoted your message that I replied to in full. I stripped absolutely nothing and do not appreciate your utterly false claim here. Retract it. Harald van Dijk

Re: [Issue 8 drafts 0001564]: clariy on what (character/byte) strings pattern matching notation should work

On 15/05/2022 16:14, Harald van Dijk via austin-group-l at The Open Group wrote: On 19/04/2022 01:52, Harald van Dijk via austin-group-l at The Open Group wrote: On 15/04/2022 04:57, Christoph Anton Mitterer wrote: On Fri, 2022-04-15 at 00:44 +0100, Harald van Dijk via austin-group-l

Re: [Issue 8 drafts 0001564]: clariy on what (character/byte) strings pattern matching notation should work

On 20/05/2022 01:11, Christoph Anton Mitterer wrote: On Thu, 2022-05-19 at 09:05 +0100, Harald van Dijk wrote: The above, AFAIU, mean that any shell/fnmatch matches a valid multibyte character... but also a byte that is not a character in the locale. Correct, though as I wrote later on, the

Re: POSIX bind_textdomain_codeset(): some invalid codeset arguments

On 12/05/2022 18:19, Steffen Nurpmeso via austin-group-l at The Open Group wrote: Bruno Haible wrote in <4298913.vrqWZg68TM@omega>: |Steffen Nurpmeso wrote: |> ... |>| [.] "UTF-7"." |> |> That is overshoot. | |No. UTF-7 is invalid here because it produces output that is not NUL

Re: When can shells remove "known" process IDs from the list?

On 29/04/2022 19:38, Robert Elz via austin-group-l at The Open Group wrote: Date:Fri, 29 Apr 2022 15:39:23 +0100 From:"Geoff Clare via austin-group-l at The Open Group" Message-ID: <20220429143923.GA22521@localhost> | It also appears that dash still

Re: [1003.1(2016/18)/Issue7+TC2 0001614]: XSH 3/mktime does not specify EINVAL and should

On 25/11/2022 05:40, Robert Elz via austin-group-l at The Open Group wrote: Date:Thu, 24 Nov 2022 15:49:49 + From:"Geoff Clare via austin-group-l at The Open Group" Message-ID: | Combining the above with the TZ rules, if TZ=EST5EDT then POSIX requires

Re: Syntax error with "command . file" (was: [1003.1(2016/18)/Issue7+TC2 0001629]: Shell vs. read(2) errors on the script)

On 10/03/2023 17:12, Geoff Clare via austin-group-l at The Open Group wrote: -- (0006200) kre (reporter) - 2023-03-10 14:52 https://www.austingroupbugs.net/view.php?id=1629#c6200

Re: Syntax error with "command . file" (was: [1003.1(2016/18)/Issue7+TC2 0001629]: Shell vs. read(2) errors on the script)

On 15/03/2023 00:17, Chet Ramey wrote: On 3/14/23 4:58 PM, Harald van Dijk wrote: On 14/03/2023 20:41, Chet Ramey wrote: On 3/12/23 10:19 PM, Harald van Dijk via austin-group-l at The Open Group wrote: bash appears to disables the reading of .profile in POSIX mode entirely. This isn't

Re: Syntax error with "command . file" (was: [1003.1(2016/18)/Issue7+TC2 0001629]: Shell vs. read(2) errors on the script)

On 14/03/2023 20:41, Chet Ramey wrote: On 3/12/23 10:19 PM, Harald van Dijk via austin-group-l at The Open Group wrote: bash appears to disables the reading of .profile in POSIX mode entirely. This isn't quite correct. By default, a login shell named `sh' or `-sh' reads /etc/profile

Re: Syntax error with "command . file" (was: [1003.1(2016/18)/Issue7+TC2 0001629]: Shell vs. read(2) errors on the script)

On 12/03/2023 19:10, Robert Elz wrote: Date:Fri, 10 Mar 2023 23:40:18 + From:"Harald van Dijk via austin-group-l at The Open Group" Message-ID: | Based on past experiences, I am assuming the e-mail this is a reply to | was meant

Re: Syntax error with "command . file" (was: [1003.1(2016/18)/Issue7+TC2 0001629]: Shell vs. read(2) errors on the script)

d van Dijk via austin-group-l at The Open Group" Message-ID: | Other shells that exit are bosh, yash, and my own. It's both what POSIX | currently requires (contrary to what kre wrote on the bug) That's not how I intended what I wrote to be interpreted, I meant exactly wha

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

On 27/06/2019 09:29, Stephane Chazelas wrote: 2019-06-27 08:59:29 +0100, Harald van Dijk: [...] If there is no fnmatch() implementation that behaves that way, then agreed that it makes sense to just specify that. That pax example in the rationale should then also be changed to not escape any

Re: Writing the "[job] pid" for async and-or lists

On 24/02/2023 15:59, Robert Elz via austin-group-l at The Open Group wrote: In new text added by bug 1254, in the (renamed) section "Asynchronous AND-OR Lists", the following text has been added: If the shell is interactive and the asynchronous AND-OR list became a background

Re: $? behaviour after comsub in same command

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

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

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 <mailto:a...@gigawatt.nl>> yazdı:     I am not sure which other ash based shells you were looking at, /bin/sh on NetBSD an

Re: $? behaviour after comsub in same command

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

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

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: probable UB in recently accepted text

On 28/07/2023 21:51, Thorsten Glaser via austin-group-l at The Open Group wrote: Davin McCall via austin-group-l at The Open Group dixit: Since the operand isn't evaluated, there is no null pointer dereference. It is That’s what I told them, but they weren’t convinced. This has been

Re: sh 'continue' shenanigans: negating

On 13/02/2024 22:38, Harald van Dijk via austin-group-l at The Open Group wrote: On 13/02/2024 21:04, Thorsten Glaser via austin-group-l at The Open Group wrote: > After all, the continue utility doesn't know it's called by the ! construct. In ash-derived shells, this basically works beca

Re: sh 'continue' shenanigans: negating

On 13/02/2024 21:04, Thorsten Glaser via austin-group-l at The Open Group wrote: Chet Ramey wrote, according to the list archive ontinue' is a builtin; continue has a return status; !' says to negate it. It seems easy to come to the conclusion that the script should return 1. Yes, I can see

Re: sh 'continue' shenanigans: negating

On 14/02/2024 06:16, Oğuz wrote: On Wed, Feb 14, 2024 at 8:47 AM Harald van Dijk wrote: POSIX specifies: > The value of the special parameter '?' shall be set to n, an unsigned decimal integer, or to the exit status of the last command executed if n is not specified. In your example, n is

Re: sh 'continue' shenanigans: negating

On 14/02/2024 05:06, Oğuz via austin-group-l at The Open Group wrote: On Tuesday, February 13, 2024, Chet Ramey via austin-group-l at The Open Group > wrote: `continue' is a builtin; continue has a return status; `!' says to negate it. It seems easy

Re: sh 'continue' shenanigans: negating

On 14/02/2024 07:54, Oğuz wrote: On Wed, Feb 14, 2024 at 9:58 AM Harald van Dijk wrote: The test script with 'return'? I mean this one: for x in y; do ! continue done echo $? Ah, thanks for the clarification. I still do not see the same results as you (I still see a