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
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
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
1.
Cheers,
Harald van Dijk
utilities, does know it's called by the !
construct, because the call is wrapped in a function that checks if the
result was negated. But there are other ways to make this work too.
Cheers,
Harald van Dijk
if evaluated, but the expression isn't
evaluated, and is not used in a context that requires a constant
expression, the implementation must accept it.
https://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_109.html
https://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_132.html
Cheers,
Harald van Dijk
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
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
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
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 and FreeBSD
Thanks. I indeed see the same results as you on a recent version of
h, and my own) keep it
that way.
I am not sure which other ash based shells you were looking at, but it
may be worth making sure you are on a current version.
Cheers,
Harald van Dijk
as
sufficiently clear, but does clear up with new wording that regardless
of whether this can be inferred from the current wording of the
standard, this interpretation is the intended one.
Cheers,
Harald van Dijk
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
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
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
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
Based on past experiences, I am assuming the e-mail this is a reply to
was meant to be sent to the list and I am quoting it in full and
replying on the list for that reason.
On 10/03/2023 21:24, Robert Elz wrote:
Date:Fri, 10 Mar 2023 18:13:00 +
From:"Haral
makes sense to them and keep it internally consistent, whether that is
by ignoring what 1629 specifies, or by ignoring what is required for
syntax errors.
There are more issues that make me doubt this is going to be implemented
as written in other shells too, but that's for the other authors to raise.
Cheers,
Harald van Dijk
hells of interactive shells and already
don't in various existing shells (but the extent to which they don't
varies from shell to shell). Rather than make a special exception for
process IDs, could this be made a general rule?
Cheers,
Harald van Dijk
g through that logic, and an implementation that is
indistinguishable from a conforming one is itself conforming.
Cheers,
Harald van Dijk
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 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
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
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
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
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:
|>|> .
ther characters, including U+, must be
encoded using rule 2. GNU iconv is doing what the RFC specifies here.
Cheers,
Harald van Dijk
t introduces another bug.
Cheers,
Harald van Dijk
[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
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
to think carefully about what to do in my shell.
Cheers,
Harald van Dijk
have this way I am wondering
if I am not simply misreading the specification. Am I? If not, does
waiting indefinitely match the intent?
Cheers,
Harald van Dijk
that not all utilities can process
arbitrary binary data. There are many utilities that specify input must
be a text file. One way or another it should be made clear whether that
is a restriction that also applies to command substitutions.
Cheers,
Harald van Dijk
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
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
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
nce of one or more
bytes representing a single graphic symbol or control code" (3
Definitions), with a note that says it corresponds to what C calls a
multi-byte character. Environment variables are not specified to allow
arbitrary bytes.
Cheers,
Harald van Dijk
ally store text as wide strings? If so, it
would be useful if POSIX were to explicitly require this. yash is
written based on the POSIX specification; the fact that they implemented
it like this is a clear indication that such a requirement was not clear
at all to them.
Cheers,
Harald van Dijk
hose allow [^...] but not all of
them treat the ^ in it as negation. Whether they treat it as negation is
what's relevant, not whether they allow it.
Cheers,
Harald van Dijk
as an
operand already means that -c and -- must also be interpreted as operands.
Cheers,
Harald van Dijk
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
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
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
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
aware of in POSIX that
allows this.
Cheers,
Harald van Dijk
tly.
That wouldn't be some unexpected interpretation of any POSIX rule, that
would simply be a bug.
Cheers,
Harald van Dijk
imes it appears on line 2.
Cheers,
Harald van Dijk
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
ied order, which looks like a bug (#2) in those
shells. This can be confirmed by running under 'set -x'.
Bug #1 leads to the output "1 2 1".
Bug #2 leads to the output "2 0 0".
Bug #1 & bug #2 combined leads to the output "2 0 1".
Cheers,
Harald van Dijk
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 rathe
n display and
> write in Display.
Alternatively, "write" could be defined in a way such that writing to a
stream is defined as writing to the file associated with that stream.
Cheers,
Harald van Dijk
P.S.: The fact that the underlying file descriptor of standard output is
fd 1 rath
dent
of that, opens /dev/null for writing and immediately closes it, unless
this is explicitly made unspecified in some section I have missed. In
bash, even in POSIX mode, this runs 'echo hello' with both stdout and
stderr redirected to /dev/null.
Cheers,
Harald van Dijk
specific cases, the optimisation should be
perfectly valid and any reasons why it should or should not be performed
are not of a technical nature.
Cheers,
Harald van Dijk
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
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
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
<ht
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
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
| startu
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 e
are
either seriously deluded, or trolling. I cannot tell which and have no
interest in wasting time figuring it out.
Cheers,
Harald van Dijk
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 exam
: "If the first line
of a file of shell commands starts with the characters "#!", the results
are unspecified."
Cheers,
Harald van Dijk
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 differ
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
tempt to execute it will fail, there are a lot of
shells where command -v gcc returns /bin/gcc, but running gcc actually
executes /usr/bin/gcc instead without reporting any error: this
behaviour is common to bosh, dash and variants (including mine), ksh,
and zsh.
Cheers,
Harald van Dijk
imisation that dash performs here is not permitted by
POSIX. In my shell, a fork of dash, I removed the optimisation for
exactly this reason in 2018.
Cheers,
Harald van Dijk
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
g only one of
'(' or ')' part of the pattern (now pattern_list) rule for readability
reasons, but if you prefer a shorter grammar instead, that makes sense
to me too.
Cheers,
Harald van Dijk
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
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
.
Cheers,
Harald van Dijk
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
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
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
invalid and rejected by bash, and when invoked in
POSIX mode, also rejected by yash and zsh. Should that become valid, or
should that remain an error?
(Accidentally sent only to Geoff, re-sending to the list.)
Cheers,
Harald van Dijk
as UTF-8, the script will needlessly break
when it is run in an ISO-8859-15 environment.
Cheers,
Harald van Dijk
so that an effectively non-interactive subshell starts
to pretend that it is interactive.
Cheers,
Harald van Dijk
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,
On 29/07/2020 16:07, Geoff Clare wrote:
Harald van Dijk wrote, on 29 Jul 2020:
On 29/07/2020 09:45, Geoff Clare wrote:
It's only easy because (most/all?) shells take the easy option and do
a lexical analysis of the command to be substituted.
trap (without -p) in a command substitution
On 31/07/2020 00:10, Harald van Dijk wrote:
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, this must be matchable by bracket expressions.
However, "d" ind
yte sequences (byte sequences that lead to
EILSEQ) that shells in general try to tolerate, and the shell no longer
has the option to decide how to handle invalid patterns (patterns
containing non-existent character classes or collating elements) which
shells in general also aim to tolerate.
Cheers,
Harald van Dijk
[*] I have not investigated whether implementations actually do do this
efficiently.
,
Harald van Dijk
normal, including alias substitution. However,
as parsing $(switch foo in foo) by itself results in a syntax error as
far as POSIX is concerned, shells are permitted to parse the full $(
switch foo in foo) echo ok;; esac ) as a command substitution as an
extension instead. All the results you see in shells appear to me to be
permitted by the standard.
Cheers,
Harald van Dijk
On 19/04/2020 14:32, Koichi Murase wrote:
2020-04-19 21:55 Harald van Dijk :
My reading was that interpretation B must be what is intended, which
is why I had modified my shell, a fork of dash, to change dash's A
behaviour to B in late 2018.
Thank you. Is your shell this https://github.com
On 28/03/2020 16:31, Robert Elz wrote:
Date:Sat, 28 Mar 2020 15:12:48 +
From:Harald van Dijk
Message-ID: <865ce3c3-9976-9de4-1a65-9aebe80b8...@gigawatt.nl>
| Not to disagree with the main point of your message, but printf is
| som
of implementing it myself, but it has
been used often enough in scripts that sometimes I did feel like taking
the easy route and making the scripts use /usr/bin/printf (which on my
system is the GNU coreutils version) rather than fixing up the uses to
use octal escape sequences.
Cheers,
Harald van
treats the second \n
as .
On Wednesday, March 25, 2020 Harald van Dijk wrote:
On 25/03/2020 21:09, shwaresyst wrote:
> If it wasn't in single quotes, then that might be plausible, but I don't
> see it as the int
e standard says or intends to say.
On Wednesday, March 25, 2020 Harald van Dijk wrote:
On 25/03/2020 19:44, shwaresyst wrote:
> The GNU version is more correct, in my opinion, in that the use of n as
> a delim
On 25/03/2020 19:44, shwaresyst wrote:
The GNU version is more correct, in my opinion, in that the use of n as
a delimiter should take precedence over its use as control character
alias with the wording as is. The other versions appear to consider the
BRE as so does not match 'n'.
You have
es match what shells do, and you weren't actually under the impression
that the standard required otherwise, if you merely felt the standard
could be misinterpreted in such a way, ignore my reply.
Cheers,
Harald van Dijk
rminate...".
"Before the shell terminates" is not limited to "before the top level
shell terminates". If a shell terminates, even if it is a subshell that
terminates, any EXIT trap action should be run.
Cheers,
Harald van Dijk
at all.
The one way I can see that would fix this is to mandate limited support
for job ID notation even when job control is disabled, and for scripts
to use that instead of tracking PIDs.
Cheers,
Harald van Dijk
On 13/03/2020 13:10, Chet Ramey wrote:
On 3/12/20 4:21 PM, Harald van Dijk wrote:
On 11/03/2020 17:44, Don Cragun wrote:
Would this issue be resolved if we change the last sentence of the
description section of the return Special Built-In Utility from:
If the shell is not currently
On 15/12/2019 12:38, Robert Elz wrote:
Date:Sat, 14 Dec 2019 14:41:34 +
From:Harald van Dijk
Message-ID: <9cbcf0fd-83d1-b449-cfe8-eafdee14b...@gigawatt.nl>
| This was not an exhaustive list, nor was it intended to be.
Still, if one relies (at all
On 14/12/2019 11:29, Robert Elz wrote:
Date:Fri, 13 Dec 2019 08:57:28 +
From:Harald van Dijk
Message-ID: <9c1e4a98-e557-e5d1-27bc-05e7bbfe5...@gigawatt.nl>
| Pretending such scripts are portable does a disservice to users.
Since the shells yo
On 13/12/2019 00:44, Robert Elz wrote:
Date:Thu, 12 Dec 2019 21:37:55 +
From:Harald van Dijk
Message-ID:
| This change would benefit not just those shells, but also other existing
| shells,
The point of the standard isn't to benefit the shells
in unclosed bracket expressions, by
not requiring re-parsing from the unmatched '['.
Cheers,
Harald van Dijk
,
Harald van Dijk
On 27/10/2019 17:16, Robert Elz wrote:
Date:Sun, 27 Oct 2019 15:44:52 +
From:Harald van Dijk
Message-ID: <01735f8e-c0ef-a1d6-f8d1-258a669d9...@gigawatt.nl>
| This could potentially be useful if the script author knows the command
| will be ex
ands to be forgotten, including
those found through function definitions.
Cheers,
Harald van Dijk
1 - 100 of 191 matches
Mail list logo
