Faking a TTY on a pipe/socketpair

[M***@dastardlyhq.com]

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

[Kenny McCormack]

Post by M***@dastardlyhq.com
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.

[M***@DastartdlyHQ.org]

On Sat, 16 Nov 2024 20:51:28 -0000 (UTC)

Post by Kenny McCormack

Post by M***@dastardlyhq.com
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?

Post by Kenny McCormack
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!

[Wolfgang Agnes]

Post by M***@DastartdlyHQ.org
On Sat, 16 Nov 2024 20:51:28 -0000 (UTC)

Post by Kenny McCormack

Post by M***@dastardlyhq.com
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.

[Kenny McCormack]

In article <vhca72$i0nn$***@dont-email.me>, <***@DastartdlyHQ.org> wrote:
...

Post by M***@DastartdlyHQ.org
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.

[M***@DastartdlyHQ.org]

On Sun, 17 Nov 2024 18:25:28 -0000 (UTC)

Post by Kenny McCormack
....

Post by M***@DastartdlyHQ.org
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.

Post by Kenny McCormack
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.

[Kaz Kylheku]

Post by M***@dastardlyhq.com
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?

[...]

Post by M***@dastardlyhq.com
** 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.

[M***@DastartdlyHQ.org]

On Sun, 17 Nov 2024 17:48:23 -0000 (UTC)

Post by Kaz Kylheku

Post by M***@dastardlyhq.com
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?

[...]

Post by M***@dastardlyhq.com
** Yes I know about the master-slave ptm,pts approach and I have done that

in

Post by M***@dastardlyhq.com
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.

Post by Kaz Kylheku
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.

[Eric Pozharski]

Post by Kaz Kylheku

Post by M***@dastardlyhq.com
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]

Post by Kaz Kylheku
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]

[Scott Lurndal]

Post by Eric Pozharski

Post by Kaz Kylheku

Post by M***@dastardlyhq.com
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]

Post by Kaz Kylheku
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

[Kaz Kylheku]

Post by Eric Pozharski

Post by Kaz Kylheku

Post by M***@dastardlyhq.com
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]

Post by Kaz Kylheku
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.

[Eric Pozharski]

Post by Kaz Kylheku

Post by Eric Pozharski

Post by Kaz Kylheku

Post by M***@dastardlyhq.com
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]

Post by Kaz Kylheku
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]

Post by Kaz Kylheku

Post by Eric Pozharski
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]

[Janis Papanagnou]

Post by M***@dastardlyhq.com
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

Post by M***@dastardlyhq.com
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

[M***@DastartdlyHQ.org]

On Mon, 18 Nov 2024 03:38:01 +0100

Post by Janis Papanagnou

Post by M***@dastardlyhq.com
There is a command line util (MacOS "say")* that I wish to use fork-exec'd

from

Post by M***@dastardlyhq.com
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.

[Richard Kettlewell]

Post by Janis Papanagnou

Post by M***@dastardlyhq.com
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.

[M***@DastartdlyHQ.org]

On Mon, 18 Nov 2024 09:51:33 +0000

Post by Janis Papanagnou

Post by M***@dastardlyhq.com
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

Post by Janis Papanagnou

Post by M***@dastardlyhq.com
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.

[Richard L. Hamilton]

Post by M***@dastardlyhq.com
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)

[M***@DastardlyHQ.org]

On Tue, 03 Dec 2024 05:29:51 GMT

Post by Richard L. Hamilton

Post by M***@dastardlyhq.com
There is a command line util (MacOS "say")* that I wish to use fork-exec'd

from

Post by M***@dastardlyhq.com
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

Post by M***@dastardlyhq.com
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

Post by M***@dastardlyhq.com
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.

