command line help
On 3/7/2021 11:28 AM, Jordan Brown wrote:
On 3/7/2021 10:06 AM, nop head wrote:
For Linux you would need the outer single quotes but not for Windows.
Windows is weird.
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.)
Let me "walk that back" a little.
Windows itself isn't all that weird. It's not UNIX, and it behaves
differently.
But when you combine it with the behaviors of a variety of libraries
embedded in applications, yes, the sum can be weird and inconsistent.
In any other languages outer quotes are stripped and don't appear in the
final string. In Windows cmd they can enclose things like spaces but they
also get included in the result, which in my book is weird. I can' think of
any other language like that.
On Sun, 7 Mar 2021 at 19:33, Jordan Brown openscad@jordan.maileater.net
wrote:
On 3/7/2021 11:28 AM, Jordan Brown wrote:
On 3/7/2021 10:06 AM, nop head wrote:
For Linux you would need the outer single quotes but not for Windows.
Windows is weird.
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.)
Let me "walk that back" a little.
Windows itself isn't all that weird. It's not UNIX, and it behaves
differently.
But when you combine it with the behaviors of a variety of libraries
embedded in applications, yes, the sum can be weird and inconsistent.
I tested command line stuff a while ago, my results went into the wiki.
Here is one of the batch files and output.
cd
set par1=val1="string with %%percent%%"
echo. %par1%
openscad -o "test_o64d.stl" -D "val2="text";" -D "%par1%" testd.scad
pause
Always use outer double-quotes (they get removed), always escape internal
double-quotes.
Note the double percent in environment variable use.
You don't always need to quote the output filename, but some strange ones
make it better to use them.
(it is probably good to also quote the input .scad filename)
C:\test\bit64>o64d.bat
C:\test\bit64>cd
C:\test\bit64
C:\test\bit64>set par1=val1="string with %percent%"
C:\test\bit64>echo. val1="string with %percent%"
val1="string with %percent%"
C:\test\bit64>openscad -o "test_o64d.stl" -D "val2="text";" -D
"val1="string with %percent%"" testd.scad
ECHO: [2014, 12, 16]
ECHO: "hello c:\test\bit64\testd.scad"
ECHO: val1 = "string with %percent%", val2 = "text"
ECHO: "cylinder"
C:\test\bit64>pause
Press any key to continue . . .
testd.scad
// testd.scad
echo(version());
echo("hello c:\test\bit64\testd.scad");
translate([0,0,-15])
cube(10);
echo(val1=val1,val2=val2);
if (val2=="text") {
echo("cylinder");
cylinder(r=10,h=20);
}
else {
echo("sphere");
sphere(r=10);
}
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've worked out what's going on with 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.
"unknown variable" is understandable, not a real warning, explainable but
not ideal, I'll raise an issue to see if it's easily fixable.
Firstly "WARNING: Too many unnamed arguments supplied in file offset.scad,
line 30 " is just the new warnings introduced with 2021.01, if you don't
want them turn off
offset.scad has:
A bunch of "WARNING: variable t not specified as parameter in file
some-file.scad, line 777 "
The write.scad module write() has only one defined parameter 'module
write(word)' but is designed to
accept a range of other parameters, so when e.g.
write(txt, t = 2, h = sy/6, rotate = 270, center=true);
it warns about those undeclared parameters.
They can be dispensed with via that preference, or use text().
Only occurs with command-line use - literally 'use <>', it doesn't occur
with 'include <>'.
Jon must be the first to use this specific method of input parameters via
(ie variable=a_variable - optionVar is declared in the main program)
It has nothing to do with quotes or double quotes.
Test case
The '-D var=val' was always a hack solution.
What it does is append 'var=val;' to the input files (in memory), this uses
the Variables are set at compile-time, not run-time
https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/General#Variables
'feature' so the appended 'var=val' overrides any/all 'var=' elsewhere in
the file.
OpenSCAD is appending that to the 'use <>' files, I don't think it should.
In Jon's case 'myOption=optionVar' is appended to all three 'use <>'d files.
With 'use <>' because $variables may change, every call to a module must
re-evaluate all expressions.
When it hits 'myOption=optionVar' it evaluates it, looks for the variable
optionVar, because 'use <>' has it's own private scope, it does not find
that variable, hence:
One for every module call to a 'use <>' file. Close observation shows those
line numbers are beyond end-of-file.
'include <>' inherits the scope from the main file, so it finds optionVar,
and has no error.
So, for now, either ignore it or utilise 'include <>' instead if there are
no conflicting variables in the library.
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/