There is a command line util (MacOS "say")* that I wish to use fork-exec'd from
my own program and send data to it via a socket created by socketpair().
Unfortunately "say" behaves differently depending on whether its stdin is
attached to a tty or not (and there's no cmd line option to prevent this).
With the former it'll speak after every newline, with the latter not until it
gets an EOF and I'd rather not do a fork-exec for each individual word or
phrase that needs to be spoken.

So my question is - is there a way to set up a pipe or socketpair** so that
it appears to be a tty from the exec'd programs point of view, eg ttyname()
returns non null?

* The MacOS speech API is Objective-C only and completely obtuse.

** Yes I know about the master-slave ptm,pts approach and I have done that in
the past but its complete overkill for this purpose.

Thanks for any help

In article <vh9vgr$5bb$1@dont-email.me>, <Muttley@dastardlyhq.com> wrote:
>There is a command line util (MacOS "say")* that I wish to use fork-exec'd from
>my own program and send data to it via a socket created by socketpair().
>Unfortunately "say" behaves differently depending on whether its stdin is
>attached to a tty or not (and there's no cmd line option to prevent this).
>With the former it'll speak after every newline, with the latter not until it
>gets an EOF and I'd rather not do a fork-exec for each individual word or
>phrase that needs to be spoken.
>
>So my question is - is there a way to set up a pipe or socketpair** so that
>it appears to be a tty from the exec'd programs point of view, eg ttyname()
>returns non null?

I think the short answer to your question is: No.

There's no way to directly do what you want in a clean way.

Thus, all we have is kludgey workarounds. And I'm sure you've got plenty
of your own kludgey workarounds; you don't need any more from me.

That said, if was me, I'd use Expect. A few lines of Expect would do it,
such that I could send text to the process and the process would think they
were coming from a tty. In fact, if you don't want to learn Expect (i.e.,
Tcl) just for this project, I think just using "unbuffer -p" (unbuffer is a
program that comes with the Expect distribution) would do it for you.

If you want a more integrated Expect solution, there is a way to embed
Expect inside of your C program (i.e., link to it as a DLL instead of via
TCL scripting). I've never done this because I've never had the need, but
it might be closer to what you want.

Another way might be to write an interposer so that you could fool the
"say" program into thinking it was talking to a tty even if it wasn't. I
haven't done any Mac programming in a long time (since my Mac stopped
working), but I think interposers were do-able in the Mac ecosystem.

--
Many North Koreans believe Kim-il-Sung is an "almighty god" who "created
the world" in seven days as a divine spirit millions of years ago, and
came to Earth as a human in 1912 as a messianic figure.

On Sat, 16 Nov 2024 20:51:28 -0000 (UTC)
gazelle@shell.xmission.com (Kenny McCormack) boring babbled:
>In article <vh9vgr$5bb$1@dont-email.me>, <Muttley@dastardlyhq.com> wrote:
>>So my question is - is there a way to set up a pipe or socketpair** so that
>>it appears to be a tty from the exec'd programs point of view, eg ttyname()
>>returns non null?
>
>I think the short answer to your question is: No.
>
>There's no way to directly do what you want in a clean way.
>
>Thus, all we have is kludgey workarounds. And I'm sure you've got plenty
>of your own kludgey workarounds; you don't need any more from me.
>
>That said, if was me, I'd use Expect. A few lines of Expect would do it,
>such that I could send text to the process and the process would think they
>were coming from a tty. In fact, if you don't want to learn Expect (i.e.,
>Tcl) just for this project, I think just using "unbuffer -p" (unbuffer is a
>program that comes with the Expect distribution) would do it for you.

Hmm, both sound pretty kludgey too tbh. As for Tcl , thats a blast from the
past. Does anyone really still use it?

>Another way might be to write an interposer so that you could fool the
>"say" program into thinking it was talking to a tty even if it wasn't. I
>haven't done any Mac programming in a long time (since my Mac stopped
>working), but I think interposers were do-able in the Mac ecosystem.

Not heard of that. Probably simpler just to do master-slave pty stuff in
the end which I may well end up having to do.o

Kind of annoying the developers of "say" didn't consider this scenario. After
all , the whole point of having a command line speech utility is for it to
be controlled by another process, its not much use on its own other than
5 mins of novelty value!

Muttley@DastartdlyHQ.org writes:

