Chet Ramey wrote, according to the list archive
(hasn’t arrived here yet, probably due to greylisting,
so best don’t Cc me so the mailing list copy will arrive,
or, if you must, Cc a different address of mine, which
will then end up in my normal INBOX):
>ontinue' is a builtin; continue has a
Hi,
I’ve got the following issue, and… yes I can see how the
reporter could come to the conclusion that it should “return”
1, but…
… at what point does “continue” “return”? Where do I stop
operating?
mksh does indeed deviate from all the other shells here, but
I’m puzzled how they’d even
Hi all,
I searched the draft and the tracker, but cannot find *anywhere* how
to determine the limits of off_t. There are no OFF_{MIN,MAX} constants,
nor does sysconf() say anything about it. It cannot be inferred from
sizeof(off_t) either because POSIX does not forbid padding bits, except
for
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.
> If the type of the operand is a variable length array type, the
> operand is evaluated; otherwise, the
https://www.austingroupbugs.net/view.php?id=561#c6085 (the accepted
text) suggests that…
versions, the size is typically in the range 92 to 108. An application
can
deduce the size by using sizeof(((struct sockaddr_un
*)0)->sun_path).
… but I was recently told that attempting that
Eric Blake dixit:
>https://sourceware.org/pipermail/libc-alpha/2023-July/149588.html
Which has:
>There are two user-facing changes:
> * nl_langinfo(CODESET) is "POSIX" instead of "ANSI_X3.4-1968"
DON’T do that. For two reasons:
① "POSIX" is not a codeset. It’s entirely possible, TTBOMK, to
Eric Blake dixit:
>The conclusion in those links appears to be that it is compliant to
>have the 8-bit characters map to wchar_t codepoints that are not valid
Thanks.
>encoding errors. Whether the mapping is to the 0xdcXX or 0xdfXX range
>of reserved codepoints in Unicode is a matter of
Hi,
I get that the POSIX locale must be a single-byte character locale
where all 256 octets are characters. I’ve got a question about the
wide character representation.
Assuming my POSIX locale uses ASCII as encoding, I’ve got the whole
portable character set (and then some) in the first 128
Robert Elz via austin-group-l at The Open Group dixit:
>And of course, that means that even though the >> operator is in Table 1-2
>as one that must be supported, it cannot actually work, as >> is unspecified
>(or even undefined, I forget) on signed values, and POSIX sh arithmetic only
No, only
Geoff Clare via austin-group-l at The Open Group dixit:
>XCU 1.1.2 relates to utilities that "perform complex data manipulation
>using their own procedure and arithmetic languages". So it applies to
>shell arithmetic expansion, but isn't really relevant to simple
>argument parsing by a utility.
Hi,
what’s the POSIX mode behaviour expected when scripts attempt to
use overlong numbers in arguments e.g. to utilities (but possibly
anywhere in XSH)?
Say a script has on a 64-bit system:
test 2 -lt
I found “1.1.2 Concepts Derived from the ISO C Standard” in XSH
Hi,
I was finally able to obtain 202x_d2.1.pdf (waiting helped), and I found
the index rather lacking.
Volume 2 chapter 3 and volume 3 chapter 3 comprise thousands of
individual pages; these should be expanded in the index (so one
can find e.g. printf without resorting to the Index at the end.
Geoff Clare via austin-group-l at The Open Group dixit:
[…]
>data into any other encoding." So I think that change should be
>fine too.
OK. Do I need to file this separately or do you have it on
your list now?
>I assume Δ was originally chosen for use in file format notation
>because it was a
Robert Elz via austin-group-l at The Open Group dixit:
> | The key is that everyone `executes' the partial line after getting EOF,
> | even yash.
>
>This is important, it makes reading from files, and reading from
>strings, work the same way, which avoids the need for everyone to
>supply a
Hi,
I cannot seem to get http://www.opengroup.org/austin/login.html to
work so sorry for not checking if the latest drafts still have this
issue, but:
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html
speaks of “ISO/IEC 646:1991 standard IRV” most of the time, but in
some cases
Geoff Clare via austin-group-l at The Open Group dixit:
>NULL and null are not the same thing. The "null" in "null terminator"
>is a null byte, not a null pointer. There is a definition in XBD
It’s a NUL byte. Conflating the use of the word “null” for the digit
zero, the number zero, the
Christoph Anton Mitterer via austin-group-l at The Open Group dixit:
>IMO it should only be removed if replaced by the base64 utility.
Which of them, GNU base64(1) or BSD b64{en,de}code(1)?
Let POSIX not become a GNU shipping house, please.
Also, uu is standard for clasic eMail attachments.
Hi all,
I got a report https://bugs.launchpad.net/mksh/+bug/2002044 that
the shell(s) don’t abort when executing a script and there is a
read(2) error (either the first block or a subsequent one in the
case of, for example, long, long-running scripts on network file‐
systems). The argument is
Robert Elz via austin-group-l at The Open Group dixit:
>The non existing path version can just be done as:
>
> var=/whatever/path/name # obtained however this path is calculated
> newpath=$(realpath ${var%/*})/${var##*/}
No, because the trailing /name *may* exist (and be a symlink).
Dixi quod…
>But useless as most Android scripts would get mksh’s realpath
>if called without any options…
>
>(some custom Android ROMs add busybox or GNU bash, but that’s
You can also symlink or hardlink realpath to mksh and get its builtin.
That would make which you get consistent ☺
Goodnight,
enh via austin-group-l at The Open Group dixit:
>> OK, I did. Note that we're talking of options for realpath(1), not
>> readlink(1). It looks as if the toybox version (from what I can gather
>> from what I guess from that very stylised code) has no options to realpath
>> at all - and that it
Christoph Anton Mitterer via austin-group-l at The Open Group dixit:
>On Tue, 2022-02-08 at 15:21 -0600, Eric Blake wrote:
>>On Tue, Feb 08, 2022 at 06:53:50AM +0100, Christoph Anton Mitterer via
>>austin-group-l at The Open Group wrote:
>What does that mean in practise... does e.g. Linux/glibc
Robert Elz via austin-group-l at The Open Group dixit:
>But there is a somewhat weird case that the shells (those for which
>this works at all, which is a minority) differ about, that I don't
>Which is correct, and why?
Should that even work?! (mksh is one of the shells in which it doesn’t,
and
Hans Åberg dixit:
>It would be better to use astronomical year numbering.
>
>https://en.wikipedia.org/wiki/Astronomical_year_numbering
Isn’t that just the proleptic Gregorian calendar, as used
by struct tm (tm_year is “years since 1900”) already anyway?
But in the text example I was thinking of
Hi,
I just saw “1 AD” (“anno domini”) in line 70246 of the
current working draft, and I’d like to ask that date+era
specifications do not use the abrahamistic designation (in
English, BC/AD) but the neutral one (BCE/CE, common era).
Thanks in advance,
//mirabilos
--
cool ein Ada Lovelace
Hi Geoff,
>This came up during discussions of bug 1063 and the description has
>been changed to something deliberately vague. It has also been marked
>obsolescent.
I’m normally using the web version for my “what does POSIX say?” lookups
-h
Locate and remember utilities invoked by functions as those
functions are defined (the utilities are normally located when
the function is executed).
Neither mksh nor ksh93 nor GNU bash (the versions I have on my systems)
even have an option remotely like that.
Martijn Dekker dixit:
> Datapoint: AT ksh93 has a C.UTF-8 locale built in which it handles
> internally. I suppose that could be considered a precedent of sorts.
Datapoint:
I proposed to add a C.UTF-8 locale to eglibc via Debian, almost a
decade ago.
Debian’s GNU libc packages have been
Geoff Clare via austin-group-l at The Open Group dixit:
>since the standard requires the POSIX locale to have 256 valid
>single-byte characters.
WTF, how is *that* supposed to be implemented?
I guess I could use ASCII as the first half and map the other
128 to U+EF80‥U+EFFF though (which I have
Steffen Nurpmeso via austin-group-l at The Open Group dixit:
> |This is because m4.opengroup.org runs qmail, the arsehole under the MTAs,
> |which auto-converted the mail from quoted-printable to 8bit, sending it
> |as 8bit even to MTAs that don't offer 8BITMIME (I configured my sendmail
> |not
Joerg Schilling via austin-group-l at The Open Group dixit:
>here is where the original mail ended for me. Interesting that you did get
This is because m4.opengroup.org runs qmail, the arsehole under the MTAs,
which auto-converted the mail from quoted-printable to 8bit, sending it
as 8bit even
Hi *,
I’ve got a report in IRC by a user who spotted a cross-shell difference.
In my opinion, the invocation…
sh -c 'ls() { echo meow; }; exec ls'
… is supposed to output "meow\n and return to the caller with a zero
errorlevel.
Some shells execve() the ls(1) binary instead.
In
32 matches
Mail list logo
