I don't think you want the single quotes under Windows.

On Sun, 7 Mar 2021 at 13:24, jon jon@jonbondy.com wrote:

You appear to be correct, although the example from the documentation is
this:

openscad -o my_model_production.stl -D 'quality="production"' my_model.scad

Now, I get the warning that "val1" is an "unknown variable" for each of
the used files, and too many unnamed arguments for one of the used
files. Unsettling.

The STL appears to have been generated correctly, but the warnings are
frightening: they do not occur when run from the GUI.

I guess I'm off and running, albeit nervously

Thanks!

On 3/7/2021 8:30 AM, nop head wrote:

See  wiki
https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/Using_OpenSCAD_in_a_command_line_environment

One way:

It's been a while since I used cmd-line, I seem to recall that in batch
files it got complex.

OpenSCAD Admin - email* me if you need anything,  or if I've done something stupid...

• on the Forum, click on my MichaelAtOz label, there is a link to email me.

Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.

--
Sent from: http://forum.openscad.org/

I was using the wiki entry you recommend.

My sense is that nophead is correct about removing the single quotes
from my original example, and that the syntax for a batch file and for a
command line execution are subtly different.  There is no need to escape
the inner quotes, because there are no inner quotes once nophead's
suggestion is implemented

The warnings are scary, but I think I'm off and running

Jon

On 3/7/2021 8:44 AM, MichaelAtOz wrote:

Do you ECHO the variables to be sure that they are getting in with the
values that you set?

On 2021-03-07 8:48 a.m., jon wrote:

--
Ron Wheeler
Artifact Software
438-345-3369
rwheeler@artifact-software.com

The values were correct, because the STLs created were correct. I cannot
explain the warning messages

On 3/7/2021 10:57 AM, Ron Wheeler via Discuss wrote:

The proof is in the pudding but one hates to see error messages
(unexpected ones at least) even if the code appears to work.

On 2021-03-07 11:26 a.m., jon wrote:

--
Ron Wheeler
Artifact Software
438-345-3369
rwheeler@artifact-software.com

For Linux you would need the outer single quotes but not for Windows.
Windows is weird.

On Linux the outer single quotes would be stripped but on Windows that
would be passed to OpenSCAD.

On Windows the inner double quotes both allow spaces etc in the string but
also get passed to OpenSCAD, which is why you don't need the outer quotes.

You shouldn't expect any additional warnings.

On Sun, 7 Mar 2021 at 16:50, Ron Wheeler via Discuss <
discuss@lists.openscad.org> wrote:

On 3/7/2021 10:06 AM, nop head wrote:

Windows isn't weird.  It's just different.

(Well, OK, in some ways it's weird too.  But this really isn't one of them.)

Doing anything non-trivial with the various command processors requires
that you understand the syntax that they impose, and how they will
process the line before the program sees it.

In a UNIX-derived shell, in this command:

openscad -o my_model_production.stl -D 'quality="production"' my_model.scad

the single quotes are not formally part of the definition of the
command.  They are eaten by the shell and are not at all visible to the
program.  What the program sees is a list of "words", the argv array:

openscad
-o
my_model_production.stl
-D
quality="production"
my_model.scad

The Windows model for passing arguments to programs is completely
different.  It's been a million years since I've looked at Windows
arguments without a C library interpreting them for me, but historically
MS-DOS just handed over the entire line after the command, quotes,
spaces, and all, less only a few things like I/O redirection.  C
libraries, since they want to present a sort of UNIX-like environment to
the program, parse those command lines in a way that's sort of similar
to the UNIX shell, but only sort of.  The details will depend on the
particular library used, which can lead to unfortunate inconsistencies
between one program and the next.  For MSYS2, it appears that double
quotes are handled but single quotes are not.  Here's a demonstration
using a simple program that dumps its arguments:

C:\msys64\home\Jordan>args a "a b" 'a b' "'a b'" '"a b"' a\ b
0 >args<
1 >a<
2 >a b<
3 >'a<
4 >b'<
5 >'a b'<
6 >'a b'<
7 >a\<
8 >b<

Contrast that with the UNIX shell behavior:

$ ./args a "a b" 'a b' "'a b'" '"a b"' a\ b
0 >C:\msys64\home\Jordan\args.exe<
1 >a<
2 >a b<
3 >a b<
4 >'a b'<
5 >"a b"<
6 >a b<

(Interesting note:  that's the same MSYS2 program running in both
cases.  The MSYS2 infrastructure must somehow negotiate with the program
to let it know that the arguments have already been parsed.  Running
under the MSYS2 version of bash, the command is getting parsed the same
as it would be under UNIX.)

In the world of the UNIX shell, double quotes protect most characters
from special interpretation, allowing spaces and wild-card characters to
be passed as arguments.  They do not protect against shell variable
references.  Single quotes protect against all special interpretation,
except for the closing single quote.  Backslash protects the following
character against any special interpretation.  After these characters
have done their job, they are stripped from the arguments that are
passed to the program.

In the world of the half-hearted UNIX-like parsing done by the MSYS2
library, it seems that double quotes are similar, but single quotes and
backslashes are not special - or at least not quite as special;
backslashes do seem to protect double quotes from being treated specially.

I don't know anything about Windows PowerShell syntax, but
experimentation says that it (combined with the MSYS2 library) gives
still another behavior:

PS C:\msys64\home\jordan> ./args a "a b" 'a b' "'a b'" '"a b"' a\ b
0 >C:\msys64\home\jordan\args.exe<
1 >a<
2 >a b<
3 >a b<
4 >'a b'<
5 >a b<
6 >a\<
7 >b<

Note that it has respected the simple single and double quote cases as a
UNIX shell would, and the single-inside-double case, but it stripped
both layers off of the double-inside-single case, and didn't respect the
backslash.

Judging from the examples in the documentation, some Windows C library
that OpenSCAD has used allowed protecting double quotes by doubling
them.  I don't know what variation this is from:

openscad.com -o my_model_production.stl -D "quality=""production""" my_model.scad

The documentation hints at how it really works in its description of
running OpenSCAD from another programming language:

When executing OpenSCAD from another process in Unix, the
single-quotes shouldn't be used e.g. from within a Java application:

   pb = new ProcessBuilder("/usr/bin/openscad",
     "-o", "my_model_production.stl",
     "-D", "quality=\"production\"",
     "my_model.scad");

but it's not exactly correct, or at least it doesn't lead to the right
mental model.  It's not that OpenSCAD doesn't need the single quotes in
that context - it's that they are needed in the shell context, but by
the shell, not OpenSCAD itself.  Note that this Java invocation has also
done several other things to the command - it's split the words into
separate strings, and it's supplied an absolute path to the program, and
it's backslash-quoted the double quotes so that they can be inside a
Java string.

Anyhow, net, you always need to distinguish between what the command
processor (perhaps augmented by the system-specific C library) will do
to the command, and what the program proper will see.  If you don't keep
that straight in your head, you'll run into trouble and
apparently-mysterious behavior in more complex cases and when you move
from system to system and command processor to command processor.