[Lawrence D'Oliveiro]

Post by M***@DastardlyHQ.org
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”.

[M***@DastardlyHQ.org]

On Tue, 3 Dec 2024 20:21:27 -0000 (UTC)

Post by M***@DastardlyHQ.org
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.

[Lawrence D'Oliveiro]

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

Which “unix philosophy” would that be?

[Kenny McCormack]

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?

[Dan Cross]

Post by Kenny McCormack

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?

Why do people continue to try and engage with Lawrence in good
faith? He's a rather obvious troll.

- Dan C.

[Kenny McCormack]

Post by Dan Cross

Post by Kenny McCormack

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?

Why do people continue to try and engage with Lawrence in good
faith? He's a rather obvious troll.

Yes, well, you make a good point. But it passes the time.

One could argue that I wasn't exactly engaging in good faith.
I was making the point that he wasn't arguing in good faith; his question
is obvious trollery, not a legitimate question. If it *were* a legitimate
question, then Googling would give him his answer. But it isn't, so it
won't.,.

[M***@DastardlyHQ.org]

On Thu, 5 Dec 2024 13:57:20 -0000 (UTC)

Post by Kenny McCormack
is obvious trollery, not a legitimate question. If it *were* a legitimate
question, then Googling would give him his answer. But it isn't, so it
won't.,.

To be fair, if google had the answer to everything no one would ever post on
here again.

[Nicolas George]

Post by Lawrence D'Oliveiro
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.

[M***@DastardlyHQ.org]

On Thu, 5 Dec 2024 02:11:04 -0000 (UTC)

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

Which “unix philosophy” would that be?

The one where init does a single task instead of spreading itself throughout
the system after massive scope creep and hence isn't a huge attack vector for
hackers and a single point of failure, plus doesn't use obtuse binary files for
logging which require tools to read. init needed an upgrade for sure, but
systemd isn't it.

[Lawrence D'Oliveiro]

Post by M***@DastardlyHQ.org
On Thu, 5 Dec 2024 02:11:04 -0000 (UTC)

Post by Lawrence D'Oliveiro

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

Which “unix philosophy” would that be?

The one where init does a single task instead of spreading itself
throughout the system ...

What “single task” did init do?

* Mount filesystems
* Spawn syslog, cron
* Spawn terminal login processes (getty)
* Respawn terminated getty processes
* Monitor other special stuff in inittab
* Spawn random other services, without monitoring their state
* Act as a general catch-all for orphaned processes when they terminate

This was all before systemd came on the scene.

[Scott Lurndal]

Post by M***@DastardlyHQ.org
On Thu, 5 Dec 2024 02:11:04 -0000 (UTC)

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

Which “unix philosophy” would that be?

The one where init does a single task instead of spreading itself
throughout the system ...

What “single task” did init do?

Read a bunch of files and call the shell to execute them
whenever the run-level changed and monitored the resulting
processes for failure.

And reaped zombies.

[M***@DastardlyHQ.org]

On Thu, 5 Dec 2024 20:45:36 -0000 (UTC)

Post by M***@DastardlyHQ.org
On Thu, 5 Dec 2024 02:11:04 -0000 (UTC)

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

Which “unix philosophy” would that be?

The one where init does a single task instead of spreading itself
throughout the system ...

What “single task” did init do?

Boot the system to usable state. You can't have that without filesystems,
terminals or other important system daemons running.

[Lawrence D'Oliveiro]

Post by M***@DastardlyHQ.org
On Thu, 5 Dec 2024 20:45:36 -0000 (UTC)

Post by Lawrence D'Oliveiro
What “single task” did init do?

Boot the system to usable state.

What would you say systemd does that is not related to that?

[John Ames]

On Fri, 6 Dec 2024 20:00:54 -0000 (UTC)

Post by Lawrence D'Oliveiro
What would you say systemd does that is not related to that?

QR codes?

[Scott Lurndal]

Post by John Ames
On Fri, 6 Dec 2024 20:00:54 -0000 (UTC)

Post by Lawrence D'Oliveiro
What would you say systemd does that is not related to that?

QR codes?

DNS. Drives me nuts, the crappy resolver in SystemCrap doesn't
work at all on a LAN which has a DNS server serving the local
domain and forwarding to external DNS resolvers.

[M***@dastardlyhq.com]

On Fri, 6 Dec 2024 20:00:54 -0000 (UTC)

Post by Lawrence D'Oliveiro

Post by M***@DastardlyHQ.org
On Thu, 5 Dec 2024 20:45:36 -0000 (UTC)

Post by Lawrence D'Oliveiro
What “single task” did init do?

Boot the system to usable state.

What would you say systemd does that is not related to that?

Networking, including DNS
Graphics
Logging
systemd-boot

Basically init should start the system, maintain some the running of
some essential daemons and then leave well alone.

[Kenny McCormack]

In article <vj16j0$30r12$***@dont-email.me>, <***@dastardlyhq.com> wrote:
...

Post by M***@dastardlyhq.com

Post by Lawrence D'Oliveiro
What would you say systemd does that is not related to that?

Networking, including DNS
Graphics
Logging
systemd-boot
Basically init should start the system, maintain some the running of
some essential daemons and then leave well alone.

I agree with you. But it underscores a major difference between two very
different ways of thinking about computing, which can be described as
"Unix-think" vs. "Windows-think".

systemd represents nothing so much as the bringing of "Windows-think" to Unix.

If one embraces "Windows-think", then systemd makes complete sense.

In fact, systemd is a lot of like the original goal of MS's "dot net",
which was to put a solid wall between the applications programmer and the
actual operating system.

[M***@dastardlyhq.com]

On Sat, 7 Dec 2024 15:00:50 -0000 (UTC)

Post by Kenny McCormack
....

Post by M***@dastardlyhq.com

Post by Lawrence D'Oliveiro
What would you say systemd does that is not related to that?

Networking, including DNS
Graphics
Logging
systemd-boot
Basically init should start the system, maintain some the running of
some essential daemons and then leave well alone.

I agree with you. But it underscores a major difference between two very
different ways of thinking about computing, which can be described as
"Unix-think" vs. "Windows-think".
systemd represents nothing so much as the bringing of "Windows-think" to Unix.
If one embraces "Windows-think", then systemd makes complete sense.

Yes, I've heard that said before and it does ring true. I guess we should be
thankful that systemd still uses text based config but I wouldn't be surprised
if some Windows like binary registry isn't somewhere on the horizon. Of course
Poettering has worked for MS for a long time so one can see where all his bad
ideas come from.

[Richard L. Hamilton]

Post by M***@dastardlyhq.com
On Sat, 7 Dec 2024 15:00:50 -0000 (UTC)

Post by Kenny McCormack
....

Post by M***@dastardlyhq.com

Post by Lawrence D'Oliveiro
What would you say systemd does that is not related to that?

Networking, including DNS
Graphics
Logging
systemd-boot
Basically init should start the system, maintain some the running of
some essential daemons and then leave well alone.

I agree with you. But it underscores a major difference between two very
different ways of thinking about computing, which can be described as
"Unix-think" vs. "Windows-think".
systemd represents nothing so much as the bringing of "Windows-think" to Unix.
If one embraces "Windows-think", then systemd makes complete sense.

Yes, I've heard that said before and it does ring true. I guess we should be
thankful that systemd still uses text based config but I wouldn't be surprised
if some Windows like binary registry isn't somewhere on the horizon. Of course
Poettering has worked for MS for a long time so one can see where all his bad
ideas come from.j

AIX ("AIX Isn't uniX") has something like a registry, as I recall.

Even on Solaris, although the configuration files may still mostly be text,
there's a tendency toward commands that do the actual configuring. In a way,
that's safer since they can offer sanity checks before changes actually take
effect.

[Janis Papanagnou]

AIX ("AIX Isn't uniX") [...]

Since I've never heard that I was tempted to ask whether that's
true or a joke; a quick look into the Web suggested "Advanced
Interactive eXecutive". - I admit your interpretation is nicer.

Janis

[Kaz Kylheku]

Post by Kenny McCormack
If one embraces "Windows-think", then systemd makes complete sense.

Complete Windows-think would be if systemd ran all services in the same
process, so that all services die if you have to kill it.

[Jim Jackson]

Post by Kenny McCormack
...

Post by M***@dastardlyhq.com

Post by Lawrence D'Oliveiro
What would you say systemd does that is not related to that?

Networking, including DNS
Graphics
Logging
systemd-boot
Basically init should start the system, maintain some the running of
some essential daemons and then leave well alone.

I agree with you. But it underscores a major difference between two very
different ways of thinking about computing, which can be described as
"Unix-think" vs. "Windows-think".
systemd represents nothing so much as the bringing of "Windows-think" to Unix.
If one embraces "Windows-think", then systemd makes complete sense.
In fact, systemd is a lot of like the original goal of MS's "dot net",
which was to put a solid wall between the applications programmer and the
actual operating system.

Having just had a wee look at the Android init process, it looks as if
it attempts to do the same.

[Rainer Weikusat]

Post by John Ames
On Fri, 6 Dec 2024 20:00:54 -0000 (UTC)

Post by Lawrence D'Oliveiro

Post by M***@DastardlyHQ.org
On Thu, 5 Dec 2024 20:45:36 -0000 (UTC)

Post by Lawrence D'Oliveiro
What “single task” did init do?

Boot the system to usable state.

What would you say systemd does that is not related to that?

Networking, including DNS
Graphics
Logging
systemd-boot
Basically init should start the system, maintain some the running of
some essential daemons and then leave well alone.

There's no particular reason why init should implement process
management. That init is the one program which cannot easily be replaced on
a running system, is actually a good reason why it shouldn't.

At least on Linux, arbitrary processes can become so-called subreapers
for their descendant processes (prctl(2), PR_SET_CHILD_SUBREAPER). This
means not only the already specious reason¹ that only init can wait for
processes trying to "break out of process management" by double-forking
isn't really valid anymore.

¹ Well-behaved server programs shouldn't background themselves as whether or not a
particular instance should run in the background depends on the reason
why it was started. Ie, that's a system- and situation-specific policy
decision. Backgrounding can easily be provided by a special tool for
that.

[Richard L. Hamilton]

Post by John Ames
On Fri, 6 Dec 2024 20:00:54 -0000 (UTC)

Post by Lawrence D'Oliveiro

Post by M***@DastardlyHQ.org
On Thu, 5 Dec 2024 20:45:36 -0000 (UTC)

Post by Lawrence D'Oliveiro
What “single task” did init do?

Boot the system to usable state.

What would you say systemd does that is not related to that?

Networking, including DNS
Graphics
Logging
systemd-boot
Basically init should start the system, maintain some the running of
some essential daemons and then leave well alone.

On Solaris 10 and later, svc.startd does most spawning and respawning
and such, and uses a "contract" mechanism to be able to keep track of
and if needed kill off otherwise daemonized processes (sshd needs a
compile time option so it only kills the listening sshd and not the
children handling processes - which need to explicitly break their
"contract", otherwise an admin restarting sshd over ssh will kick
themselves out; but for the vast majority of other code, the contract
mechanism does what one might hope with no modification needed to the
code of what it controls)).

But it still has init, although init does little more than start or
control svc.startd (but you could configure it to start something
outside of the control of svc.startd if you really wanted to).

What's the point of svc.startd there? It with the relevant service
configuration files can handle dependencies among services (processes
or other actions) to be started, starting in parallel any whose
dependencies are satisfied; with sufficient hardware threads, that can
provide faster startup. And it can use the aforementioned contract
mechanism to stay more in control, and will fix simple things by
restarting, albeit not if they keep faulting too rapidly. It interacts
with fault management (which also deals with hardware issues) to
provide a consolidated handing of both daemon and hardware issues, for
greater fault tolerance.

For Solaris systems isolated enough that they didn't need regular security
updates, I've seen uptimes in years, so they're probably doing something
right (that they mostly have ECC RAM helps a lot, too). @home, I seldom
get those uptimes, in part because I don't have UPS for everything. :-)

[Rainer Weikusat]

Post by Lawrence D'Oliveiro

Post by M***@DastardlyHQ.org
On Thu, 5 Dec 2024 02:11:04 -0000 (UTC)

Post by Lawrence D'Oliveiro

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

Which “unix philosophy” would that be?

The one where init does a single task instead of spreading itself
throughout the system ...

What “single task” did init do?
* Mount filesystems
* Spawn syslog, cron
* Spawn terminal login processes (getty)
* Respawn terminated getty processes
* Monitor other special stuff in inittab
* Spawn random other services, without monitoring their state
* Act as a general catch-all for orphaned processes when they terminate
This was all before systemd came on the scene.

Originally, mainly two things: Execute a script to kick off userspace
boot. Call wait in a loop in order to reap zombies.

System V init is somewhat more complicated than that. It has a concept
of numbered run levels and will run a configurable command in response
to runlevel change request. On linux, that's usually the script
/etc/init.d/rc. It also has some process monitoring capabilities: It can
start programs depending on the current runlevel and restart them when
they terminate. This is typically used to run getty processes for real
or virtual terminals and serial lines connected to modems.

Minus some handling of special situations (power failure, ctrl-alt-del
on PCs), that's it. Anything beyond that is done by the rc script.

One could argue that this is already a case of creature feep as process
monitoring and restarting of terminated processes and many other
process invocation management tasks can as well be provided
by dedicated programs. There's no reason to hack all of this (or rather,
some random subset of what could be provided here) into a single
codebase save developer inertia: It's less work to add code to a file
that's already compiled by some build system or to add a new file to a
code base which already has a build system than to create lots of
different, specialized tools.

[Jim Jackson]

Post by M***@DastardlyHQ.org
On Thu, 5 Dec 2024 02:11:04 -0000 (UTC)

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

Which ???unix philosophy??? would that be?

The one where init does a single task instead of spreading itself
throughout the system ...

What ???single task??? did init do?
* Mount filesystems
* Spawn syslog, cron
* Spawn terminal login processes (getty)
* Respawn terminated getty processes
* Monitor other special stuff in inittab
* Spawn random other services, without monitoring their state
* Act as a general catch-all for orphaned processes when they terminate
This was all before systemd came on the scene.

Actually traditional Unix "init" didn't do ALL those things. Most tended
to have the inittab config file. Even busybox's init has.

I can't think of a pre-systemd init that mounted filesystems, or spawned
things like syslog/cron. It ran other programs/systems that did most of
system-bring-up and the process control stuff one of which was SysV
initialise setup. Which, surprize though this might sound to some
people, was, at the time, an improvement on the startup setups that had
been common previously.

[Lawrence D'Oliveiro]

Post by Jim Jackson
Actually traditional Unix "init" didn't do ALL those things.

sysvinit certainly did. That is the usual standard of comparison, is it
not?

[Rainer Weikusat]

Post by Lawrence D'Oliveiro

Post by Jim Jackson
Actually traditional Unix "init" didn't do ALL those things.

sysvinit certainly did. That is the usual standard of comparison, is it
not?

It certainly didn't. sysvinit is a program. There source code is, for example, online
here

https://github.com/slicer69/sysvinit/blob/main/src/init.c

and all this does is execute configurable other programs in a couple of
different ways (mostly respawn, exec once and exec once and wait for it)
in response to runlevel changes.

[Richard Kettlewell]

Post by Jim Jackson

What ???single task??? did init do?
* Mount filesystems
* Spawn syslog, cron
* Spawn terminal login processes (getty)
* Respawn terminated getty processes
* Monitor other special stuff in inittab
* Spawn random other services, without monitoring their state
* Act as a general catch-all for orphaned processes when they terminate
This was all before systemd came on the scene.

Actually traditional Unix "init" didn't do ALL those things. Most
tended to have the inittab config file. Even busybox's init has.

Depends if you mean init=/sbin/init or init=the entire sysvinit system.
If you(plural) are going talk about init systems then you need to agree
terms.

[M***@DastardlyHQ.org]

On Tue, 10 Dec 2024 08:50:20 +0000

Post by Richard Kettlewell

Post by Jim Jackson

What ???single task??? did init do?
* Mount filesystems
* Spawn syslog, cron
* Spawn terminal login processes (getty)
* Respawn terminated getty processes
* Monitor other special stuff in inittab
* Spawn random other services, without monitoring their state
* Act as a general catch-all for orphaned processes when they terminate
This was all before systemd came on the scene.

Actually traditional Unix "init" didn't do ALL those things. Most
tended to have the inittab config file. Even busybox's init has.

Depends if you mean init=/sbin/init or init=the entire sysvinit system.
If you(plural) are going talk about init systems then you need to agree
terms.

Its probably fair to say that because the traditional init system uses
shell scripts and hence can do anything you like they often did. But the
core part should really just be limited to starting the machine and getting
enough things running for a user to log on (or if its a black box to do its
task).

[Jim Jackson]

Post by M***@DastardlyHQ.org
On Tue, 10 Dec 2024 08:50:20 +0000

Post by Richard Kettlewell

Post by Jim Jackson

What ???single task??? did init do?
* Mount filesystems
* Spawn syslog, cron
* Spawn terminal login processes (getty)
* Respawn terminated getty processes
* Monitor other special stuff in inittab
* Spawn random other services, without monitoring their state
* Act as a general catch-all for orphaned processes when they terminate
This was all before systemd came on the scene.

Actually traditional Unix "init" didn't do ALL those things. Most
tended to have the inittab config file. Even busybox's init has.

Depends if you mean init=/sbin/init or init=the entire sysvinit system.
If you(plural) are going talk about init systems then you need to agree
terms.

Yes of course. But he did mention "init" which I take to mean pid 1.

Post by M***@DastardlyHQ.org
Its probably fair to say that because the traditional init system uses
shell scripts and hence can do anything you like they often did. But the
core part should really just be limited to starting the machine and getting
enough things running for a user to log on (or if its a black box to do its
task).

Doesn't have to be shell scripts - init just launched programs, e.g.
getty on serial lines, etc.

I think Android init does quite a bit more.

[Lawrence D'Oliveiro]

But the core part should really just be limited to starting the
machine and getting enough things running for a user to log on (or
if its a black box to do its task).

One thing lacking from sysvinit is, while it can start a service, it
cannot ensure the service was started properly, and it cannot perform
reliable service shutdown. So the job of service management was really
only half-done.

[Rainer Weikusat]

Post by Lawrence D'Oliveiro

But the core part should really just be limited to starting the
machine and getting enough things running for a user to log on (or
if its a black box to do its task).

One thing lacking from sysvinit is, while it can start a service, it
cannot ensure the service was started properly, and it cannot perform
reliable service shutdown. So the job of service management was really
only half-done.

sysvinit has no concept of 'service.'

"Service started properly" is a pointless historical property because
"service was running propery 1ms" ago doesn't mean "service is still
running properly now" (that's one of the classic TOCTOU races everybody
just loves to ignore).

It's unclear what "reliable service shutdown" is supposed to mean. It's
possible to stop a somehow monitored process (not service) reliably (or
sort-of reliably) by killing it if it didn't terminate on its own
within some amount of time after a SIGTERM was sent to it. This works
perfectly with a special-purpose tool for that and doesn't need any
giant wolpertingers implemented with hundredthousands of lines of
overcomplicated C code.

[M***@DastardlyHQ.org]

On Tue, 10 Dec 2024 20:55:05 -0000 (UTC)

Post by Lawrence D'Oliveiro

But the core part should really just be limited to starting the
machine and getting enough things running for a user to log on (or
if its a black box to do its task).

One thing lacking from sysvinit is, while it can start a service, it
cannot ensure the service was started properly, and it cannot perform
reliable service shutdown. So the job of service management was really
only half-done.

It doesn't need to , it can just spawn off a script or some other program
which does that which is entirely inline with the unix philosophy. Something
Poettering never understood.

[Lawrence D'Oliveiro]

Post by M***@DastardlyHQ.org
On Tue, 10 Dec 2024 20:55:05 -0000 (UTC)

Post by Lawrence D'Oliveiro
One thing lacking from sysvinit is, while it can start a service, it
cannot ensure the service was started properly, and it cannot perform
reliable service shutdown. So the job of service management was really
only half-done.

It doesn't need to , it can just spawn off a script or some other
program which does that which is entirely inline with the unix
philosophy.

Which is where the trouble starts.

Post by M***@DastardlyHQ.org
Something Poettering never understood.

Poettering understands that services don’t just to be started, they also
need to be managed and shut down cleanly.

[Jim Jackson]

Post by Lawrence D'Oliveiro

Post by M***@DastardlyHQ.org
On Tue, 10 Dec 2024 20:55:05 -0000 (UTC)

Post by Lawrence D'Oliveiro
One thing lacking from sysvinit is, while it can start a service, it
cannot ensure the service was started properly, and it cannot perform
reliable service shutdown. So the job of service management was really
only half-done.

It doesn't need to , it can just spawn off a script or some other
program which does that which is entirely inline with the unix
philosophy.

Which is where the trouble starts.

Post by M***@DastardlyHQ.org
Something Poettering never understood.

Poettering understands that services don???t just to be started, they also
need to be managed and shut down cleanly.

My God, how did we all manage running services before systemd came along?

[Nicolas George]

Post by Jim Jackson
My God, how did we all manage running services before systemd came along?

Badly, with services that have crashed and nobody noticed for weeks.

Some teams have been working on better replacement for SysV init, but
without the industrial strength of Red Hat they could only stay niche.

[Alexis]

Post by Nicolas George

Post by Jim Jackson
My God, how did we all manage running services before systemd came along?

Badly, with services that have crashed and nobody noticed for weeks.
Some teams have been working on better replacement for SysV init, but
without the industrial strength of Red Hat they could only stay niche.

Jonathan de Boyne Pollard, creator of the Nosh system[a], has written an
article about "known problems with System 5 rc":

https://jdebp.uk/FGA/system-5-rc-problems.html

i've used runit and s6+66 on Void Linux, and on Gentoo am currently
using OpenRC+s6 (the latter for providing user services, which are are
still a work in progress under OpenRC[b]):

https://wiki.gentoo.org/wiki/User:Flexibeast/guides/OpenRC_user_services_via_s6

My own case is certainly niche, though s6 is extensively used for
containers, via the s6-overlay project, which currently has ~3.8k stars
on GitHub:

https://github.com/just-containers/s6-overlay


Alexis.


[a] https://jdebp.uk/Softwares/nosh/

[b] https://github.com/OpenRC/openrc/pull/723

[Nicolas George]

Post by Alexis
My own case is certainly niche, though s6 is extensively used for
containers, via the s6-overlay project, which currently has ~3.8k stars

I am rather pleased to ear that s6 has some success, although I know all the
ill its author thinks of containers.

[Lawrence D'Oliveiro]

Post by Nicolas George
Some teams have been working on better replacement for SysV init, but
without the industrial strength of Red Hat they could only stay niche.

I wonder what you think Red Hat’s business model could be in forcing
competitors to adopt technology they developed without paying for it.

[M***@DastardlyHQ.org]

On Thu, 12 Dec 2024 08:27:39 -0000 (UTC)

Post by Nicolas George
Some teams have been working on better replacement for SysV init, but
without the industrial strength of Red Hat they could only stay niche.

I wonder what you think Red Hat’s business model could be in forcing
competitors to adopt technology they developed without paying for it.

Dead Rat was the darling of the business community for a long time - even more
so once IBM bought it. It was effectively a replacement for Solaris, HP-UX and
AIX. So the other distros thought they needed to follow suite in order to pick
up some of that market. Whether that worked or not I don't know, but its left
us with this legacy of systemd infesting just about every mainstream distro.

[Lawrence D'Oliveiro]

Post by M***@DastardlyHQ.org
So the other distros thought they needed to
follow suite in order to pick up some of that market.

Something you pulled out of your fevered imagination, no doubt.

[Jim Jackson]

Post by Nicolas George

Post by Jim Jackson
My God, how did we all manage running services before systemd came along?

Badly, with services that have crashed and nobody noticed for weeks.

People keep saying that. But in my experience services were run as
efficiently as they seem to be run today. Perhaps the team I worked in
knew what it was doing :-)

[Lawrence D'Oliveiro]

Post by Jim Jackson

Post by Nicolas George

Post by Jim Jackson
My God, how did we all manage running services before systemd came along?

Badly, with services that have crashed and nobody noticed for weeks.

People keep saying that. But in my experience services were run as
efficiently as they seem to be run today. Perhaps the team I worked in
knew what it was doing :-)

How many custom services were you running on a single machine, just out of
curiosity?

[Jim Jackson]

Post by Lawrence D'Oliveiro

Post by Jim Jackson

Post by Nicolas George

Post by Jim Jackson
My God, how did we all manage running services before systemd came along?

Badly, with services that have crashed and nobody noticed for weeks.

People keep saying that. But in my experience services were run as
efficiently as they seem to be run today. Perhaps the team I worked in
knew what it was doing :-)

How many custom services were you running on a single machine, just out of
curiosity?

What do you mean by custom? There were database services, web-based
services, information servers other than web all running on 2 big
servers. The infrastructure services (file servers, DNS, NTP, DHCP,
boot servers, automatic backup etc etc) were split between 2 servers
with backup and failover. not sure how you'd classify our mail service,
as infrastructure or custom, but it was far from bog-standard.

[Lawrence D'Oliveiro]

Post by Jim Jackson

Post by Lawrence D'Oliveiro

Post by Jim Jackson

Post by Nicolas George

Post by Jim Jackson
My God, how did we all manage running services before systemd came along?

Badly, with services that have crashed and nobody noticed for weeks.

People keep saying that. But in my experience services were run as
efficiently as they seem to be run today. Perhaps the team I worked in
knew what it was doing :-)

How many custom services were you running on a single machine, just out
of curiosity?

What do you mean by custom?

Code that you had to write substantially from scratch, as opposed to
configuring standard DBMS, Web, directory, MTA, DNS etc.

I ask because the standard services will already have their startup
requirements worked out, because your own would require you to create your
own startup scripts. Which is where the trouble would often start, with
sysvinit.

[Jim Jackson]

Post by Lawrence D'Oliveiro

Post by Jim Jackson

Post by Lawrence D'Oliveiro

Post by Jim Jackson

Post by Nicolas George

Post by Jim Jackson
My God, how did we all manage running services before systemd came along?

Badly, with services that have crashed and nobody noticed for weeks.

People keep saying that. But in my experience services were run as
efficiently as they seem to be run today. Perhaps the team I worked in
knew what it was doing :-)

How many custom services were you running on a single machine, just out
of curiosity?

What do you mean by custom?

Code that you had to write substantially from scratch, as opposed to
configuring standard DBMS, Web, directory, MTA, DNS etc.

Ok I've done specific network monitoring stuff from scratch - back in
the day, when SNMP was a new thing. But it was easier to control than
other stuff because I (and a couple of others) wrote it - we knew it -
so what's difficult? We even transitioned it from pre-SYS-V init to
SYS-V init, and I remember no difficulties.

Post by Lawrence D'Oliveiro
I ask because the standard services will already have their startup
requirements worked out, because your own would require you to create your
own startup scripts. Which is where the trouble would often start, with
sysvinit.

[Lawrence D'Oliveiro]

Post by Jim Jackson
Ok I've done specific network monitoring stuff from scratch - back in
the day, when SNMP was a new thing. But it was easier to control than
other stuff because I (and a couple of others) wrote it - we knew it -
so what's difficult? We even transitioned it from pre-SYS-V init to
SYS-V init, and I remember no difficulties.

Anything with this <https://www.phoronix.com/news/Facebook-systemd-2018>
level of complexity?

[M***@DastardlyHQ.org]

On Wed, 11 Dec 2024 22:26:56 -0000 (UTC)

Post by Lawrence D'Oliveiro

Post by M***@DastardlyHQ.org
On Tue, 10 Dec 2024 20:55:05 -0000 (UTC)

Post by Lawrence D'Oliveiro
One thing lacking from sysvinit is, while it can start a service, it
cannot ensure the service was started properly, and it cannot perform
reliable service shutdown. So the job of service management was really
only half-done.

It doesn't need to , it can just spawn off a script or some other
program which does that which is entirely inline with the unix
philosophy.

Which is where the trouble starts.

The trouble is with any support scripts, not with init. I've written a
number of init scripts with a lot of surrounding logic. God knows how I'd
do that with systemd short of just getting it to call the exact same script
which rather defeats the purpose of having systemd.

Post by Lawrence D'Oliveiro

Post by M***@DastardlyHQ.org
Something Poettering never understood.

Poettering understands that services don’t just to be started, they also
need to be managed and shut down cleanly.

Poettering created the wrong solution to the wrong problem.

[Lawrence D'Oliveiro]

Post by M***@DastardlyHQ.org
On Wed, 11 Dec 2024 22:26:56 -0000 (UTC)

Post by Lawrence D'Oliveiro

Post by M***@DastardlyHQ.org
It doesn't need to , it can just spawn off a script or some other
program which does that which is entirely inline with the unix
philosophy.

Which is where the trouble starts.

The trouble is with any support scripts, not with init. I've written a
number of init scripts with a lot of surrounding logic.

I’m sure you have. Which means you are familiar with the wholesale copying
and pasting of boilerplate from one script to the next. “What does this
bit do?” “Don’t bother thinking too hard, just stick it in, just in case.”

Post by M***@DastardlyHQ.org
God knows how I'd do that with systemd ...

Figure out what the directives do (they’re all documented), and which
settings will achieve the result you want. Most of the time, your service
file will be very simple and very short, since all the common cases are
already covered.

“Simple things should be simple, and complex things should be possible.”
-- Alan Kay

He was talking about GUI design, but the same applies to systemd. And to a
lot of other popular *nix software, while we’re at it.

Post by M***@DastardlyHQ.org

Post by Lawrence D'Oliveiro
Poettering understands that services don’t just to be started, they al
so need to be managed and shut down cleanly.

Poettering created the wrong solution to the wrong problem.

Lots of sysadmins, and distro maintainers, and developers of service apps,
disagree.

Think of how simple it is to log error messages now: systemd automatically
captures stderr, and shows it in your service status and in the journal.

[M***@DastardlyHQ.org]

On Thu, 12 Dec 2024 22:31:50 -0000 (UTC)

Post by M***@DastardlyHQ.org
The trouble is with any support scripts, not with init. I've written a
number of init scripts with a lot of surrounding logic.

I’m sure you have. Which means you are familiar with the wholesale copying
and pasting of boilerplate from one script to the next. “What does this
bit do?” “Don’t bother thinking too hard, just stick it in, just in
case.”

Its a few lines of code and usually one just copies a simple rc file and
starts from there.

Post by M***@DastardlyHQ.org
God knows how I'd do that with systemd ...

Figure out what the directives do (they’re all documented), and which

Why TF would I want to have to leanr Yet Another Config Language when in
shell script I have a turing complete language that can do anything with the
system? You might as well say "Don't bother with that car, use this pushbike
instead."

Post by M***@DastardlyHQ.org
Poettering created the wrong solution to the wrong problem.

Lots of sysadmins, and distro maintainers, and developers of service apps,
disagree.

Sheep exist even i open source. That other abortion poetrring wrote pulseaudio
was shoved into every distro until people realised that all it did was
remove the complexity of Alsa and add its own complexity in exchange. And
being built on alsa it simply added another layer and hence delay into the
sound system where you REALLY don't want delays.

Think of how simple it is to log error messages now: systemd automatically
captures stderr, and shows it in your service status and in the journal.

Oh wow, is there no end to its magical abilities!

[John Ames]

On Fri, 13 Dec 2024 10:38:51 -0000 (UTC)

That other abortion poetrring wrote pulseaudio was shoved into every
distro until people realised that all it did was remove the
complexity of Alsa and add its own complexity in exchange. And being
built on alsa it simply added another layer and hence delay into the
sound system where you REALLY don't want delays.

This bears repeating. Why *anybody* decided to trust the judgement of
the person who gave us the jankiest of all the incredibly janky *nix
audio subsystems is beyond comprehension.

[Lawrence D'Oliveiro]

Post by John Ames
This bears repeating. Why *anybody* decided to trust the judgement of
the person who gave us the jankiest of all the incredibly janky *nix
audio subsystems is beyond comprehension.

There was no reason why you had to. You could easily have created your own
distro without any of his code in it, if you wanted to. Or become an
aficionado of one of the existing distros that did exactly that.

Open Source is all about choice. If you can’t stand the thought of people
making different choices from you, you know what you can do.

[Rainer Weikusat]

Post by Lawrence D'Oliveiro

Post by John Ames
This bears repeating. Why *anybody* decided to trust the judgement of
the person who gave us the jankiest of all the incredibly janky *nix
audio subsystems is beyond comprehension.

There was no reason why you had to. You could easily have created your own
distro without any of his code in it, if you wanted to. Or become an
aficionado of one of the existing distros that did exactly that.
Open Source is all about choice. If you can’t stand the thought of people
making different choices from you, you know what you can do.

If these people get paid by $big_name_companies, there's exactly nothing
individuals can do about that. Unless they happen to be rich enough that
they can waste a ton of money on their hobbies and then, they'd still
need to get a competent work force from somewhere.

[M***@dastardlyhq.com]

On Sat, 14 Dec 2024 20:16:08 +0000

Post by Rainer Weikusat

Post by Lawrence D'Oliveiro

Post by John Ames
This bears repeating. Why *anybody* decided to trust the judgement of
the person who gave us the jankiest of all the incredibly janky *nix
audio subsystems is beyond comprehension.

There was no reason why you had to. You could easily have created your own
distro without any of his code in it, if you wanted to. Or become an
aficionado of one of the existing distros that did exactly that.
Open Source is all about choice. If you can’t stand the thought of people
making different choices from you, you know what you can do.

If these people get paid by $big_name_companies, there's exactly nothing
individuals can do about that. Unless they happen to be rich enough that
they can waste a ton of money on their hobbies and then, they'd still
need to get a competent work force from somewhere.

The sort of idiots who make those "why don't you write your own" remarks
probably still live with and are financed by mum and dad so don't see the
issue with spending months rolling your own system. Plus they seem to have
some kind of believe that you shouldn't criticise something unless you have
the ability to replicate it youself which means no one should ever comment on
any music, films, TV, food etc they disliked unless they could make a hollywood
blockbuster, album, whatever themselves. Its a very juvenile attitude.

[Rainer Weikusat]

Post by M***@dastardlyhq.com
On Sat, 14 Dec 2024 20:16:08 +0000

Post by Rainer Weikusat

Post by Lawrence D'Oliveiro

Post by John Ames
This bears repeating. Why *anybody* decided to trust the judgement of
the person who gave us the jankiest of all the incredibly janky *nix
audio subsystems is beyond comprehension.

There was no reason why you had to. You could easily have created your own
distro without any of his code in it, if you wanted to. Or become an
aficionado of one of the existing distros that did exactly that.
Open Source is all about choice. If you can’t stand the thought of people
making different choices from you, you know what you can do.

If these people get paid by $big_name_companies, there's exactly nothing
individuals can do about that. Unless they happen to be rich enough that
they can waste a ton of money on their hobbies and then, they'd still
need to get a competent work force from somewhere.

The sort of idiots who make those "why don't you write your own" remarks
probably still live with and are financed by mum and dad so don't see the
issue with spending months rolling your own system.

I actually did. By the time when systemd started to become a serious
nuisance, I had just started to work on a different product. The
previous had been an (ARM9-based) UTM appliance and I actually wrote an
own init for that. I was determined to avoid doing that again but still
needed more process management than sysvinit + rc provided.

I started this as sort-of a conscious anti-systemd experiment. The idea
was that, whenever I needed some process management feature, I'd write a
(fairly small) C program to provide that and find out how far this would
get me. That was about fifteen years ago. I've meanwhile accumulated 38
of these C program with a total size of 5690 lines of code and that's
enough for all of my process management needs and I'm dealing with some
more complicated stuff then people just running web servers.

This is arguably not open source but the copyright belongs to my
employer. OTOH, if it were, mainstream Linux distributions wouldn't use
it, not the least because many people just love complicated stuff (like
systemd).

Post by M***@dastardlyhq.com
Plus they seem to have some kind of believe that you shouldn't
criticise something unless you have the ability to replicate it
youself which means no one should ever comment on any music, films,
TV, food etc they disliked unless they could make a hollywood
blockbuster, album, whatever themselves. Its a very juvenile attitude.

Indeed.

[M***@DastardlyHQ.org]

On Sun, 15 Dec 2024 21:25:36 +0000

Post by Rainer Weikusat
employer. OTOH, if it were, mainstream Linux distributions wouldn't use
it, not the least because many people just love complicated stuff (like
systemd).

True. Far too many people think complicated = clever. What they don't
understand is that really smart people have the ability to make complicated
stuff simple for the user. Sadly not an ability Poettering has.

[Lawrence D'Oliveiro]

Post by M***@DastardlyHQ.org
Far too many people think complicated = clever.

You mean, clever like struggling with complicated workarounds to clunky,
ancient init systems that don’t actually handle service management very
well, when more modern ones solve long-standing problems in a much simpler
and more elegant fashion?

[M***@DastardlyHQ.org]

On Mon, 16 Dec 2024 19:51:36 -0000 (UTC)

Post by Lawrence D'Oliveiro

Post by M***@DastardlyHQ.org
Far too many people think complicated = clever.

You mean, clever like struggling with complicated workarounds to clunky,
ancient init systems that don’t actually handle service management very
well, when more modern ones solve long-standing problems in a much simpler
and more elegant fashion?

Sure, but we're talking about systemd.

[Lawrence D'Oliveiro]

On Mon, 16 Dec 2024 19:51:36 -0000 (UTC) Lawrence D'Oliveiro

Post by Lawrence D'Oliveiro

Post by M***@DastardlyHQ.org
Far too many people think complicated = clever.

You mean, clever like struggling with complicated workarounds to clunky,
ancient init systems that don’t actually handle service management very
well, when more modern ones solve long-standing problems in a much
simpler and more elegant fashion?

Sure, but we're talking about systemd.

Why, what were you talking about?

[Rainer Weikusat]

Post by Lawrence D'Oliveiro

Post by M***@DastardlyHQ.org
Far too many people think complicated = clever.

You mean, clever like struggling with complicated workarounds to clunky,
ancient init systems that don’t actually handle service management very
well, when more modern ones solve long-standing problems in a much simpler
and more elegant fashion?

The systemd-252 codebase which is used for Debian 12 is composed of
(sloccount) 690,648 lines of code. That's anything but simple.

[John Ames]

On Sat, 14 Dec 2024 01:35:37 -0000 (UTC)

Post by Lawrence D'Oliveiro
There was no reason why you had to. You could easily have created
your own distro without any of his code in it, if you wanted to. Or
become an aficionado of one of the existing distros that did exactly
that.

Have done - been running Devuan since 2016.

Post by Lawrence D'Oliveiro
Open Source is all about choice. If you can’t stand the thought of
people making different choices from you, you know what you can do.

The fact that people are free to make stupid choices does not mean that
other people aren't allowed to call out stupidity where they see it.

[Lawrence D'Oliveiro]

Post by John Ames
The fact that people are free to make stupid choices does not mean that
other people aren't allowed to call out stupidity where they see it.

Notice that all the complaints seem to go in one direction, not the other?
We only see systemd-haters complaining about those using it, you don’t see
systemd users complaining about those who don’t?

[John Ames]

On Mon, 16 Dec 2024 20:15:02 -0000 (UTC)

Post by Lawrence D'Oliveiro
Notice that all the complaints seem to go in one direction, not the
other? We only see systemd-haters complaining about those using it,
you don’t see systemd users complaining about those who don’t?

That would likely be because systemd users are getting what they want,
and aren't being pushed onto sysvinit by distro maintainers.

[Jim Jackson]

Post by Lawrence D'Oliveiro

Post by John Ames
The fact that people are free to make stupid choices does not mean that
other people aren't allowed to call out stupidity where they see it.

Notice that all the complaints seem to go in one direction, not the other?
We only see systemd-haters complaining about those using it, you don???t see
systemd users complaining about those who don???t?

No. But I think some of us get a bit pissed at some people making out
that previous inits were (almost) unworkable - which is palpably false.

[Lawrence D'Oliveiro]

... I think some of us get a bit pissed at some people making out
that previous inits were (almost) unworkable - which is palpably false.

Do you understand what a “strawman” argument is?

[M***@DastardlyHQ.org]

On Tue, 17 Dec 2024 02:37:24 -0000 (UTC)

... I think some of us get a bit pissed at some people making out
that previous inits were (almost) unworkable - which is palpably false.

Do you understand what a “strawman” argument is?

Is it irony week again?

[Lawrence D'Oliveiro]

On Tue, 17 Dec 2024 02:37:24 -0000 (UTC) Lawrence D'Oliveiro

Post by Lawrence D'Oliveiro

... I think some of us get a bit pissed at some people making out that
previous inits were (almost) unworkable - which is palpably false.

Do you understand what a “strawman” argument is?

It’s when you try to tear down a false argument that the other side never
made.

[Richard Kettlewell]

Post by Jim Jackson

Post by Lawrence D'Oliveiro

Post by John Ames
The fact that people are free to make stupid choices does not mean
that other people aren't allowed to call out stupidity where they
see it.

Notice that all the complaints seem to go in one direction, not the
other? We only see systemd-haters complaining about those using it,
you don???t see systemd users complaining about those who don???t?

No. But I think some of us get a bit pissed at some people making out
that previous inits were (almost) unworkable - which is palpably false.

‘Unworkable’ may be an exaggeration, but the practical issues and
functionality gaps were real; even if you didn’t personally experience
them, other people did. I think there were at least ten different
attempts to come up with something better in the free software world
alone. Meanwhile the commercial Unixes largely got their act together
long before Linux did.

Whether systemd was the best possible design, or just the best option
available, is another question, and perhaps more opinion-based.

[Rainer Weikusat]

Post by Lawrence D'Oliveiro

Post by John Ames
The fact that people are free to make stupid choices does not mean that
other people aren't allowed to call out stupidity where they see it.

Notice that all the complaints seem to go in one direction, not the other?
We only see systemd-haters complaining about those using it, you don’t see
systemd users complaining about those who don’t?

Hmm ... what do you think you are doing here?

:-)

[M***@dastardlyhq.com]

On Fri, 13 Dec 2024 07:42:07 -0800

Post by John Ames
On Fri, 13 Dec 2024 10:38:51 -0000 (UTC)

That other abortion poetrring wrote pulseaudio was shoved into every
distro until people realised that all it did was remove the
complexity of Alsa and add its own complexity in exchange. And being
built on alsa it simply added another layer and hence delay into the
sound system where you REALLY don't want delays.

This bears repeating. Why *anybody* decided to trust the judgement of
the person who gave us the jankiest of all the incredibly janky *nix
audio subsystems is beyond comprehension.

Agreed. On a side note, its a shame the original authors of X didn't decide
to do sound too or at least provide an API that others could build extensions
to use because by the time X - or at least X11 - was adopted unix had moved on
from cabinet sized servers to desktop workstations where sound mattered. It
seems odd to me that graphics and sound are still totally seperate on unix
but perhaps my formative years on 8 bit home micros where graphics and sound
came bundled skew my opinion.

[Rainer Weikusat]

Post by Lawrence D'Oliveiro

Post by M***@DastardlyHQ.org
On Wed, 11 Dec 2024 22:26:56 -0000 (UTC)

Post by Lawrence D'Oliveiro

Post by M***@DastardlyHQ.org
It doesn't need to , it can just spawn off a script or some other
program which does that which is entirely inline with the unix
philosophy.

Which is where the trouble starts.

The trouble is with any support scripts, not with init. I've written a
number of init scripts with a lot of surrounding logic.

I’m sure you have. Which means you are familiar with the wholesale copying
and pasting of boilerplate from one script to the next. “What does this
bit do?” “Don’t bother thinking too hard, just stick it in, just in case.”

Nobody but you can be familiar with what you are doing when being forced
to write code.

Post by Lawrence D'Oliveiro

Post by M***@DastardlyHQ.org
God knows how I'd do that with systemd ...

Figure out what the directives do (they’re all documented), and which
settings will achieve the result you want. Most of the time, your service
file will be very simple and very short, since all the common cases are
already covered.
“Simple things should be simple, and complex things should be possible.”
-- Alan Kay

According to an automated count (mostly perl -ne 'print $_, "\n" for
/\w+=/g') the current version of systemd supports about 320
directives and people still combine that with start scripts, be this
because their use case still isn't supported or because they didn't want
to be bothered with learning about all the details of this huge, rusted
barbed wire obstacle just for solving a simple problem.

The quote would thus more appropriate be:

Make simple things hideously complicated and complicated things at all
impossible.

-- Lennart Poettering about "How to create problems for other people for one's
own benefit."

Post by Lawrence D'Oliveiro
He was talking about GUI design, but the same applies to systemd. And to a
lot of other popular *nix software, while we’re at it.

Post by M***@DastardlyHQ.org

Post by Lawrence D'Oliveiro
Poettering understands that services don’t just to be started, they al
so need to be managed and shut down cleanly.

Poettering created the wrong solution to the wrong problem.

Lots of sysadmins, and distro maintainers, and developers of service apps,
disagree.

Due to human nature, lots of people will always disagree with anything.

[Jim Jackson]

Post by M***@DastardlyHQ.org
The trouble is with any support scripts, not with init. I've written a
number of init scripts with a lot of surrounding logic.

I???m sure you have. Which means you are familiar with the wholesale copying
and pasting of boilerplate from one script to the next. ???What does this
bit do???? ???Don???t bother thinking too hard, just stick it in, just in case.???

Ah describing bad programming practice. The same thing happens when
people just cut and paste anything without knowing what they are doing.

Post by M***@DastardlyHQ.org
God knows how I'd do that with systemd ...

Figure out what the directives do (they???re all documented), and which
settings will achieve the result you want.

Nah, as you say above just cut and paste and not think about any diffiicult
bits you need to read up on :-)

Most of the time, your service
file will be very simple and very short, since all the common cases are
already covered.

Post by M***@DastardlyHQ.org

Post by Lawrence D'Oliveiro
Poettering understands that services don???t just to be started, they al
so need to be managed and shut down cleanly.

Actually a service should know how to shutdown itself cleanly and should
document how that is achieved.

[Richard L. Hamilton]

Post by Lawrence D'Oliveiro

Post by M***@DastardlyHQ.org
On Thu, 5 Dec 2024 02:11:04 -0000 (UTC)

Post by Lawrence D'Oliveiro

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

Which “unix philosophy” would that be?

The one where init does a single task instead of spreading itself
throughout the system ...

What “single task” did init do?
* Mount filesystems
* Spawn syslog, cron
* Spawn terminal login processes (getty)
* Respawn terminated getty processes
* Monitor other special stuff in inittab
* Spawn random other services, without monitoring their state
* Act as a general catch-all for orphaned processes when they terminate
This was all before systemd came on the scene.

It spawned other processes, and where the idea of run levels existed,
selected what to spawn based on those.

It did not do tricky communication with processes, elaborately
manipulate their initial environment, and except for adopting orphans
and respawning processes, didn't do much at all to bother them during
their lifespan unless the run level was changed.

MacOS launchd is arguably even worse insofar as it also has things like
Mach namespaces to deal with.

[M***@dastardlyhq.com]

On Sat, 14 Dec 2024 08:52:14 GMT

Post by Richard L. Hamilton

Post by Lawrence D'Oliveiro
This was all before systemd came on the scene.

It spawned other processes, and where the idea of run levels existed,
selected what to spawn based on those.
It did not do tricky communication with processes, elaborately
manipulate their initial environment, and except for adopting orphans

Which to anyone except poettering and his fanboys its quite obvious it doesn't
need to as a wrapper script can do that quite nicely.

Post by Richard L. Hamilton
MacOS launchd is arguably even worse insofar as it also has things like
Mach namespaces to deal with.

And XML config. Ugh. Why people persist with the hideousness that is XML when
the much clearer json is pretty much standard now beats the hell out of me.

[Lawrence D'Oliveiro]

Post by Richard L. Hamilton
MacOS launchd is arguably even worse insofar as it also has things like
Mach namespaces to deal with.

Linux has namespaces. Everything, just about, is isolatable in its own
namespace: mounted filesystems, network interfaces, processes, user IDs,
even the system time and hostname. Put them all together, and you get
containers.

And yes, launchd was an inspiration for systemd.

[Lawrence D'Oliveiro]

Post by M***@DastardlyHQ.org
On Thu, 5 Dec 2024 02:11:04 -0000 (UTC)

Post by Lawrence D'Oliveiro

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

Which “unix philosophy” would that be?

The one where init does a single task instead of spreading itself
throughout the system ...

What “single task” did init do?

* Mount filesystems
* Spawn syslog, cron
* Spawn terminal login processes (getty)
* Respawn terminated getty processes
* Monitor other special stuff in inittab
* Spawn random other services, without monitoring their state
* Act as a general catch-all for orphaned processes when they terminate

This was all before systemd came on the scene.

[Richard L. Hamilton]

Post by Lawrence D'Oliveiro

Post by M***@DastardlyHQ.org
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”.

It probably does as of the version of the formal specification they met
to be allowed to use the trademark.

Other features that are customary but not entirely standardized
may be implemented differently if at all, possibly with different
side-effects or complications.

Pretty sure I've some time ago used the equivalent of LD_PRELOAD on
macOS to wrap some existing library function, with very little change
to the C code, but some change to compiler options, environment
variables required, etc. For instance, one might need compiler flags
-fPIC -dynamiclib

which might be different from other platforms. And the environment variable
for macOS instead of LD_PRELOAD (from the dyld man page) is
DYLD_INSERT_LIBRARIES
This is a colon separated list of additional dynamic libraries to
load before the ones specified in the program. If instead, your
goal is to substitute a library that would normally be loaded, use
DYLD_LIBRARY_PATH or DYLD_FRAMEWORK_PATH instead.


However I just tried this with some old preloadable modules (of
suitable architecture), and it no longer seems to work. Not sure what
else I have to do now. Maybe this changed/broke when most dynamic libraries
were replaced by a pre-linked cache files that would map in in their entirety
at reserved address(es). Faster, more secure, but maybe less flexible.
Haven't googled enough yet to find the answer, if any.

[M***@dastardlyhq.com]

On Sat, 14 Dec 2024 08:48:00 GMT

Post by Richard L. Hamilton
However I just tried this with some old preloadable modules (of
suitable architecture), and it no longer seems to work. Not sure what
else I have to do now. Maybe this changed/broke when most dynamic libraries
were replaced by a pre-linked cache files that would map in in their entirety
at reserved address(es). Faster, more secure, but maybe less flexible.
Haven't googled enough yet to find the answer, if any.

Probably something to do with security. Apple have really nailed MacOS down
in recent releases. I looked at how to do it for recent versions and just
decided I couldn't be bothered. Seemed to require putting macros in code and
I just thought nah.

[Geoff Clare]

Post by Richard L. Hamilton

Post by M***@DastardlyHQ.org
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".

It probably does as of the version of the formal specification they met
to be allowed to use the trademark.

It is certified as conforming to "UNIX 03", which is so named because
the certification program was launched in 2003, although by coincidence
the corresponding version of The Single UNIX Specification (SUS) is
version 3. There have since been SUSv4 (2008) and SUSv5 (2024) so
macOS is two versions behind. (AIX and Solaris are/were certified to
SUSv4; there is no certification program yet for SUSv5.)

SUSv3/4 included dlopen(), dlsym() and dlclose() but no other
requirements related to dynamic linking. SUSv5 adds the ability to
build shared libraries and dynamic executables using the c17 utility,
but doesn't specify how their loading can be controlled with
environment variables.

The things Lawrence said don't work on macOS the way people expect
UNIX to work are almost certainly all, just like LD_PRELOAD, not
specified by SUS. (Otherwise macOS would fail some of the tens of
thousands of tests it has to pass in order for each new macOS version
to be certified.)

[Richard Kettlewell]

(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.

[Scott Lurndal]

Post by Richard L. Hamilton

Post by M***@dastardlyhq.com
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.