Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > alt.folklore.computers > #236210 > unrolled thread
| Started by | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| First post | 2026-10-29 04:56 +0000 |
| Last post | 2026-11-05 09:23 +0000 |
| Articles | 20 on this page of 80 — 22 participants |
Back to article view | Back to alt.folklore.computers
Emacs Turns 50 Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-29 04:56 +0000
Re: Emacs Turns 50 Aidan Kehoe <kehoea@parhasard.net> - 2026-10-29 07:30 +0000
bash on macOS (was: Emacs Turns 50) Geoff Clare <geoff@clare.See-My-Signature.invalid> - 2026-10-29 15:00 +0000
Re: bash on macOS (was: Emacs Turns 50) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-29 23:09 +0000
Re: bash on macOS (was: Emacs Turns 50) scott@slp53.sl.home (Scott Lurndal) - 2026-10-30 00:49 +0000
Re: bash on macOS (was: Emacs Turns 50) Geoff Clare <geoff@clare.See-My-Signature.invalid> - 2026-10-30 13:26 +0000
Re: bash on macOS (was: Emacs Turns 50) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-30 22:37 +0000
Re: bash on macOS Nuno Silva <nunojsilva@invalid.invalid> - 2026-10-31 01:06 +0000
Re: bash on macOS Geoff Clare <geoff@clare.See-My-Signature.invalid> - 2026-11-02 13:42 +0000
Re: bash on macOS Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-11-02 20:11 +0000
Re: bash on macOS (was: Emacs Turns 50) Geoff Clare <geoff@clare.See-My-Signature.invalid> - 2026-11-02 13:28 +0000
Re: bash on macOS (was: Emacs Turns 50) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-11-02 20:10 +0000
Re: bash on macOS (was: Emacs Turns 50) Geoff Clare <geoff@clare.See-My-Signature.invalid> - 2026-11-03 13:17 +0000
Re: bash on macOS (was: Emacs Turns 50) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-11-03 20:39 +0000
Re: bash on macOS Nuno Silva <nunojsilva@invalid.invalid> - 2026-11-04 01:02 +0000
Re: bash on macOS (was: Emacs Turns 50) Geoff Clare <geoff@clare.See-My-Signature.invalid> - 2026-11-04 14:00 +0000
Re: bash on macOS (was: Emacs Turns 50) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-11-04 21:41 +0000
Re: bash on macOS (was: Emacs Turns 50) Geoff Clare <geoff@clare.See-My-Signature.invalid> - 2026-11-05 13:53 +0000
Re: bash on macOS (was: Emacs Turns 50) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-11-05 19:00 +0000
Re: bash on macOS (was: Emacs Turns 50) Geoff Clare <geoff@clare.See-My-Signature.invalid> - 2026-11-06 13:59 +0000
Re: bash on macOS Peter Flass <Peter@Iron-Spring.com> - 2026-11-06 07:43 -0700
Re: bash on macOS scott@slp53.sl.home (Scott Lurndal) - 2026-11-06 15:42 +0000
Re: bash on macOS Peter Flass <Peter@Iron-Spring.com> - 2026-11-06 10:48 -0700
Re: bash on macOS Nuno Silva <nunojsilva@invalid.invalid> - 2026-11-06 18:21 +0000
Re: bash on macOS Nuno Silva <nunojsilva@invalid.invalid> - 2026-11-06 18:16 +0000
Re: bash on macOS antispam@fricas.org (Waldek Hebisch) - 2026-11-06 21:52 +0000
Re: bash on macOS Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-11-07 00:35 +0000
Portability of 'echo -n' (was: Re: bash on macOS) Nuno Silva <nunojsilva@invalid.invalid> - 2026-11-07 10:02 +0000
Re: Portability of 'echo -n' antispam@fricas.org (Waldek Hebisch) - 2026-11-07 21:24 +0000
Re: Portability of 'echo -n' Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-11-07 22:25 +0000
Re: Portability of 'echo -n' Nuno Silva <nunojsilva@invalid.invalid> - 2026-11-08 00:25 +0000
Re: Portability of 'echo -n' Geoff Clare <geoff@clare.See-My-Signature.invalid> - 2026-11-09 14:38 +0000
Re: bash on macOS Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-11-06 20:43 +0000
Re: bash on macOS (was: Emacs Turns 50) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-11-06 20:42 +0000
Re: bash on macOS (was: Emacs Turns 50) Geoff Clare <geoff@clare.See-My-Signature.invalid> - 2026-11-09 14:05 +0000
Re: bash on macOS Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-11-09 22:23 +0800
Re: bash on macOS (was: Emacs Turns 50) scott@slp53.sl.home (Scott Lurndal) - 2026-11-09 16:00 +0000
Re: bash on macOS (was: Emacs Turns 50) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-11-09 22:13 +0000
Re: bash on macOS (was: Emacs Turns 50) scott@slp53.sl.home (Scott Lurndal) - 2026-11-10 01:21 +0000
Re: Emacs Turns 50 rbowman <bowman@montana.com> - 2026-10-29 15:51 +0000
Re: Emacs Turns 50 Nuno Silva <nunojsilva@invalid.invalid> - 2026-10-30 12:16 +0000
Re: Emacs Turns 50, gpl is still a bad idea John Levine <johnl@taugh.com> - 2026-10-30 17:49 +0000
Re: Emacs Turns 50, gpl is still a bad idea Nuno Silva <nunojsilva@invalid.invalid> - 2026-10-31 01:13 +0000
Re: Emacs Turns 50, gpl is still a bad idea Tapiro Ubriaco <interwebs.dude@gmail.com> - 2026-10-31 18:45 +0000
macOS Tivoization (was: Re: Emacs Turns 50) Nuno Silva <nunojsilva@invalid.invalid> - 2026-11-01 01:17 +0000
Re: macOS Tivoization (was: Re: Emacs Turns 50) Tapiro Ubriaco <interwebs.dude@gmail.com> - 2026-11-04 12:14 +0000
Re: macOS Tivoization Nuno Silva <nunojsilva@invalid.invalid> - 2026-11-04 15:12 +0000
Re: Emacs Turns 50, gpl is still a bad idea antispam@fricas.org (Waldek Hebisch) - 2026-11-01 15:06 +0000
Re: Emacs Turns 50 Chris Ahlstrom <OFeem1987@teleworm.us> - 2026-10-30 18:24 -0400
Re: Emacs Turns 50 Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-11-09 22:25 +0800
Re: Emacs Turns 50 rbowman <bowman@montana.com> - 2026-11-09 19:58 +0000
Re: Emacs Turns 50 Chris Ahlstrom <OFeem1987@teleworm.us> - 2026-10-30 18:20 -0400
Re: Emacs Turns 50 Bob Eager <throwaway0008@eager.cx> - 2026-10-30 23:45 +0000
Re: Emacs Turns 50 John Bokma <contact@johnbokma.com> - 2026-10-31 15:28 +0100
Re: Emacs Turns 50 Anssi Saari <anssi.saari@usenet.mail.kapsi.fi> - 2026-11-03 17:05 +0200
Re: Emacs Turns 50 John McCue <jmclnx@gmail.com.invalid> - 2026-11-03 21:16 +0000
Re: Emacs Turns 50 Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-11-03 22:22 +0000
Re: Emacs Turns 50 Aidan Kehoe <kehoea@parhasard.net> - 2026-11-04 07:14 +0000
Re: Emacs Turns 50 Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-11-04 08:24 +0000
Re: Emacs Turns 50 John McCue <jmclnx@gmail.com.invalid> - 2026-11-06 01:27 +0000
Re: Emacs Turns 50 Daniel <me@fuhgitabutit.com> - 2026-11-04 19:19 -0800
Re: Emacs Turns 50 ted@loft.tnolan.com (Ted Nolan <tednolan>) - 2026-11-05 03:21 +0000
Re: Emacs Turns 50 Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-11-05 03:33 +0000
Re: Emacs Turns 50 scott@slp53.sl.home (Scott Lurndal) - 2026-11-05 15:04 +0000
Re: Emacs Turns 50 scott@slp53.sl.home (Scott Lurndal) - 2026-11-05 16:13 +0000
Re: Emacs Turns 50 Peter Flass <Peter@Iron-Spring.com> - 2026-11-05 09:26 -0700
Re: Emacs Turns 50 Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-11-05 19:06 +0000
Re: Emacs Turns 50 rbowman <bowman@montana.com> - 2026-11-05 19:38 +0000
Re: Emacs Turns 50 Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-11-05 23:09 +0000
Re: Emacs Turns 50 antispam@fricas.org (Waldek Hebisch) - 2026-11-06 17:59 +0000
Re: Emacs Turns 50 rbowman <bowman@montana.com> - 2026-11-05 03:26 +0000
Re: Emacs Turns 50 Don_from_AZ <djatechNOSPAM@comcast.net.invalid> - 2026-11-04 21:09 -0700
Re: Emacs Turns 50 rbowman <bowman@montana.com> - 2026-11-05 06:51 +0000
Re: Emacs Turns 50 Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-11-05 19:17 +0000
Re: Emacs Turns 50 Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-11-05 22:59 +0000
Re: Emacs Turns 50 Jeroen Belleman <jeroen@nospam.please> - 2026-11-06 00:12 +0100
Re: Emacs Turns 50 Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-11-05 23:24 +0000
Re: Emacs Turns 50 "Kerr-Mudd, John" <admin@127.0.0.1> - 2026-11-08 14:26 +0000
Re: Emacs Turns 50 Daniel <me@fuhgitabutit.com> - 2026-11-05 23:26 -0800
Re: Emacs Turns 50 Bob Eager <throwaway0008@eager.cx> - 2026-11-05 09:23 +0000
Page 2 of 4 — ← Prev page 1 [2] 3 4 Next page →
| From | Peter Flass <Peter@Iron-Spring.com> |
|---|---|
| Date | 2026-11-06 07:43 -0700 |
| Subject | Re: bash on macOS |
| Message-ID | <11ckp2g$2jqjg$2@dont-email.me> |
| In reply to | #236600 |
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:~$
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-11-06 15:42 +0000 |
| Subject | Re: bash on macOS |
| Message-ID | <lzmHS.316762$_pxc.180387@fx17.iad> |
| In reply to | #236602 |
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
[toc] | [prev] | [next] | [standalone]
| From | Peter Flass <Peter@Iron-Spring.com> |
|---|---|
| Date | 2026-11-06 10:48 -0700 |
| Subject | Re: bash on macOS |
| Message-ID | <11cl3so$2ofmm$1@dont-email.me> |
| In reply to | #236605 |
On 11/6/26 08:42, Scott Lurndal wrote: > 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 bash.
[toc] | [prev] | [next] | [standalone]
| From | Nuno Silva <nunojsilva@invalid.invalid> |
|---|---|
| Date | 2026-11-06 18:21 +0000 |
| Subject | Re: bash on macOS |
| Message-ID | <11cl5s7$2nftp$4@dont-email.me> |
| In reply to | #236605 |
On 2026-11-06, Scott Lurndal wrote: > 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 Isn't this just the name of the executable entity through which the shell was execve()d? > bash(1) by default doesn't start in posix mode: > > $ bash > $ echo $0 > bash > $ set -o | grep posix > posix off -- Nuno Silva
[toc] | [prev] | [next] | [standalone]
| From | Nuno Silva <nunojsilva@invalid.invalid> |
|---|---|
| Date | 2026-11-06 18:16 +0000 |
| Subject | Re: bash on macOS |
| Message-ID | <11cl5im$2nftp$3@dont-email.me> |
| In reply to | #236602 |
On 2026-11-06, Peter Flass wrote: > 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:~$ 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. -- Nuno Silva
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-11-06 21:52 +0000 |
| Subject | Re: bash on macOS |
| Message-ID | <11cli6u$2u21d$1@paganini.bofh.team> |
| In reply to | #236611 |
Nuno Silva <nunojsilva@invalid.invalid> wrote:
> On 2026-11-06, Peter Flass wrote:
>
>> 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.
>>>>
<snip>
>> 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.
Both 'bash' and '/bin/sh' (which is actually 'dash'). IIUC each has
'echo' as a builtin command. Also '/bin/echo' (which comes from
GNU coreutils) shows the same behaviour.
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.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-11-07 00:35 +0000 |
| Subject | Re: bash on macOS |
| Message-ID | <11clrnu$3188f$1@dont-email.me> |
| In reply to | #236620 |
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 ...
[toc] | [prev] | [next] | [standalone]
| From | Nuno Silva <nunojsilva@invalid.invalid> |
|---|---|
| Date | 2026-11-07 10:02 +0000 |
| Subject | Portability of 'echo -n' (was: Re: bash on macOS) |
| Message-ID | <11cmsv6$3a9pr$2@dont-email.me> |
| In reply to | #236625 |
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). -- Nuno Silva
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-11-07 21:24 +0000 |
| Subject | Re: Portability of 'echo -n' |
| Message-ID | <11co4v2$37o9q$2@paganini.bofh.team> |
| In reply to | #236635 |
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.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-11-07 22:25 +0000 |
| Subject | Re: Portability of 'echo -n' |
| Message-ID | <11co8ge$3rm07$2@dont-email.me> |
| In reply to | #236655 |
On Sat, 7 Nov 2026 21:24:52 -0000 (UTC), Waldek Hebisch wrote: > Recently I had displeasure to use 'printf' in a Makefile, in my > setup that lead to orgy of quoting. The shell builtin has the “%q” format specifier which automatically handles all quoting of shell specials. OK, I think this is a bash-ism, it’s not supported by (supposedly more vanilla POSIX-conforming) dash ...
[toc] | [prev] | [next] | [standalone]
| From | Nuno Silva <nunojsilva@invalid.invalid> |
|---|---|
| Date | 2026-11-08 00:25 +0000 |
| Subject | Re: Portability of 'echo -n' |
| Message-ID | <11cofi8$3t49f$3@dont-email.me> |
| In reply to | #236655 |
On 2026-11-07, Waldek Hebisch wrote:
> 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.
'echo -n' is standard if it prints "-n" followed by a newline.
«The echo utility writes its arguments to standard output, followed
by a <newline>. If there are no arguments, only the <newline> is
written.» -- POSIX (2008 again, lines 84298–84299)
> 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.
It seems to me that widespread use and long history *is* the very strong
reason not to allow or require it.
--
Nuno Silva
[toc] | [prev] | [next] | [standalone]
| From | Geoff Clare <geoff@clare.See-My-Signature.invalid> |
|---|---|
| Date | 2026-11-09 14:38 +0000 |
| Subject | Re: Portability of 'echo -n' |
| Message-ID | <1h29sm-a9t.ln1@ID-313840.user.individual.net> |
| In reply to | #236655 |
Waldek Hebisch wrote: > '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. "echo -n" suppressing newline is historical BSD behaviour. "echo -n" writing "-n" and a newline is historical System V behaviour (with "\c" on the end of the string suppressing newline). When the POSIX and XPG/SUS standards were developed in the late 1980's and early 1990's, the POSIX.2 authors decided to allow both behaviours, whereas the XPG authors decided to require the System V behaviour. (At the time they were separate standards.) When POSIX.1, POSIX.2 and SUSv2 were merged in 2001, no doubt there was a discussion of whether to keep the System V behaviour when the XSI option is supported. Relaxing the standard to allow both behaviours regardless of whether XSI is supported would have broken long-established uses of echo on XPG and SUSv1/2 conforming systems. Bash supports both behaviours, selectable via the bash-specific "shopt" built-in or via the corresponding BASHOPTS environment variable: $ sh --version | head -n 1 GNU bash, version 5.2.15(1)-release (x86_64-pc-linux-gnu) $ sh -c 'echo -n foo; echo' foo $ env BASHOPTS=xpg_echo sh -c 'echo -n foo' -n foo I don't know whether Apple made xpg_echo the default in their version of bash or if they expect systems (or individual users) to set BASHOPTS if they want a SUS "conforming environment". -- Geoff Clare <netnews@gclare.org.uk>
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-11-06 20:43 +0000 |
| Subject | Re: bash on macOS |
| Message-ID | <11cle5q$2sgsp$2@dont-email.me> |
| In reply to | #236602 |
On Fri, 6 Nov 2026 07:43:28 -0700, Peter Flass wrote: > Linux: > isdev@pingvin:~$ echo foo > foo > isdev@pingvin:~$ echo -n foo > fooisdev@pingvin:~$ That’s not “Linux”. Remember, “Linux” is the kernel. What you’re seeing there is the behaviour of a shell, and you haven’t said which one.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-11-06 20:42 +0000 |
| Subject | Re: bash on macOS (was: Emacs Turns 50) |
| Message-ID | <11cle3q$2sgsp$1@dont-email.me> |
| In reply to | #236600 |
On Fri, 6 Nov 2026 13:59:19 +0000, Geoff Clare wrote: > Notice that it says POSIX-compliant, not UNIX-compliant. After you were insisting they were one and the same? > "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. Given that UNIX03 doesn’t mention bash, that statement doesn’t make any sense. > The previous certifications for Sequoia are still listed with the > Tahoe ones on the above pages. Individual tests, but not on the certification register <https://www.opengroup.org//openbrand/register/xy.htm> > Still seems like just a glitch to me. Five months after Golden Gate was released? Seeing the old version dropped, and the new version (coincidentally, or not) nowhere to be found? Pretty big “glitch”, if you ask me ...
[toc] | [prev] | [next] | [standalone]
| From | Geoff Clare <geoff@clare.See-My-Signature.invalid> |
|---|---|
| Date | 2026-11-09 14:05 +0000 |
| Subject | Re: bash on macOS (was: Emacs Turns 50) |
| Message-ID | <gi09sm-a9t.ln1@ID-313840.user.individual.net> |
| In reply to | #236613 |
Lawrence D’Oliveiro wrote: > On Fri, 6 Nov 2026 13:59:19 +0000, Geoff Clare wrote: > >> Notice that it says POSIX-compliant, not UNIX-compliant. > > After you were insisting they were one and the same? At this point I am going to assume that you are pretending to misunderstand things that I have written to try to get me to provide more and more corrections. I'm not going to play that game any more, sorry. If you genuinely thought that I ever said POSIX-compliant and UNIX-compliant were one and the same thing, I suggest you carefully re-read all of my posts in this thread and you will see that I did not. -- Geoff Clare <netnews@gclare.org.uk>
[toc] | [prev] | [next] | [standalone]
| From | Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> |
|---|---|
| Date | 2026-11-09 22:23 +0800 |
| Subject | Re: bash on macOS |
| Message-ID | <jHkIS.38923$0y32.10288@fx05.ams4> |
| In reply to | #236689 |
On 11/9/2026 10:05 PM, Geoff Clare wrote: > Lawrence D’Oliveiro wrote: > >> On Fri, 6 Nov 2026 13:59:19 +0000, Geoff Clare wrote: >> >>> Notice that it says POSIX-compliant, not UNIX-compliant. >> >> After you were insisting they were one and the same? > > At this point I am going to assume that you are pretending to > misunderstand things that I have written to try to get me to > provide more and more corrections. I'm not going to play that > game any more, sorry. > > If you genuinely thought that I ever said POSIX-compliant and > UNIX-compliant were one and the same thing, I suggest you > carefully re-read all of my posts in this thread and you will > see that I did not. > Dear Geoff, Don't worry about Lawrence. He is just a Python influencer, and contin- ues every conversation until he can show off his Python-skills -- which he doesn't have. Best wishes, and happy not answering Lawrence! -- Johann | email: invalid -> com | http://www.myrkraverk.com/blog/ I'm not from the Internet, I just work there. | via Easynews.com https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:; Federated at https://fed.brid.gy/bsky/myrkraverk.bsky.social
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-11-09 16:00 +0000 |
| Subject | Re: bash on macOS (was: Emacs Turns 50) |
| Message-ID | <N6mIS.3249$Kg3.2186@fx41.iad> |
| In reply to | #236689 |
Geoff Clare <geoff@clare.See-My-Signature.invalid> writes: >Lawrence D’Oliveiro wrote: > >> On Fri, 6 Nov 2026 13:59:19 +0000, Geoff Clare wrote: >> >>> Notice that it says POSIX-compliant, not UNIX-compliant. >> >> After you were insisting they were one and the same? > >At this point I am going to assume that you are pretending to >misunderstand things that I have written to try to get me to >provide more and more corrections. I'm not going to play that >game any more, sorry. LDO is a troll, and has been once since it started posting relatively recently. Best to simply ignore it.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-11-09 22:13 +0000 |
| Subject | Re: bash on macOS (was: Emacs Turns 50) |
| Message-ID | <11ctgie$1lilf$1@dont-email.me> |
| In reply to | #236689 |
On Mon, 9 Nov 2026 14:05:36 +0000, Geoff Clare wrote:
> Lawrence D’Oliveiro wrote:
>
>> On Fri, 6 Nov 2026 13:59:19 +0000, Geoff Clare wrote:
>>
>>> Notice that it says POSIX-compliant, not UNIX-compliant.
>>
>> After you were insisting they were one and the same?
>
> At this point I am going to assume that you are pretending to
> misunderstand things that I have written to try to get me to
> provide more and more corrections. I'm not going to play that
> game any more, sorry.
>
> If you genuinely thought that I ever said POSIX-compliant and
> UNIX-compliant were one and the same thing, I suggest you
> carefully re-read all of my posts in this thread and you will
> see that I did not.
From previous postings:
Lawrence D’Oliveiro wrote:
>
> On Tue, 3 Nov 2026 13:17:46 +0000, Geoff Clare wrote:
>
>> 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, as you can easily verify for yourself
from the front page of SUSv5 ...
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-11-10 01:21 +0000 |
| Subject | Re: bash on macOS (was: Emacs Turns 50) |
| Message-ID | <6kuIS.6525$wY2.3191@fx24.iad> |
| In reply to | #236702 |
Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> writes: >On Mon, 9 Nov 2026 14:05:36 +0000, Geoff Clare wrote: > >> Lawrence D’Oliveiro wrote: >> >>> On Fri, 6 Nov 2026 13:59:19 +0000, Geoff Clare wrote: >>> >>>> Notice that it says POSIX-compliant, not UNIX-compliant. >>> >>> After you were insisting they were one and the same? >> >> At this point I am going to assume that you are pretending to >> misunderstand things that I have written to try to get me to >> provide more and more corrections. I'm not going to play that >> game any more, sorry. >> >> If you genuinely thought that I ever said POSIX-compliant and >> UNIX-compliant were one and the same thing, I suggest you >> carefully re-read all of my posts in this thread and you will >> see that I did not. > >From previous postings: > > Lawrence D’Oliveiro wrote: > > > > On Tue, 3 Nov 2026 13:17:46 +0000, Geoff Clare wrote: > > > >> 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, as you can easily verify for yourself > from the front page of SUSv5 ... You're just digging yourself deeper and deeper. The specs have been the same since TOG(XPG) and POSIX merged decades ago. With the merge, the spec picked up various optional requirements from XPG that means that there are multiple sets of requirements. POSIX requires the base set, while Unix03 requires the base set plus additional optional features. So the spec is the same, but there are multiple certifications available for different subsets of the spec.
[toc] | [prev] | [next] | [standalone]
| From | rbowman <bowman@montana.com> |
|---|---|
| Date | 2026-10-29 15:51 +0000 |
| Message-ID | <nkh8beFinrcU1@mid.individual.net> |
| In reply to | #236210 |
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.
[toc] | [prev] | [next] | [standalone]
Page 2 of 4 — ← Prev page 1 [2] 3 4 Next page →
Back to top | Article view | alt.folklore.computers
csiph-web