> On Sat, 16 Nov 2024 20:51:28 -0000 (UTC)
> gazelle@shell.xmission.com (Kenny McCormack) boring babbled:
>>In article <vh9vgr$5bb$1@dont-email.me>, <Muttley@dastardlyhq.com> wrote:
>>>So my question is - is there a way to set up a pipe or socketpair** so that
>>>it appears to be a tty from the exec'd programs point of view, eg ttyname()
>>>returns non null?
>>
>>I think the short answer to your question is: No.
>>
>>There's no way to directly do what you want in a clean way.
>>
>>Thus, all we have is kludgey workarounds. And I'm sure you've got plenty
>>of your own kludgey workarounds; you don't need any more from me.
>>
>>That said, if was me, I'd use Expect. A few lines of Expect would do it,
>>such that I could send text to the process and the process would think they
>>were coming from a tty. In fact, if you don't want to learn Expect (i.e.,
>>Tcl) just for this project, I think just using "unbuffer -p" (unbuffer is a
>>program that comes with the Expect distribution) would do it for you.
>
> Hmm, both sound pretty kludgey too tbh. As for Tcl , thats a blast from the
> past. Does anyone really still use it?

Hey, software doesn't dusty.

On 2024-11-16, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
> So my question is - is there a way to set up a pipe or socketpair** so that
> it appears to be a tty from the exec'd programs point of view, eg ttyname()
> returns non null?
[...]
> ** Yes I know about the master-slave ptm,pts approach and I have done that in
> the past but its complete overkill for this purpose.

No; you need a master/slave pseudo TTY pair connected to an active
process, which forwards between that and the socketpair or pipe.

Sockets and pipes cannot be given window dressing so that they look
like tty's. When the standard input (or output) of a process is a tty,
and that process cares about it, it will likely try operations like
tcgetattr.

Programs that use stdio standard input are affected by whether the
output is a TTY or not because the standard libraries on Unixes call
isatty() to determine whether the input constitutes an "interactive
device" according to ISO C, and hence whether to make the output fully
buffered.

The GNU C Library has a mechanism to override this, driven by
environment variables, and a wrapper utility callet "stdbuf"
which uses the environment variables to tell a child process
what buffering discipline to use for stdin, stdour or stderr.

So for that one small way in which it matters whether the standard
input or output is a TTY, at least one platform has a solution:
you don't have to fake out a TTY to trick a program into stdout
or stderr line buffering.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

In article <vhca72$i0nn$1@dont-email.me>, <Muttley@DastartdlyHQ.org> wrote:
....
>Kind of annoying the developers of "say" didn't consider this scenario. After
>all , the whole point of having a command line speech utility is for it to
>be controlled by another process, its not much use on its own other than
>5 mins of novelty value!

I assume that their intent is that if you are doing anything remotely
serious, you will use their API. The "say" program was probably a 15 minute
effort by whoever developed the API; I doubt much thought went into it
other than as a quick "proof of concept".

Yes, things like this are annoying.

--
If the automobile had followed the same development cycle as the
computer, a Rolls-Royce today would cost $100, get a million miles to
the gallon, and explode once every few weeks, killing everyone inside.

On Sun, 17 Nov 2024 17:48:23 -0000 (UTC)
Kaz Kylheku <643-408-1753@kylheku.com> boring babbled:
>On 2024-11-16, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
>> So my question is - is there a way to set up a pipe or socketpair** so that
>> it appears to be a tty from the exec'd programs point of view, eg ttyname()
>> returns non null?
>[...]
>> ** Yes I know about the master-slave ptm,pts approach and I have done that
>in
>> the past but its complete overkill for this purpose.
>
>No; you need a master/slave pseudo TTY pair connected to an active
>process, which forwards between that and the socketpair or pipe.

I figured as much but thought I'd ask, you never know.

>Sockets and pipes cannot be given window dressing so that they look
>like tty's. When the standard input (or output) of a process is a tty,
>and that process cares about it, it will likely try operations like
>tcgetattr.

The only think I suspect this util cares about is whether its having a file
redirected into its stdin and uses isatty() to find out. Its behaviour when
injesting a file is to take it all in the speak the lot instead of line by
line. Why I don't know, it would make little to no difference to the output.

