Interesting quote:
Apple stopped shipping GNU Emacs in 2019, but the company still
has a program called mg (?Micro GNU Emacs?). Though it supports
most EMACS commands, it lacks an integrated programming language,
making it what some call an ?ersatz EMACS.?
Why did Apple stop shipping GNU tools like Emacs and Bash? Why did it
give up on Objective C (implemented as part of the GNU Compiler
Collection) after so many years, and replace that with its own
homegrown Swift programming language?
It seems to me, the move away from GNU software has to do with the
adoption of version 3 of the GPL. Something new in that version is
being seen by certain folks in Apple as a threat, where they were
happy to bundle and redistribute software that was licensed under
GPLv2.
Why did Apple stop shipping GNU tools like Emacs and Bash?
I think it needs to execute bash in order for the system to conform
to UNIX03.
On Thu, 29 Oct 2026 15:00:43 +0000, Geoff Clare wrote:
I think it needs to execute bash in order for the system to conform
to UNIX03.
1) I doubt that SuS would include something GNU-specific in their
requirements.
On Thu, 29 Oct 2026 04:56:45 -0000 (UTC), Lawrence D?Oliveiro wrote:
It seems to me, the move away from GNU software has to do with the
adoption of version 3 of the GPL. Something new in that version is being
seen by certain folks in Apple as a threat, where they were happy to
bundle and redistribute software that was licensed under GPLv2.
https://www.gnu.org/licenses/gpl-3.0.en.html
I'm not a lawyer so I cannot figure out this steaming pile of legalese.
On Thu, 29 Oct 2026 15:00:43 +0000, Geoff Clare wrote:
I think it needs to execute bash in order for the system to conform
to UNIX03.
1) I doubt that SuS would include something GNU-specific in their
requirements.
2) Why UNIX03? Why not UNIXV7?
A brief little retrospective on the history of Emacs, on the occasion
of its 50th birthday <https://www.technologyreview.com/2026/10/20/1145399/emacs-turns-50/>.
Before it was reimplemented in Lisp, the original version was written
in TECO, a language that I once heard characterized as bearing a
remarkable resemblance to transmission line noise.
Interesting quote:
Apple stopped shipping GNU Emacs in 2019, but the company still
has a program called mg (?Micro GNU Emacs?). Though it supports
most EMACS commands, it lacks an integrated programming language,
making it what some call an ?ersatz EMACS.?
Why did Apple stop shipping GNU tools like Emacs and Bash? Why did it
give up on Objective C (implemented as part of the GNU Compiler
Collection) after so many years, and replace that with its own
homegrown Swift programming language?
It seems to me, the move away from GNU software has to do with the
adoption of version 3 of the GPL. Something new in that version is
being seen by certain folks in Apple as a threat, where they were
happy to bundle and redistribute software that was licensed under
GPLv2.
On 2026-10-29, rbowman wrote:
On Thu, 29 Oct 2026 04:56:45 -0000 (UTC), Lawrence D?Oliveiro wrote:
It seems to me, the move away from GNU software has to do with the
adoption of version 3 of the GPL. Something new in that version is being >>> seen by certain folks in Apple as a threat, where they were happy to
bundle and redistribute software that was licensed under GPLv2.
https://www.gnu.org/licenses/gpl-3.0.en.html
I'm not a lawyer so I cannot figure out this steaming pile of legalese.
In short, if a corporation is arguing that GPLv3 is a reason not to use software or newer versions under that license, you probably should steer clear of that corporation, that means either they don't intend to honor
the freedoms they need to honor in strong copyleft, or that they're
trying to reserve the right of defeating these freedoms with patent-wrangling.
Or is there something else I've forgotten about?
IIRC GPLv3 was mostly or completely about spelling out what were the
expected implications in GPLv2, but which some corporations, notably
TiVo, managed to circumvent and get away with it.
Lawrence D?Oliveiro wrote:
On Thu, 29 Oct 2026 15:00:43 +0000, Geoff Clare wrote:
I think it needs to execute bash in order for the system to
conform to UNIX03.
1) I doubt that SuS would include something GNU-specific in their
requirements.
What I wrote does not in any way imply that there is something
GNU-specific in SUS.
2) Why UNIX03? Why not UNIXV7?
Because macOS is certified to UNIX03, not UNIXV7.
I liked microEMACS as an alternative to PC vi, in the early 90's,
in a DOS environment.
On Fri, 30 Oct 2026 13:26:19 +0000, Geoff Clare wrote:
Lawrence D?Oliveiro wrote:
On Thu, 29 Oct 2026 15:00:43 +0000, Geoff Clare wrote:
I think it needs to execute bash in order for the system to
conform to UNIX03.
1) I doubt that SuS would include something GNU-specific in their
requirements.
What I wrote does not in any way imply that there is something
GNU-specific in SUS.
Bash is GNU-specific.
2) Why UNIX03? Why not UNIXV7?
Because macOS is certified to UNIX03, not UNIXV7.
Why not the latest version of the spec? Why such an old one? And why
does The Open Group allow this?
Lawrence D?Oliveiro wrote this screed in ALL-CAPS (fixed):
A brief little retrospective on the history of Emacs, on the occasion
of its 50th birthday
<https://www.technologyreview.com/2026/10/20/1145399/emacs-turns-50/>.
Before it was reimplemented in Lisp, the original version was written
in TECO, a language that I once heard characterized as bearing a
remarkable resemblance to transmission line noise.
Interesting quote:
Apple stopped shipping GNU Emacs in 2019, but the company still
has a program called mg (?Micro GNU Emacs?). Though it supports
most EMACS commands, it lacks an integrated programming language,
making it what some call an ?ersatz EMACS.?
I liked microEMACS as an alternative to PC vi, in the early 90's,
in a DOS environment.
Why did Apple stop shipping GNU tools like Emacs and Bash? Why did it
give up on Objective C (implemented as part of the GNU Compiler
Collection) after so many years, and replace that with its own
homegrown Swift programming language?
It seems to me, the move away from GNU software has to do with the
adoption of version 3 of the GPL. Something new in that version is
being seen by certain folks in Apple as a threat, where they were
happy to bundle and redistribute software that was licensed under
GPLv2.
Could be true. Can you still install it in Mac?
On Fri, 30 Oct 2026 13:26:19 +0000, Geoff Clare wrote:
Lawrence D?Oliveiro wrote:
On Thu, 29 Oct 2026 15:00:43 +0000, Geoff Clare wrote:
I think it needs to execute bash in order for the system to
conform to UNIX03.
1) I doubt that SuS would include something GNU-specific in their
requirements.
What I wrote does not in any way imply that there is something
GNU-specific in SUS.
Bash is GNU-specific.
2) Why UNIX03? Why not UNIXV7?
Because macOS is certified to UNIX03, not UNIXV7.
Why not the latest version of the spec? Why such an old one?
And why does The Open Group allow this?
MacOS X's certification also seems to predate the year of "UNIX V7"/SUS4?
Lawrence D?Oliveiro wrote:
On Fri, 30 Oct 2026 13:26:19 +0000, Geoff Clare wrote:
Lawrence D?Oliveiro wrote:
On Thu, 29 Oct 2026 15:00:43 +0000, Geoff Clare wrote:
I think it needs to execute bash in order for the system to
conform to UNIX03.
1) I doubt that SuS would include something GNU-specific in their
requirements.
What I wrote does not in any way imply that there is something
GNU-specific in SUS.
Bash is GNU-specific.
Irrelevant.
SUS does not require any behaviour that is specific to bash.
Everything it requires is also supported by ksh.
2) Why UNIX03? Why not UNIXV7?
Because macOS is certified to UNIX03, not UNIXV7.
Why not the latest version of the spec? Why such an old one?
I assume this is because the reason Apple certified macOS was to
settle the lawsuit over their unlicensed use of the UNIX trademark.
Updating to UNIXV7 would involve a lot of work (although probably
not nearly as much as they had to do to get to UNIX03 conformance).
They don't need to do that work if they can continue to license the
trademark by certifying each new release to UNIX03.
And why does The Open Group allow this?
You would have to ask them that.
IIRC UNIX V7 certification was launched in 2010, although it took
until 2018 before anyone certified.
On Mon, 2 Nov 2026 13:28:38 +0000, Geoff Clare wrote:
Lawrence D?Oliveiro wrote:
On Fri, 30 Oct 2026 13:26:19 +0000, Geoff Clare wrote:
Lawrence D?Oliveiro wrote:
On Thu, 29 Oct 2026 15:00:43 +0000, Geoff Clare wrote:
I think it needs to execute bash in order for the system to
conform to UNIX03.
1) I doubt that SuS would include something GNU-specific in their
requirements.
What I wrote does not in any way imply that there is something
GNU-specific in SUS.
Bash is GNU-specific.
Irrelevant.
SUS does not require any behaviour that is specific to bash.
Then why mention bash specifically in the requirements?
Everything it requires is also supported by ksh.
Why not spell out the specific behaviour that is required, then,
if POSIX isn?t enough?
And why does The Open Group allow this?
You would have to ask them that.
Because they?re just out for the money, that?s why. The ?Unix?
trademark doesn?t mean that much any more, if it?s just a commodity
that can be bought.
I liked microEMACS as an alternative to PC vi, in the early 90's,
in a DOS environment.
Lawrence D?Oliveiro wrote:
On Mon, 2 Nov 2026 13:28:38 +0000, Geoff Clare wrote:
Lawrence D?Oliveiro wrote:
On Fri, 30 Oct 2026 13:26:19 +0000, Geoff Clare wrote:
Lawrence D?Oliveiro wrote:
On Thu, 29 Oct 2026 15:00:43 +0000, Geoff Clare wrote:
I think it needs to execute bash in order for the system to
conform to UNIX03.
1) I doubt that SuS would include something GNU-specific in
their requirements.
What I wrote does not in any way imply that there is something
GNU-specific in SUS.
Bash is GNU-specific.
Irrelevant.
SUS does not require any behaviour that is specific to bash.
Then why mention bash specifically in the requirements?
Bash is not mentioned specifically in UNIX03 / SUSv3 requirements.
(It is mentioned in non-normative rationale, as is ksh.)
Why not spell out the specific behaviour that is required, then,
if POSIX isn?t enough?
You do know that POSIX.1 and (the Base volumes of) SUS are one and
the same standard, right?
And why does The Open Group allow this?
You would have to ask them that.
Because they?re just out for the money, that?s why. The ?Unix?
trademark doesn?t mean that much any more, if it?s just a commodity
that can be bought.
Obtaining UNIX certification requires passing tens of thousands of
tests.
Lawrence D'Oliveiro wrote this screed in ALL-CAPS (fixed):
Interesting quote:
Apple stopped shipping GNU Emacs in 2019, but the company still
has a program called mg ("Micro GNU Emacs"). Though it supports
most EMACS commands, it lacks an integrated programming language,
making it what some call an "ersatz EMACS."
I liked microEMACS as an alternative to PC vi, in the early 90's,
in a DOS environment.
Coherent OS took the "original" microEMACS and added logic to
compile a program and position the cursor to the error line in the
editor.
On Tue, 3 Nov 2026 13:17:46 +0000, Geoff Clare wrote:
Lawrence D?Oliveiro wrote:
On Mon, 2 Nov 2026 13:28:38 +0000, Geoff Clare wrote:
Lawrence D?Oliveiro wrote:
On Fri, 30 Oct 2026 13:26:19 +0000, Geoff Clare wrote:
Lawrence D?Oliveiro wrote:
On Thu, 29 Oct 2026 15:00:43 +0000, Geoff Clare wrote:
I think it needs to execute bash in order for the system to
conform to UNIX03.
1) I doubt that SuS would include something GNU-specific in
their requirements.
What I wrote does not in any way imply that there is something
GNU-specific in SUS.
My point was that of the shells that /bin/sh can be configured to
execute (bash, dash and zsh), bash conforms to UNIX03 but I don't
think dash and zsh do. So if you want conforming behaviour you have >>>>>> to stick with the default configuration (bash).
Bash is GNU-specific.
Irrelevant.
SUS does not require any behaviour that is specific to bash.
Then why mention bash specifically in the requirements?
Bash is not mentioned specifically in UNIX03 / SUSv3 requirements.
(It is mentioned in non-normative rationale, as is ksh.)
Then why did you say ?I think it needs to execute bash in order for
the system to conform to UNIX03?? You were the one who mentioned bash specifically.
On Tue, 3 Nov 2026 21:16:21 -0000 (UTC), John McCue wrote:
Coherent OS took the "original" microEMACS and added logic to
compile a program and position the cursor to the error line in the
editor.
That?s the kind of thing that can be done with a few lines of Lisp by the user in *proper* Emacs. ?
The point of a minmal emacs is to be minimal. To their credit, I
suppose, they haven?t expanded it to be able to read email.
On Tue, 3 Nov 2026 13:17:46 +0000, Geoff Clare wrote:
Lawrence D?Oliveiro wrote:
Then why mention bash specifically in the requirements?
Bash is not mentioned specifically in UNIX03 / SUSv3 requirements.
(It is mentioned in non-normative rationale, as is ksh.)
Then why did you say ?I think it needs to execute bash in order for
the system to conform to UNIX03?? You were the one who mentioned bash specifically.
You do know that POSIX.1 and (the Base volumes of) SUS are one and
the same standard, right?
If the two specs were one and the same, there would not be separate certification for both.
And why does The Open Group allow this?
You would have to ask them that.
Because they?re just out for the money, that?s why. The ?Unix?
trademark doesn?t mean that much any more, if it?s just a commodity
that can be bought.
Obtaining UNIX certification requires passing tens of thousands of
tests.
And the ability to handwave those you didn?t pass. You *do* know,
don?t you, that macOS, as shipped by Apple, is not actually
SUS-compliant?
Lawrence D?Oliveiro wrote:
On Tue, 3 Nov 2026 13:17:46 +0000, Geoff Clare wrote:
Lawrence D?Oliveiro wrote:
Then why mention bash specifically in the requirements?
Bash is not mentioned specifically in UNIX03 / SUSv3 requirements.
(It is mentioned in non-normative rationale, as is ksh.)
Then why did you say ?I think it needs to execute bash in order for
the system to conform to UNIX03?? You were the one who mentioned bash
specifically.
I already explained that earlier in the thread ...
You do know that POSIX.1 and (the Base volumes of) SUS are one and
the same standard, right?
If the two specs were one and the same, there would not be separate
certification for both.
They *are* one and the same ...
Obtaining UNIX certification requires passing tens of thousands of
tests.
And the ability to handwave those you didn?t pass. You *do* know,
don?t you, that macOS, as shipped by Apple, is not actually
SUS-compliant?
Some of the macOS certifications in the past had "temporary waivers"
which are granted for minor non-compliances and last 12 months.
They were always corrected before the next certification.
As it happens, Tahoe had no temporary waivers:
A brief little retrospective on the history of Emacs, on the occasion
of its 50th birthday <https://www.technologyreview.com/2026/10/20/1145399/emacs-turns-50/>.
Before it was reimplemented in Lisp, the original version was written
in TECO, a language that I once heard characterized as bearing a
remarkable resemblance to transmission line noise.
There aren't many packages in the wild today that can claim such
longevity and success.
Well, Unix, of course.
On Wed, 04 Nov 2026 19:19:28 -0800, Daniel wrote:
Lawrence D?Oliveiro <ldo@nz.invalid> writes:
A brief little retrospective on the history of Emacs, on the occasion
of its 50th birthday
<https://www.technologyreview.com/2026/10/20/1145399/emacs-turns-50/>.
Before it was reimplemented in Lisp, the original version was written
in TECO, a language that I once heard characterized as bearing a
remarkable resemblance to transmission line noise.
Fifty years of amazing software, wow. There aren't many packages in the
wild today that can claim such longevity and success. It was roughly
twenty years old when I began using it - and even then it was mature.
Mind blown.
Yeah, emacs blew my mind when I tried to use it. Then I deleted it and install vim.
Lawrence D?Oliveiro <ldo@nz.invalid> writes:
A brief little retrospective on the history of Emacs, on the occasion
of its 50th birthday
<https://www.technologyreview.com/2026/10/20/1145399/emacs-turns-50/>.
Before it was reimplemented in Lisp, the original version was written
in TECO, a language that I once heard characterized as bearing a
remarkable resemblance to transmission line noise.
Fifty years of amazing software, wow. There aren't many packages in the
wild today that can claim such longevity and success. It was roughly
twenty years old when I began using it - and even then it was mature.
On Wed, 4 Nov 2026 14:00:15 +0000, Geoff Clare wrote:
Lawrence D?Oliveiro wrote:
On Tue, 3 Nov 2026 13:17:46 +0000, Geoff Clare wrote:
Lawrence D?Oliveiro wrote:
Then why mention bash specifically in the requirements?
Bash is not mentioned specifically in UNIX03 / SUSv3 requirements.
(It is mentioned in non-normative rationale, as is ksh.)
Then why did you say ?I think it needs to execute bash in order for
the system to conform to UNIX03?? You were the one who mentioned bash
specifically.
I already explained that earlier in the thread ...
You mean, the part where you started talking about ksh as well?
You do know that POSIX.1 and (the Base volumes of) SUS are one and
the same standard, right?
If the two specs were one and the same, there would not be separate
certification for both.
They *are* one and the same ...
Well, POSIX doesn?t mention bash, so why should SUS?
I just rechecked the compliance register for UNIX v03
<https://www.opengroup.org//openbrand/register/xy.htm>
You?ll notice Apple is no longer listed ...
On 5 Nov 2026 03:21:56 GMT, Ted Nolan <tednolan> wrote:
There aren't many packages in the wild today that can claim such
longevity and success.
Well, Unix, of course.
There is not a single line of original Bell Labs/AT&T code in any
current Free software *nix system (BSD or Linux).
AT&T launched a lawsuit to make sure of that.
Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> writes:
On 5 Nov 2026 03:21:56 GMT, Ted Nolan <tednolan> wrote:
There aren't many packages in the wild today that can claim such
longevity and success.
Well, Unix, of course.
There is not a single line of original Bell Labs/AT&T code in any
current Free software *nix system (BSD or Linux).
Nonsense.
AT&T launched a lawsuit to make sure of that.
Which they lost, handily
scott@slp53.sl.home (Scott Lurndal) writes:
Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> writes:
On 5 Nov 2026 03:21:56 GMT, Ted Nolan <tednolan> wrote:
There aren't many packages in the wild today that can claim such
longevity and success.
Well, Unix, of course.
There is not a single line of original Bell Labs/AT&T code in any
current Free software *nix system (BSD or Linux).
Nonsense.
AT&T launched a lawsuit to make sure of that.
Which they lost, handily
My bad, I was referring to the SCO lawsuit. The AT&T
BSD lawsuit resulted in BSD adding additional copyright
text to certain source files crediting AT&T.
From my post on Fri, 30 Oct 2026 13:26:19 +0000:
My point was that of the shells that /bin/sh can be configured
to execute (bash, dash and zsh), bash conforms to UNIX03 but I
don't think dash and zsh do. So if you want conforming behaviour
you have to stick with the default configuration (bash).
POSIX.1 does mention bash, in non-normative rationale, as I said
before.
I just rechecked the compliance register for UNIX v03
<https://www.opengroup.org//openbrand/register/xy.htm>
You?ll notice Apple is no longer listed ...
That's strange. Looks like a glitch on their web site, as it's only
missing from the "umbrella" UNIX03 product standard listing; it's
still there for the individual product standards that comprise
UNIX03:
Internationalized System Calls and Libraries Extd V3
https://www.opengroup.org/openbrand/register/sd.htm
Commands and Utilities V4
https://www.opengroup.org/openbrand/register/cx.htm
C Language V2
https://www.opengroup.org/openbrand/register/lm.htm
Internationalized Terminal Interfaces
https://www.opengroup.org/openbrand/register/uu.htm
The problem (as I see it) is that Unix was originally distributed
for basically the cost of the distribution media. I guess there were restrictions of re-distribution.
Later on AT&T tried to convert it into a for-profit product, but the
cat had already left the barn at that point.
On Wed, 04 Nov 2026 21:09:32 -0700, Don_from_AZ wrote:
I first learned to use Emacs on a Honeywell Multics machine in Phoenix
circa 1980, so apparently only 4 years after it was born. I use it
primarily as an editor, and for some of its packages like "Org Mode".
This post is being written with "Gnus" under Emacs. I have not yet
needed or had occasion to write any Lisp code myself.
I was introduced to it much later in '99 when I started work at a new company and some of the programmers used it. The numbers a laughingly
small today but iirc the emacs installation required about 10 times more disk space than vim. It was an easy decision when you were scrambling for every last MB. True, vim didn't tell fortunes or play go.
I looked into [Emacs] a couple of times, but quickly realized that
we aren't from the same planet.
There also is not a single line of the original Emacs in the current
version.
On 2026-11-05, rbowman <bowman@montana.com> wrote:
On Wed, 04 Nov 2026 21:09:32 -0700, Don_from_AZ wrote:
I first learned to use Emacs on a Honeywell Multics machine in Phoenix
circa 1980, so apparently only 4 years after it was born. I use it
primarily as an editor, and for some of its packages like "Org Mode".
This post is being written with "Gnus" under Emacs. I have not yet
needed or had occasion to write any Lisp code myself.
I was introduced to it much later in '99 when I started work at a new
company and some of the programmers used it. The numbers a laughingly
small today but iirc the emacs installation required about 10 times more
disk space than vim. It was an easy decision when you were scrambling for
every last MB. True, vim didn't tell fortunes or play go.
Eight Megabytes And Constantly Swapping
I looked into it a couple of times, but quickly realized
that we aren't from the same planet.
A text editor should edit text, no more.
On Tue, 3 Nov 2026 21:16:21 -0000 (UTC), John McCue wrote:
Coherent OS took the "original" microEMACS and added logic to
compile a program and position the cursor to the error line in the
editor.
That's the kind of thing that can be done with a few lines of Lisp
by the user in *proper* Emacs.
rbowman <bowman@montana.com> writes:
On Wed, 04 Nov 2026 19:19:28 -0800, Daniel wrote:
Lawrence D?Oliveiro <ldo@nz.invalid> writes:
A brief little retrospective on the history of Emacs, on the occasion
of its 50th birthday
<https://www.technologyreview.com/2026/10/20/1145399/emacs-turns-50/>. >>>> Before it was reimplemented in Lisp, the original version was written
in TECO, a language that I once heard characterized as bearing a
remarkable resemblance to transmission line noise.
Fifty years of amazing software, wow. There aren't many packages in the
wild today that can claim such longevity and success. It was roughly
twenty years old when I began using it - and even then it was mature.
Mind blown.
Yeah, emacs blew my mind when I tried to use it. Then I deleted it and
install vim.
I first learned to use Emacs on a Honeywell Multics machine in Phoenix
circa 1980, so apparently only 4 years after it was born. I use it
primarily as an editor, and for some of its packages like "Org
Mode". This post is being written with "Gnus" under Emacs. I have not
yet needed or had occasion to write any Lisp code myself.
On Thu, 5 Nov 2026 13:53:50 +0000, Geoff Clare wrote:
From my post on Fri, 30 Oct 2026 13:26:19 +0000:
My point was that of the shells that /bin/sh can be configured
to execute (bash, dash and zsh), bash conforms to UNIX03 but I
don't think dash and zsh do. So if you want conforming behaviour
you have to stick with the default configuration (bash).
Which is not true anyway <https://manpages.debian.org/dash(1)>.
POSIX.1 does mention bash, in non-normative rationale, as I said
before.
No, you said ?I think it needs to execute bash in order for the system
to conform to UNIX03?. ?Needs? is hardly ?non-normative? is it?
I just rechecked the compliance register for UNIX v03
<https://www.opengroup.org//openbrand/register/xy.htm>
You?ll notice Apple is no longer listed ...
That's strange. Looks like a glitch on their web site, as it's only
missing from the "umbrella" UNIX03 product standard listing; it's
still there for the individual product standards that comprise
UNIX03:
Internationalized System Calls and Libraries Extd V3
https://www.opengroup.org/openbrand/register/sd.htm
Commands and Utilities V4
https://www.opengroup.org/openbrand/register/cx.htm
C Language V2
https://www.opengroup.org/openbrand/register/lm.htm
Internationalized Terminal Interfaces
https://www.opengroup.org/openbrand/register/uu.htm
These only mention macOS 26 ?Tahoe?, not macOS 27 ?Golden Gate?.
Wasn?t that released several months ago? Hasn?t it passed UNIX
compliance yet? (Or at all?)
Could that be why it was dropped from the register page?
Lawrence D?Oliveiro wrote:
On Thu, 5 Nov 2026 13:53:50 +0000, Geoff Clare wrote:
From my post on Fri, 30 Oct 2026 13:26:19 +0000:
My point was that of the shells that /bin/sh can be configured
to execute (bash, dash and zsh), bash conforms to UNIX03 but I
don't think dash and zsh do. So if you want conforming behaviour
you have to stick with the default configuration (bash).
Which is not true anyway <https://manpages.debian.org/dash(1)>.
It would have been helpful if you pointed to which part of that
web page you are referring to. I assume it is the part that says
"dash is a POSIX-compliant implementation of /bin/sh that aims to
be as small as possible".
Notice that it says POSIX-compliant, not UNIX-compliant.
The difference, as I explained before, is that UNIX conformance
requires the POSIX "XSI Option" to be supported (and others).
One of the XSI requirements is that "echo -n foo" writes "-n foo"
and a newline. With the built-in echo on dash (at least on Debian;
I haven't tried it on macOS) it writes just "foo" (the -n suppresses
the newline). This is allowed for POSIX conformance, but not for
UNIX conformance.
There may well be other ways that dash does not conform to UNIX
(or indeed POSIX, despite Debian's claim) requirements too. I seem
to remember discussions in the Austin Group about it not handling
multibyte characters correctly.
POSIX.1 does mention bash, in non-normative rationale, as I said
before.
No, you said ?I think it needs to execute bash in order for the system
to conform to UNIX03?. ?Needs? is hardly ?non-normative? is it?
You are mixing up two completely separate statements that I made.
"I think it needs to execute bash ..." was a statement of my opinion regarding how macOS needs to be configured in order to conform to
UNIX03.
"POSIX.1 does mention bash, in non-normative rationale" was a statement
of fact about the POSIX.1/SUS standard (backed up with evidence).
I just rechecked the compliance register for UNIX v03
<https://www.opengroup.org//openbrand/register/xy.htm>
You?ll notice Apple is no longer listed ...
That's strange. Looks like a glitch on their web site, as it's only
missing from the "umbrella" UNIX03 product standard listing; it's
still there for the individual product standards that comprise
UNIX03:
Internationalized System Calls and Libraries Extd V3
https://www.opengroup.org/openbrand/register/sd.htm
Commands and Utilities V4
https://www.opengroup.org/openbrand/register/cx.htm
C Language V2
https://www.opengroup.org/openbrand/register/lm.htm
Internationalized Terminal Interfaces
https://www.opengroup.org/openbrand/register/uu.htm
These only mention macOS 26 ?Tahoe?, not macOS 27 ?Golden Gate?.
Wasn?t that released several months ago? Hasn?t it passed UNIX
compliance yet? (Or at all?)
Could that be why it was dropped from the register page?
The previous certifications for Sequoia are still listed with the
Tahoe ones on the above pages. So regardless of what the situation
is with Golden Gate, there wouldn't be any reason to remove the
Tahoe ones from the register.
Still seems like just a glitch to me.
On 11/6/26 06:59, Geoff Clare wrote:
Lawrence D?Oliveiro wrote:
On Thu, 5 Nov 2026 13:53:50 +0000, Geoff Clare wrote:
From my post on Fri, 30 Oct 2026 13:26:19 +0000:
My point was that of the shells that /bin/sh can be configured
to execute (bash, dash and zsh), bash conforms to UNIX03 but I
don't think dash and zsh do. So if you want conforming behaviour
you have to stick with the default configuration (bash).
Which is not true anyway <https://manpages.debian.org/dash(1)>.
It would have been helpful if you pointed to which part of that
web page you are referring to. I assume it is the part that says
"dash is a POSIX-compliant implementation of /bin/sh that aims to
be as small as possible".
Notice that it says POSIX-compliant, not UNIX-compliant.
The difference, as I explained before, is that UNIX conformance
requires the POSIX "XSI Option" to be supported (and others).
One of the XSI requirements is that "echo -n foo" writes "-n foo"
and a newline. With the built-in echo on dash (at least on Debian;
I haven't tried it on macOS) it writes just "foo" (the -n suppresses
the newline). This is allowed for POSIX conformance, but not for
UNIX conformance.
There may well be other ways that dash does not conform to UNIX
(or indeed POSIX, despite Debian's claim) requirements too. I seem
to remember discussions in the Austin Group about it not handling
multibyte characters correctly.
POSIX.1 does mention bash, in non-normative rationale, as I said
before.
No, you said ?I think it needs to execute bash in order for the system
to conform to UNIX03?. ?Needs? is hardly ?non-normative? is it?
You are mixing up two completely separate statements that I made.
"I think it needs to execute bash ..." was a statement of my opinion
regarding how macOS needs to be configured in order to conform to
UNIX03.
"POSIX.1 does mention bash, in non-normative rationale" was a statement
of fact about the POSIX.1/SUS standard (backed up with evidence).
I just rechecked the compliance register for UNIX v03
<https://www.opengroup.org//openbrand/register/xy.htm>
You?ll notice Apple is no longer listed ...
That's strange. Looks like a glitch on their web site, as it's only
missing from the "umbrella" UNIX03 product standard listing; it's
still there for the individual product standards that comprise
UNIX03:
Internationalized System Calls and Libraries Extd V3
https://www.opengroup.org/openbrand/register/sd.htm
Commands and Utilities V4
https://www.opengroup.org/openbrand/register/cx.htm
C Language V2
https://www.opengroup.org/openbrand/register/lm.htm
Internationalized Terminal Interfaces
https://www.opengroup.org/openbrand/register/uu.htm
These only mention macOS 26 ?Tahoe?, not macOS 27 ?Golden Gate?.
Wasn?t that released several months ago? Hasn?t it passed UNIX
compliance yet? (Or at all?)
Could that be why it was dropped from the register page?
The previous certifications for Sequoia are still listed with the
Tahoe ones on the above pages. So regardless of what the situation
is with Golden Gate, there wouldn't be any reason to remove the
Tahoe ones from the register.
Still seems like just a glitch to me.
Linux:
isdev@pingvin:~$ echo foo
foo
isdev@pingvin:~$ echo -n foo
fooisdev@pingvin:~$
Peter Flass <Peter@Iron-Spring.com> writes:
On 11/6/26 06:59, Geoff Clare wrote:
Lawrence D?Oliveiro wrote:
On Thu, 5 Nov 2026 13:53:50 +0000, Geoff Clare wrote:
From my post on Fri, 30 Oct 2026 13:26:19 +0000:
My point was that of the shells that /bin/sh can be configured >>>>> to execute (bash, dash and zsh), bash conforms to UNIX03 but I >>>>> don't think dash and zsh do. So if you want conforming behaviour >>>>> you have to stick with the default configuration (bash).
Which is not true anyway <https://manpages.debian.org/dash(1)>.
It would have been helpful if you pointed to which part of that
web page you are referring to. I assume it is the part that says
"dash is a POSIX-compliant implementation of /bin/sh that aims to
be as small as possible".
Notice that it says POSIX-compliant, not UNIX-compliant.
The difference, as I explained before, is that UNIX conformance
requires the POSIX "XSI Option" to be supported (and others).
One of the XSI requirements is that "echo -n foo" writes "-n foo"
and a newline. With the built-in echo on dash (at least on Debian;
I haven't tried it on macOS) it writes just "foo" (the -n suppresses
the newline). This is allowed for POSIX conformance, but not for
UNIX conformance.
There may well be other ways that dash does not conform to UNIX
(or indeed POSIX, despite Debian's claim) requirements too. I seem
to remember discussions in the Austin Group about it not handling
multibyte characters correctly.
POSIX.1 does mention bash, in non-normative rationale, as I said
before.
No, you said ?I think it needs to execute bash in order for the system >>>> to conform to UNIX03?. ?Needs? is hardly ?non-normative? is it?
You are mixing up two completely separate statements that I made.
"I think it needs to execute bash ..." was a statement of my opinion
regarding how macOS needs to be configured in order to conform to
UNIX03.
"POSIX.1 does mention bash, in non-normative rationale" was a statement
of fact about the POSIX.1/SUS standard (backed up with evidence).
I just rechecked the compliance register for UNIX v03
<https://www.opengroup.org//openbrand/register/xy.htm>
You?ll notice Apple is no longer listed ...
That's strange. Looks like a glitch on their web site, as it's only
missing from the "umbrella" UNIX03 product standard listing; it's
still there for the individual product standards that comprise
UNIX03:
Internationalized System Calls and Libraries Extd V3
https://www.opengroup.org/openbrand/register/sd.htm
Commands and Utilities V4
https://www.opengroup.org/openbrand/register/cx.htm
C Language V2
https://www.opengroup.org/openbrand/register/lm.htm
Internationalized Terminal Interfaces
https://www.opengroup.org/openbrand/register/uu.htm
These only mention macOS 26 ?Tahoe?, not macOS 27 ?Golden Gate?.
Wasn?t that released several months ago? Hasn?t it passed UNIX
compliance yet? (Or at all?)
Could that be why it was dropped from the register page?
The previous certifications for Sequoia are still listed with the
Tahoe ones on the above pages. So regardless of what the situation
is with Golden Gate, there wouldn't be any reason to remove the
Tahoe ones from the register.
Still seems like just a glitch to me.
Linux:
isdev@pingvin:~$ echo foo
foo
isdev@pingvin:~$ echo -n foo
fooisdev@pingvin:~$
There are a dozen different shells for linux. You need
to be more specific about which one you are actually using.
You can determine which shell you are using:
$ echo $0
-ksh
bash(1) by default doesn't start in posix mode:
$ bash
$ echo $0
bash
$ set -o | grep posix
posix off
On 5 Nov 2026 03:21:56 GMT, Ted Nolan <tednolan> wrote:
There aren't many packages in the wild today that can claim such
longevity and success.
Well, Unix, of course.
There is not a single line of original Bell Labs/AT&T code in any
current Free software *nix system (BSD or Linux).
AT&T launched a lawsuit to make sure of that.
On 11/6/26 06:59, Geoff Clare wrote:
Lawrence D?Oliveiro wrote:
On Thu, 5 Nov 2026 13:53:50 +0000, Geoff Clare wrote:
From my post on Fri, 30 Oct 2026 13:26:19 +0000:
My point was that of the shells that /bin/sh can be configured
to execute (bash, dash and zsh), bash conforms to UNIX03 but I
don't think dash and zsh do. So if you want conforming behaviour
you have to stick with the default configuration (bash).
Which is not true anyway <https://manpages.debian.org/dash(1)>.
It would have been helpful if you pointed to which part of that
web page you are referring to. I assume it is the part that says
"dash is a POSIX-compliant implementation of /bin/sh that aims to
be as small as possible".
Notice that it says POSIX-compliant, not UNIX-compliant.
The difference, as I explained before, is that UNIX conformance
requires the POSIX "XSI Option" to be supported (and others).
One of the XSI requirements is that "echo -n foo" writes "-n foo"
and a newline. With the built-in echo on dash (at least on Debian;
I haven't tried it on macOS) it writes just "foo" (the -n suppresses
the newline). This is allowed for POSIX conformance, but not for
UNIX conformance.
There may well be other ways that dash does not conform to UNIX
(or indeed POSIX, despite Debian's claim) requirements too. I seem
to remember discussions in the Austin Group about it not handling
multibyte characters correctly.
POSIX.1 does mention bash, in non-normative rationale, as I said
before.
No, you said ?I think it needs to execute bash in order for the system
to conform to UNIX03?. ?Needs? is hardly ?non-normative? is it?
You are mixing up two completely separate statements that I made.
"I think it needs to execute bash ..." was a statement of my opinion
regarding how macOS needs to be configured in order to conform to
UNIX03.
"POSIX.1 does mention bash, in non-normative rationale" was a statement
of fact about the POSIX.1/SUS standard (backed up with evidence).
I just rechecked the compliance register for UNIX v03
<https://www.opengroup.org//openbrand/register/xy.htm>
You?ll notice Apple is no longer listed ...
That's strange. Looks like a glitch on their web site, as it's only
missing from the "umbrella" UNIX03 product standard listing; it's
still there for the individual product standards that comprise
UNIX03:
Internationalized System Calls and Libraries Extd V3
https://www.opengroup.org/openbrand/register/sd.htm
Commands and Utilities V4
https://www.opengroup.org/openbrand/register/cx.htm
C Language V2
https://www.opengroup.org/openbrand/register/lm.htm
Internationalized Terminal Interfaces
https://www.opengroup.org/openbrand/register/uu.htm
These only mention macOS 26 ?Tahoe?, not macOS 27 ?Golden Gate?.
Wasn?t that released several months ago? Hasn?t it passed UNIX
compliance yet? (Or at all?)
Could that be why it was dropped from the register page?
The previous certifications for Sequoia are still listed with the
Tahoe ones on the above pages. So regardless of what the situation
is with Golden Gate, there wouldn't be any reason to remove the
Tahoe ones from the register.
Still seems like just a glitch to me.
Linux:
isdev@pingvin:~$ echo foo
foo
isdev@pingvin:~$ echo -n foo
fooisdev@pingvin:~$
Peter Flass <Peter@Iron-Spring.com> writes:[...]
Linux:
isdev@pingvin:~$ echo foo
foo
isdev@pingvin:~$ echo -n foo
fooisdev@pingvin:~$
There are a dozen different shells for linux. You need
to be more specific about which one you are actually using.
You can determine which shell you are using:
$ echo $0
-ksh
bash(1) by default doesn't start in posix mode:
$ bash
$ echo $0
bash
$ set -o | grep posix
posix off
Notice that it says POSIX-compliant, not UNIX-compliant.
"I think it needs to execute bash ..." was a statement of my opinion regarding how macOS needs to be configured in order to conform to
UNIX03.
The previous certifications for Sequoia are still listed with the
Tahoe ones on the above pages.
Still seems like just a glitch to me.
Linux:
isdev@pingvin:~$ echo foo
foo
isdev@pingvin:~$ echo -n foo
fooisdev@pingvin:~$
On 2026-11-06, Peter Flass wrote:<snip>
On 11/6/26 06:59, Geoff Clare wrote:
Lawrence D?Oliveiro wrote:
On Thu, 5 Nov 2026 13:53:50 +0000, Geoff Clare wrote:
<snip>The difference, as I explained before, is that UNIX conformance
requires the POSIX "XSI Option" to be supported (and others).
One of the XSI requirements is that "echo -n foo" writes "-n foo"
and a newline. With the built-in echo on dash (at least on Debian;
I haven't tried it on macOS) it writes just "foo" (the -n suppresses
the newline). This is allowed for POSIX conformance, but not for
UNIX conformance.
There may well be other ways that dash does not conform to UNIX
(or indeed POSIX, despite Debian's claim) requirements too. I seem
to remember discussions in the Austin Group about it not handling
multibyte characters correctly.
POSIX.1 does mention bash, in non-normative rationale, as I said
before.
Linux:
isdev@pingvin:~$ echo foo
foo
isdev@pingvin:~$ echo -n foo
fooisdev@pingvin:~$
This is one of the situations where it's wrong to say "Linux" and where calling it e.g. "GNU/Linux" would at least be better (although it'd
*still* miss the key part here, and just get a hint of what the shell
may be, if the "GNU" part isn't being used just to refer to such distributions generically).
What would matter here is which shell is that and which echo is that.
Supressing newline in echo is used by quite a lot of shell scripts
and the '-n' option is normal way to do this on Linux.
On Fri, 6 Nov 2026 21:52:32 -0000 (UTC), Waldek Hebisch wrote:
Supressing newline in echo is used by quite a lot of shell scripts
and the '-n' option is normal way to do this on Linux.
As on every other *nix that uses the GNU userland utilities.
I really cannot imagine anybody wanting a command environment that did
not interpret ?-n? in this way ...
On 2026-11-07, Lawrence D?Oliveiro wrote:
On Fri, 6 Nov 2026 21:52:32 -0000 (UTC), Waldek Hebisch wrote:
Supressing newline in echo is used by quite a lot of shell scripts
and the '-n' option is normal way to do this on Linux.
As on every other *nix that uses the GNU userland utilities.
I really cannot imagine anybody wanting a command environment that did
not interpret ?-n? in this way ...
It is non-standard, and that has implications for portability. However convenient that "-n" option may be where present, is there really a
reason not to use something more portable and conformant? IEEE
1003.1-2008 suggests printf (84381?84383).
Recently I had displeasure to use 'printf' in a Makefile, in my
setup that lead to orgy of quoting.
Nuno Silva <nunojsilva@invalid.invalid> wrote:
On 2026-11-07, Lawrence D?Oliveiro wrote:
On Fri, 6 Nov 2026 21:52:32 -0000 (UTC), Waldek Hebisch wrote:
Supressing newline in echo is used by quite a lot of shell scripts
and the '-n' option is normal way to do this on Linux.
As on every other *nix that uses the GNU userland utilities.
I really cannot imagine anybody wanting a command environment that did
not interpret ?-n? in this way ...
It is non-standard, and that has implications for portability. However
convenient that "-n" option may be where present, is there really a
reason not to use something more portable and conformant? IEEE
1003.1-2008 suggests printf (84381?84383).
Recently I had displeasure to use 'printf' in a Makefile, in my
setup that lead to orgy of quoting. Comparing, cases when
'echo -n' were enough were much simpler.
'echo -n' is standard, AFAIK it is GNU standard and compatible
with Posix.
It seems that only Unix compliance disallows it.
Given long history, widespread use and utility there should be
very strong reason to disallow it. I am not aware of such a
reason.
| Sysop: | Tetrazocine |
|---|---|
| Location: | Melbourne, VIC, Australia |
| Users: | 4 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 234:46:55 |
| Calls: | 222 |
| Files: | 21,513 |
| Messages: | 82,481 |