After installing 2025.01.19 I can confirm that this version behaves the same. Is it the same on other OSs?

Sorry for posting private messages, I didn't realize that the reply-to address is the one of the original sender and not of the mailing list. I will consider that in future discussions.

As long as the output going to stderr is stable, I'm fine with that. I just wanted to make sure that I don't miss sth. out.

On Thu, Jan 23, 2025 at 08:00:58AM -0800, Jordan Brown via Discuss wrote:

Traditional Unix programs do not produce any output or status messages.
Openscad does.

I would suggest that echo() outputs go to stdout.
and that a --quiet option suppresses all openscad status messages.
(i.e. suppresses the third stream of output).

Another, ugly solution would be to use fd 3 if it is open on
startup for one of the streams.

Roger. 

--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
**    Delftechpark 11 2628 XJ  Delft, The Netherlands.  KVK: 27239233    **
f equals m times a. When your f is steady, and your m is going down
your a** is going up.  -- Chris Hadfield about flying up the space shuttle.
**  'a' for accelleration.

Actually most - if not all - command line UNIX programs can produce output, at least if they have something like verbose mode (cp, rm, ...). I thought about the issue this morning and came to a few insights:

If OpenSCAD needs to have the option to send rendering results (stl, png, ...) to stdout, it can send neither statistics nor echo()-output to stdout in order not to contaminate the rendering result. My guess is that the feature exists to be able to pipe the rendering results(?)

If the issue should be solved (again: I am fine with stderr as long as it can be considered stable behavior) I see the following possibilities:

1. rendering to stdout shall remain unchanged AND all non-erroneous output shall be sent to stdout: send all non-erroneous output to stdout AND automatically switch to quiet-mode if rendering results are to be sent to stdout

2. rendering to stdout shall remain unchanged AND all non-erroneous output shall not be sent to stderr: send rendering results to stdout AND send all non-erroneous output to a file

3. rendering to stdout can be skipped: remove the functionality and send all non-erroneous output to stdout. I have no idea how popular the feature is.

I think that #2 is not a preferable option.

Solving this issue would help to recognize erroneous rendering because rendering errors and warnings could be sent to stderr and analysed appropriately.

I've recently written command-line programs that required both
information/status and "render" output, and I simply directed the former
to stderr.  Since both direct to the console by default, the average
user doesn't even notice the difference.  And, IMHO the average advanced
user should know how to deal with it.

I use OpenSCAD as a command-line rendering engine for a web-page
front-end for the customizer; I don't currently pipe render output to
stdout but I can see the use-case, where OpenSCAD render output would go
to another program for further manipulation, e.g., mesh-fixing.  Some
might utter "WebAssembly" and such, sorry, might not want to burden a
user's browser with all that.

Anyway, a bit of food-for-thought...

Glenn Butcher

On 1/24/2025 8:20 AM, Thomas Richter via Discuss wrote:

On 1/24/2025 12:59 AM, Rogier Wolff via Discuss wrote:

tar with the "v" option has always produced status output.  (Similarly,
though not quite as old, cpio.)

dd has always reported the number of blocks written.

make reports commands as it executes them.  (Though that is arguably
"output".)

sh -x reports commands as it executes them.

Those are the ones that I find in a quick scan through my V7 manual,
considering only those that also write output to stdout and are not
clearly intended for human interaction.  More recent tools are likely to
do more, take longer, and so be more likely to produce progress
reporting.  (But, alas, they are also less likely to use stdin and stdout.)

It's not so many as to have been an obvious need on day one, but it's
also not so few that they can be ignored.

It does.

Not safe.  Programs invoking other programs are not required to close
all of their open files.  (They probably should, but they aren't
required to.)

On Fri, Jan 24, 2025 at 04:01:26PM -0800, Jordan Brown wrote:

What I meant is that generally say a "sort" program won't
report: "reading input", "sorting", "writing results".

Many oldfashioned unix programs adhere to this principle, and some
don't. e.g. when you start passing arguments (sh -x) they can be
persuaded to indeed tell what they are doing. Usually on stderr is my
guess. I checked sh and indeed the -x output is on stderr, as to not
polute the actual output on stdout.

Openscad behaves contrary to this IMHO not a problem, but it does
create a few problems.

dd is a program that violates the Unix philosphy. It is the exception
to the rule. Modern Posix rules are pushing it to become even more
unusable. I remember an instance about a decade ago where I found dd's
behaviour undesirable and in the end the dd guys said: "Posix
specifies this behaviour, our hands are tied".

In that case this needs to be guarded by say a "--fd=12" option for
stuff to appear on open file descriptor nr 12...

Roger. 

--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
**    Delftechpark 11 2628 XJ  Delft, The Netherlands.  KVK: 27239233    **
f equals m times a. When your f is steady, and your m is going down
your a** is going up.  -- Chris Hadfield about flying up the space shuttle.
**  'a' for accelleration.