On Sun, 17 Nov 2024 18:25:28 -0000 (UTC)
gazelle@shell.xmission.com (Kenny McCormack) boring babbled:
>In article <vhca72$i0nn$1@dont-email.me>, <Muttley@DastartdlyHQ.org> wrote:
>....
>>Kind of annoying the developers of "say" didn't consider this scenario. After
>>all , the whole point of having a command line speech utility is for it to
>>be controlled by another process, its not much use on its own other than
>>5 mins of novelty value!
>
>I assume that their intent is that if you are doing anything remotely
>serious, you will use their API. The "say" program was probably a 15 minute

Quite possibly. Unfortunately apart from core Posix and a few system APIs, all
MacOS APIs these days are Objective-C (and swift), a language few people know
and few - including myself - have the time or inclination to learn given the
amount I'd ever use it.

>effort by whoever developed the API; I doubt much thought went into it
>other than as a quick "proof of concept".

It seems fairly comprehensive tbh.

On 16.11.24 12:26, Muttley@dastardlyhq.com wrote:
> There is a command line util (MacOS "say")* that I wish to use fork-exec'd from
> my own program and send data to it via a socket created by socketpair().
> Unfortunately "say" behaves differently depending on whether its stdin is
> attached to a tty or not (and there's no cmd line option to prevent this).
> With the former it'll speak after every newline, with the latter not until it
> gets an EOF and I'd rather not do a fork-exec for each individual word or
> phrase that needs to be spoken.

On shell level I'm using a program called 'pty' that takes the command
as argument to make it think it has a terminal connection. Say, instead
of calling (forking) your 'say' command you're calling (forking) the
'pty' command with your 'say' command provided as argument. And all the
gory details are kept inside the 'pty'. - I forgot whether 'pty' came
with my Linux system, or whether I downloaded it separately, or whether
I implemented or adapted the version that is published in Stevens' APUE
book (with the source code available online, IIRC). IME it's worthwhile
to have such a tool at hand; it's useful to me for various application
contexts, and the interface is clean, a separate small tool unnecessary
to be merged on source code level, and simple to use.

I've just tried it (on shell level)... (less than 2 minutes effort...)
* Download the APUE examples: http://www.apuebook.com/src.3e.tar.gz
* Enter the pty directory and call "make" to get the 'pty' program
* To test it try, e.g.: "ls", "ls | cat -", and, "./pty ls | cat -"

Disclaimer: I have used 'pty' from shell only, but given what I faintly
recall from the mechanisms documented in Stevens' book I'd expect it to
work transparently also from a fork/exec'ed pipe-connected context.
If you'll try it I'd be interested in feedback, how/whether it works in
your fork/exec context with 'say'.

Janis

>
> So my question is - is there a way to set up a pipe or socketpair** so that
> it appears to be a tty from the exec'd programs point of view, eg ttyname()
> returns non null?
>
> * The MacOS speech API is Objective-C only and completely obtuse.
>
> ** Yes I know about the master-slave ptm,pts approach and I have done that in
> the past but its complete overkill for this purpose.
>
> Thanks for any help
>
>

On Mon, 18 Nov 2024 03:38:01 +0100
Janis Papanagnou <janis_papanagnou@hotmail.com> boring babbled:
>On 16.11.24 12:26, Muttley@dastardlyhq.com wrote:
>> There is a command line util (MacOS "say")* that I wish to use fork-exec'd
>from
>> my own program and send data to it via a socket created by socketpair().
>> Unfortunately "say" behaves differently depending on whether its stdin is
>> attached to a tty or not (and there's no cmd line option to prevent this).
>> With the former it'll speak after every newline, with the latter not until it
>
>> gets an EOF and I'd rather not do a fork-exec for each individual word or
>> phrase that needs to be spoken.
>
>On shell level I'm using a program called 'pty' that takes the command
>as argument to make it think it has a terminal connection. Say, instead
>of calling (forking) your 'say' command you're calling (forking) the
>'pty' command with your 'say' command provided as argument. And all the
>gory details are kept inside the 'pty'. - I forgot whether 'pty' came
>with my Linux system, or whether I downloaded it separately, or whether
>I implemented or adapted the version that is published in Stevens' APUE
>book (with the source code available online, IIRC). IME it's worthwhile
>to have such a tool at hand; it's useful to me for various application
>contexts, and the interface is clean, a separate small tool unnecessary
>to be merged on source code level, and simple to use.

Unfortunately I can't find an equivalent to the pty util on MacOS.

Janis Papanagnou <janis_papanagnou@hotmail.com> writes:
> On 16.11.24 12:26, Muttley@dastardlyhq.com wrote:
>> There is a command line util (MacOS "say")* that I wish to use
>> fork-exec'd from
>> my own program and send data to it via a socket created by socketpair().
>> Unfortunately "say" behaves differently depending on whether its stdin is
>> attached to a tty or not (and there's no cmd line option to prevent this).
>> With the former it'll speak after every newline, with the latter not until it
>> gets an EOF and I'd rather not do a fork-exec for each individual word or
>> phrase that needs to be spoken.
>
> On shell level I'm using a program called 'pty' that takes the command
> as argument to make it think it has a terminal connection.

‘script’ will do the same and already exists on macOS. It likes to write
stdout/stderr to a file as well as its own otuput, but you can use
/dev/null for that.

I had some trouble getting it to play fully nicely with say, but some
fiddling might get the desired effect.

--
https://www.greenend.org.uk/rjk/

On Mon, 18 Nov 2024 09:51:33 +0000
Richard Kettlewell <invalid@invalid.invalid> boring babbled:
>Janis Papanagnou <janis_papanagnou@hotmail.com> writes:
>> On 16.11.24 12:26, Muttley@dastardlyhq.com wrote:
>>> There is a command line util (MacOS "say")* that I wish to use
>>> fork-exec'd from
>>> my own program and send data to it via a socket created by socketpair().
>>> Unfortunately "say" behaves differently depending on whether its stdin is
>>> attached to a tty or not (and there's no cmd line option to prevent this).
>>> With the former it'll speak after every newline, with the latter not until
>it
>>> gets an EOF and I'd rather not do a fork-exec for each individual word or
>>> phrase that needs to be spoken.
>>
>> On shell level I'm using a program called 'pty' that takes the command
>> as argument to make it think it has a terminal connection.
>
>‘script’ will do the same and already exists on macOS. It likes to write
>stdout/stderr to a file as well as its own otuput, but you can use
>/dev/null for that.
>
>I had some trouble getting it to play fully nicely with say, but some
>fiddling might get the desired effect.

Sounds a little bit hacky but I'll have a look at it, cheers.

with <20241117093714.675@kylheku.com> Kaz Kylheku wrote:
> On 2024-11-16, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:

>> So my question is - is there a way to set up a pipe or socketpair**
>> so that it appears to be a tty from the exec'd programs point of
>> view, eg ttyname() returns non null?
*SKIP* [ 18 lines 2 levels deep]
> The GNU C Library has a mechanism to override this, driven by
> environment variables, and a wrapper utility callet "stdbuf" which
> uses the environment variables to tell a child process what buffering
> discipline to use for stdin, stdour or stderr.

Now I understand what's going on (back then I've come to conclusions and
called names (AKA -- I'd been pissed off by 9 out of 12); I was
wrong). But variables? Neither stdbuf(1) nor setbuf(3) give any
directions. What should I read?

*CUT* [ 6 lines 1 level deep]

--
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom

Eric Pozharski <apple.universe@posteo.net> writes:
>with <20241117093714.675@kylheku.com> Kaz Kylheku wrote:
>> On 2024-11-16, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
>
>>> So my question is - is there a way to set up a pipe or socketpair**
>>> so that it appears to be a tty from the exec'd programs point of
>>> view, eg ttyname() returns non null?
>*SKIP* [ 18 lines 2 levels deep]
>> The GNU C Library has a mechanism to override this, driven by
>> environment variables, and a wrapper utility callet "stdbuf" which
>> uses the environment variables to tell a child process what buffering
>> discipline to use for stdin, stdour or stderr.
>
>Now I understand what's going on (back then I've come to conclusions and
>called names (AKA -- I'd been pissed off by 9 out of 12); I was
>wrong). But variables? Neither stdbuf(1) nor setbuf(3) give any
>directions. What should I read?

About 45 seconds of google search resulted in "GLIBC_TUNABLES".

https://www.gnu.org/software/libc/manual/html_node/Tunables.html

On 2024-11-18, Eric Pozharski <apple.universe@posteo.net> wrote:
> with <20241117093714.675@kylheku.com> Kaz Kylheku wrote:
>> On 2024-11-16, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
>
>>> So my question is - is there a way to set up a pipe or socketpair**
>>> so that it appears to be a tty from the exec'd programs point of
>>> view, eg ttyname() returns non null?
> *SKIP* [ 18 lines 2 levels deep]
>> The GNU C Library has a mechanism to override this, driven by
>> environment variables, and a wrapper utility callet "stdbuf" which
>> uses the environment variables to tell a child process what buffering
>> discipline to use for stdin, stdour or stderr.
>
> Now I understand what's going on (back then I've come to conclusions and
> called names (AKA -- I'd been pissed off by 9 out of 12); I was
> wrong). But variables? Neither stdbuf(1) nor setbuf(3) give any
> directions. What should I read?

Firstly, I apologize for my bad here, Eric. This is not done in glibc,
but actually by a preloaded shared library called libstdbuf.so. That
comes from CoreUtils.

I'm not sure where/if the environment variables are documented.

To simulate the action of stdbuf in your own program, you need
to LD_PRELOAD libstdbuf, and set the environment variables,
then execute the target program.

See the files src/stdbuf.c and src/libstdbuf.c in the GNU Coreutils
tree.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

with <20241118123754.282@kylheku.com> Kaz Kylheku wrote:
> On 2024-11-18, Eric Pozharski <apple.universe@posteo.net> wrote:
>> with <20241117093714.675@kylheku.com> Kaz Kylheku wrote:
>>> On 2024-11-16, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com>
>>> wrote:

>>>> So my question is - is there a way to set up a pipe or socketpair**
>>>> so that it appears to be a tty from the exec'd programs point of
>>>> view, eg ttyname() returns non null?
>> *SKIP* [ 18 lines 2 levels deep]
>>> The GNU C Library has a mechanism to override this, driven by
>>> environment variables, and a wrapper utility callet "stdbuf" which
>>> uses the environment variables to tell a child process what
>>> buffering discipline to use for stdin, stdour or stderr.
>> Now I understand what's going on (back then I've come to conclusions
*SKIP* [ 2 lines 2 levels deep]
>> directions. What should I read?
> Firstly, I apologize for my bad here, Eric. This is not done in glibc,
> but actually by a preloaded shared library called libstdbuf.so. That
> comes from CoreUtils.

Well, stdbuf(1) is good enough then.

*CUT* [ 9 lines 1 level deep]

--
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom

In article <vh9vgr$5bb$1@dont-email.me>,
Muttley@dastardlyhq.com writes:
> There is a command line util (MacOS "say")* that I wish to use fork-exec'd from
> my own program and send data to it via a socket created by socketpair().
> Unfortunately "say" behaves differently depending on whether its stdin is
> attached to a tty or not (and there's no cmd line option to prevent this).
> With the former it'll speak after every newline, with the latter not until it
> gets an EOF and I'd rather not do a fork-exec for each individual word or
> phrase that needs to be spoken.
>
> So my question is - is there a way to set up a pipe or socketpair** so that
> it appears to be a tty from the exec'd programs point of view, eg ttyname()
> returns non null?
>
> * The MacOS speech API is Objective-C only and completely obtuse.
>
> ** Yes I know about the master-slave ptm,pts approach and I have done that in
> the past but its complete overkill for this purpose.
>
> Thanks for any help
>
>

Not on a Mac. Use "expect" which does the pts/pty stuff for you.

(on a system where pipes are STREAMS based, it might be possible
to come up with a module that made a pipe pretend on one side to be a tty;
but you'd have to get into some nasty kernel coding to do that)

On Tue, 03 Dec 2024 05:29:51 GMT
rlhamil@smart.net (Richard L. Hamilton) wibbled:
>In article <vh9vgr$5bb$1@dont-email.me>,
> Muttley@dastardlyhq.com writes:
>> There is a command line util (MacOS "say")* that I wish to use fork-exec'd
>from
>> my own program and send data to it via a socket created by socketpair().
>> Unfortunately "say" behaves differently depending on whether its stdin is
>> attached to a tty or not (and there's no cmd line option to prevent this).
>> With the former it'll speak after every newline, with the latter not until
>it
>> gets an EOF and I'd rather not do a fork-exec for each individual word or
>> phrase that needs to be spoken.
>>
>> So my question is - is there a way to set up a pipe or socketpair** so that
>> it appears to be a tty from the exec'd programs point of view, eg ttyname()
>> returns non null?
>>
>> * The MacOS speech API is Objective-C only and completely obtuse.
>>
>> ** Yes I know about the master-slave ptm,pts approach and I have done that
>in
>> the past but its complete overkill for this purpose.
>>
>> Thanks for any help
>>
>>
>
>Not on a Mac. Use "expect" which does the pts/pty stuff for you.
>
>(on a system where pipes are STREAMS based, it might be possible
>to come up with a module that made a pipe pretend on one side to be a tty;
>but you'd have to get into some nasty kernel coding to do that)

I'm wondering on Linux if it would be enough on Linux to spoof ttyname() and
isatty() using LD_PRELOAD. However it seems doing something similar on a Mac
is the usual over complicated Apple hot mess.

rlhamil@smart.net (Richard L. Hamilton) writes:
> (on a system where pipes are STREAMS based, it might be possible to
> come up with a module that made a pipe pretend on one side to be a
> tty; but you'd have to get into some nasty kernel coding to do that)

That seems like more work than just using a pty, which the OP already
ruled out.

--
https://www.greenend.org.uk/rjk/

rlhamil@smart.net (Richard L. Hamilton) writes:
>In article <vh9vgr$5bb$1@dont-email.me>,
> Muttley@dastardlyhq.com writes:
>> There is a command line util (MacOS "say")* that I wish to use fork-exec'd from
>> my own program and send data to it via a socket created by socketpair().
>> Unfortunately "say" behaves differently depending on whether its stdin is
>> attached to a tty or not (and there's no cmd line option to prevent this).
>> With the former it'll speak after every newline, with the latter not until it
>> gets an EOF and I'd rather not do a fork-exec for each individual word or
>> phrase that needs to be spoken.
>>
>> So my question is - is there a way to set up a pipe or socketpair** so that
>> it appears to be a tty from the exec'd programs point of view, eg ttyname()
>> returns non null?
>>
>> * The MacOS speech API is Objective-C only and completely obtuse.
>>
>> ** Yes I know about the master-slave ptm,pts approach and I have done that in
>> the past but its complete overkill for this purpose.
>>
>> Thanks for any help
>>
>>
>
>Not on a Mac. Use "expect" which does the pts/pty stuff for you.
>
>(on a system where pipes are STREAMS based, it might be possible
>to come up with a module that made a pipe pretend on one side to be a tty;
>but you'd have to get into some nasty kernel coding to do that)

SVR4.2 included the 'strtty' streams module to support similar
scenarios, if I recall correctly.

On Tue, 3 Dec 2024 08:20:51 -0000 (UTC), Muttley wrote:

> I'm wondering on Linux if it would be enough on Linux to spoof ttyname()
> and isatty() using LD_PRELOAD. However it seems doing something similar
> on a Mac is the usual over complicated Apple hot mess.

macOS may be a licensee of the “Unix” trademark, but it does not work the
way people expect when they think of the term “Unix”.

On Tue, 3 Dec 2024 20:21:27 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wibbled:
>On Tue, 3 Dec 2024 08:20:51 -0000 (UTC), Muttley wrote:
>
>> I'm wondering on Linux if it would be enough on Linux to spoof ttyname()
>> and isatty() using LD_PRELOAD. However it seems doing something similar
>> on a Mac is the usual over complicated Apple hot mess.
>
>macOS may be a licensee of the “Unix” trademark, but it does not work the
>way people expect when they think of the term “Unix”.

Yes, it certainly has its quirks. Linux is far closer to the unix philosphy
(ignoring systemd) despite not being an official unix.

On Wed, 4 Dec 2024 08:34:30 -0000 (UTC), Muttley wrote:

> Linux is far closer to the unix philosphy (ignoring systemd) ...

Which “unix philosophy” would that be?

In article <vir23n$17csf$5@dont-email.me>,
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>On Wed, 4 Dec 2024 08:34:30 -0000 (UTC), Muttley wrote:
>
>> Linux is far closer to the unix philosphy (ignoring systemd) ...
>
>Which "unix philosophy" would that be?

Wouldn't it be easier to just use Google (or whatever search engine you
favor) to find out what the Unix philosphy is?

--
Debating creationists on the topic of evolution is rather like trying to
play chess with a pigeon --- it knocks the pieces over, craps on the
board, and flies back to its flock to claim victory.

Lawrence D'Oliveiro , dans le message <vir23n$17csf$5@dont-email.me>, a
écrit :
> Which “unix philosophy” would that be?

The one that leads to software that “work the way people expect when they
think of the term “Unix””. I wonder who wrote the expression I quoted.