export(".profile", [0]);

 for (i=[1:999999], j=[1:999999]) export(str(i,"-",j), [0]);

Hi Jordan, I'm not a linux user, unless I have to be, although now you can run linux as a subsystem in windows. There's always a way of wrecking stuff. If it is a worry, then the export file location, name and extension could be fixed in the export program e.g. export(p) would always write 'p' to a fixed file in the openscad directory named 'scadexportdata.txt', say. If the user wants to use it to overwrite a file in system32 directory, then, he has to do that outside of openscad and in most cases, if a windows user, if you are not logged in as admin, then warning messages are presented if doing something that is a bit risky, and some things you can't actually do at your login level.. I reckon that would be pretty safe. If that is safe, then have a dedicated directory , say 'scadexportdata' and let the user chose the file names on export from openscad. For it to be really useful, it would need the facility to pause openscad programmatically, until whatever task was undertaken by the outside program was completed. At the moment, I can do what I want, but it is a bit hand-cranked, having to write separate scripts , run the first, run the external program, then run the second.. So, for example, I want to manipulate the shape of a polygon composed from openscad squares/circles, etc. You can't bend the straight edges, since there are no intermediate points. Save it as an svg. I Have to export at end of program. external program inserts extra points on straight edges, and saves it as a list of points in openscad format. I could easily measure between points  there, too, if needed. A fresh openscad program can include that file wherever needed. Being able to save and pause, would allow this to be in one openscad program, and with a fixed name/folder for export, saves fiddling around with file names in the external program. I tend to use fixed names, in the svg case 'scadtosvg.svg' for exporting the svg file from openscad, 'svgtoscad.txt' to save the svg as a list of points from external program, and 'svgtoscadextra.txt' for the list of points with the intermediates. openscad can include any openscad compliant file, with any file name extension, afaik. Searching around on the web, it seems, over the years, there have been various attempts at using c++, say, and openscad https://hackaday.com/2017/01/03/ditch-openscad-for-c/ but that needs a knowledge of c++. By including the facility to save data from within openscad, then any external programming language could be used, provided it can generate a text file.  There's always a way of solving problems. Best wishes, Ray On 22/10/2022 01:29, Jordan Brown wrote: > On 10/21/2022 4:18 PM, Raymond West wrote: >> I'm not sure what security risk is created by exporting a list of >> numbers from within openscad. A risk to who, or what? > > You're a Linux user, right?  Suppose that we had a module > export(filename, value) that writes the specified value to the > specified file. > > export(".profile", [0]); > > ... destroys the user's login script, if they run OpenSCAD in their > home directory. > > for (i=[1:999999], j=[1:999999]) export(str(i,"-",j), [0]); > > fills up the user's disk by creating ~10^12 files in the current > directory. > >> As it is, openscad exports/imports it's own version of svgs and dxfs, >> which leads to errors in other programs, so I can't see a list of >> numbers  generated by the user's scripting  as being any more risky. > > There's a big difference between allowing the user to save the output > from the program to a file of their choice, and allowing the program > to save data to a name of its choice without the user's intervention. > > One could easily imagine having a user action "save the log from the > last run" - but that would be the user taking an action and > controlling the name of the file to be written. >

"There's always a way of solving problems". Maybe sort of. But if it was really so easy, we wouldn't keep hearing about security holes in our software. I think the OpenSCAD developers are not interested in opening this can of worms. They have chosen to ensure security by not writing files, which is probably the only way to be 100% certain. On Sat, Oct 22, 2022 at 10:00 AM Raymond West <raywest@raywest.com> wrote: > > Hi Jordan, > > I'm not a linux user, unless I have to be, although now you can run linux > as a subsystem in windows. > > There's always a way of wrecking stuff. > > If it is a worry, then the export file location, name and extension could > be fixed in the export program e.g. export(p) would always write 'p' to a > fixed file in the openscad directory named 'scadexportdata.txt', say. If > the user wants to use it to overwrite a file in system32 directory, then, > he has to do that outside of openscad and in most cases, if a windows user, > if you are not logged in as admin, then warning messages are presented if > doing something that is a bit risky, and some things you can't actually do > at your login level.. > > I reckon that would be pretty safe. > > If that is safe, then have a dedicated directory , say 'scadexportdata' > and let the user chose the file names on export from openscad. > > For it to be really useful, it would need the facility to pause openscad > programmatically, until whatever task was undertaken by the outside program > was completed. > > At the moment, I can do what I want, but it is a bit hand-cranked, having > to write separate scripts , run the first, run the external program, then > run the second.. > > So, for example, I want to manipulate the shape of a polygon composed from > openscad squares/circles, etc. You can't bend the straight edges, since > there are no intermediate points. Save it as an svg. I Have to export at > end of program. external program inserts extra points on straight edges, > and saves it as a list of points in openscad format. I could easily measure > between points there, too, if needed. A fresh openscad program can include > that file wherever needed. > > Being able to save and pause, would allow this to be in one openscad > program, and with a fixed name/folder for export, saves fiddling around > with file names in the external program. I tend to use fixed names, in the > svg case 'scadtosvg.svg' for exporting the svg file from openscad, > 'svgtoscad.txt' to save the svg as a list of points from external program, > and 'svgtoscadextra.txt' for the list of points with the intermediates. > openscad can include any openscad compliant file, with any file name > extension, afaik. > > Searching around on the web, it seems, over the years, there have been > various attempts at using c++, say, and openscad > https://hackaday.com/2017/01/03/ditch-openscad-for-c/ but that needs a > knowledge of c++. By including the facility to save data from within > openscad, then any external programming language could be used, provided it > can generate a text file. > > There's always a way of solving problems. > > Best wishes, > > > Ray > > > On 22/10/2022 01:29, Jordan Brown wrote: > > On 10/21/2022 4:18 PM, Raymond West wrote: > > I'm not sure what security risk is created by exporting a list of numbers > from within openscad. A risk to who, or what? > > > You're a Linux user, right? Suppose that we had a module export(filename, > value) that writes the specified value to the specified file. > > export(".profile", [0]); > > ... destroys the user's login script, if they run OpenSCAD in their home > directory. > > for (i=[1:999999], j=[1:999999]) export(str(i,"-",j), [0]); > > fills up the user's disk by creating ~1012 files in the current directory. > > As it is, openscad exports/imports it's own version of svgs and dxfs, > which leads to errors in other programs, so I can't see a list of numbers > generated by the user's scripting as being any more risky. > > > There's a big difference between allowing the user to save the output from > the program to a file of their choice, and allowing the program to save > data to a name of its choice without the user's intervention. > > One could easily imagine having a user action "save the log from the last > run" - but that would be the user taking an action and controlling the name > of the file to be written. > > _______________________________________________ > OpenSCAD mailing list > To unsubscribe send an email to discuss-leave@lists.openscad.org >

I find it hard to have sympathy with a goal of 100% certainty.  I do not have that goal in any other aspect of my life, professional or personal. There are some directories into which one could write files with some comfort, at least under Windows.  The Downloads and Documents file come to mind.  Perhaps the directory where the source code can be found. And remember that when one "runs" an OpenSCAD program, one is running source code.  While we may not want to read the source code every time we run new-to-us OpenSCAD programs, we have that option.  It is not as opaque as running an EXE that has been compiled.  And it would be possible (but, IMHO, unnecessary) to keep track of which files have been run before, and apply more checking to files that have never been run before. Finally, we CAN control the output, with a check box in Settings that enables/disables a Write feature, or which requires a prompt before writing, or which specifies a fixed output folder. I think it is time to fix this bug in OpenSCAD. Jon On 10/22/2022 10:13 AM, Adrian Mariano wrote: > "There's always a way of solving problems".  Maybe sort of.  But if it > was really so easy, we wouldn't keep hearing about security holes in > our software.  I think the OpenSCAD developers are not interested in > opening this can of worms. They have chosen to ensure security by not > writing files, which is probably the only way to be 100% certain. >

I can appreciate the developers' stand on this 100% {insert a protracted diatribe of incendiary remarks about the state of computer/internet security in the world, etc... Blame Microsoft, etc, etc... end of rant}. However, might it be possible to write data to a WINDOW? OpenSCAD could open a window, instead of a file, and write data to that window for display. If the window processes mouse selections so that some or all of the window can be copied and pasted into other applications, then the spirit of the feature can be provided, whilst placing the onus of security outside the confines of the OpenSCAD application. The user would be solely responsible for what they do with the copied data. Of course, this limits the "file output" to text data, but that shouldn't make it useless. Limit the number of open windows to some reasonable number (1, perhaps) to keep from blowing up the system by opening too many at once, of course. The memory allocated to the window might be similarly limited. All that this window needs to do is process "select-all" and "copy" (to the system clip-board) commands from the user. It would require a non-zero effort, but shouldn't be exceedingly onerous to code in one's copious free time. The "operator in the loop" aspect which forms the basis for securing the system would limit the utility somewhat, but perhaps this would be countered by the increased utility of the application. Just a series of loosely connected thoughts... Cheers, Joe On Sat, Oct 22, 2022 at 9:14 AM Adrian Mariano <avm4@cornell.edu> wrote: > "There's always a way of solving problems". Maybe sort of. But if it was > really so easy, we wouldn't keep hearing about security holes in our > software. I think the OpenSCAD developers are not interested in opening > this can of worms. They have chosen to ensure security by not writing > files, which is probably the only way to be 100% certain. > > On Sat, Oct 22, 2022 at 10:00 AM Raymond West <raywest@raywest.com> wrote: > >> >> Hi Jordan, >> >> I'm not a linux user, unless I have to be, although now you can run linux >> as a subsystem in windows. >> >> There's always a way of wrecking stuff. >> >> If it is a worry, then the export file location, name and extension could >> be fixed in the export program e.g. export(p) would always write 'p' to a >> fixed file in the openscad directory named 'scadexportdata.txt', say. If >> the user wants to use it to overwrite a file in system32 directory, then, >> he has to do that outside of openscad and in most cases, if a windows user, >> if you are not logged in as admin, then warning messages are presented if >> doing something that is a bit risky, and some things you can't actually do >> at your login level.. >> >> I reckon that would be pretty safe. >> >> If that is safe, then have a dedicated directory , say 'scadexportdata' >> and let the user chose the file names on export from openscad. >> >> For it to be really useful, it would need the facility to pause openscad >> programmatically, until whatever task was undertaken by the outside program >> was completed. >> >> At the moment, I can do what I want, but it is a bit hand-cranked, having >> to write separate scripts , run the first, run the external program, then >> run the second.. >> >> So, for example, I want to manipulate the shape of a polygon composed >> from openscad squares/circles, etc. You can't bend the straight edges, >> since there are no intermediate points. Save it as an svg. I Have to export >> at end of program. external program inserts extra points on straight edges, >> and saves it as a list of points in openscad format. I could easily measure >> between points there, too, if needed. A fresh openscad program can include >> that file wherever needed. >> >> Being able to save and pause, would allow this to be in one openscad >> program, and with a fixed name/folder for export, saves fiddling around >> with file names in the external program. I tend to use fixed names, in the >> svg case 'scadtosvg.svg' for exporting the svg file from openscad, >> 'svgtoscad.txt' to save the svg as a list of points from external program, >> and 'svgtoscadextra.txt' for the list of points with the intermediates. >> openscad can include any openscad compliant file, with any file name >> extension, afaik. >> >> Searching around on the web, it seems, over the years, there have been >> various attempts at using c++, say, and openscad >> https://hackaday.com/2017/01/03/ditch-openscad-for-c/ but that needs a >> knowledge of c++. By including the facility to save data from within >> openscad, then any external programming language could be used, provided it >> can generate a text file. >> >> There's always a way of solving problems. >> >> Best wishes, >> >> >> Ray >> >> >> On 22/10/2022 01:29, Jordan Brown wrote: >> >> On 10/21/2022 4:18 PM, Raymond West wrote: >> >> I'm not sure what security risk is created by exporting a list of numbers >> from within openscad. A risk to who, or what? >> >> >> You're a Linux user, right? Suppose that we had a module >> export(filename, value) that writes the specified value to the specified >> file. >> >> export(".profile", [0]); >> >> ... destroys the user's login script, if they run OpenSCAD in their home >> directory. >> >> for (i=[1:999999], j=[1:999999]) export(str(i,"-",j), [0]); >> >> fills up the user's disk by creating ~1012 files in the current >> directory. >> >> As it is, openscad exports/imports it's own version of svgs and dxfs, >> which leads to errors in other programs, so I can't see a list of numbers >> generated by the user's scripting as being any more risky. >> >> >> There's a big difference between allowing the user to save the output >> from the program to a file of their choice, and allowing the program to >> save data to a name of its choice without the user's intervention. >> >> One could easily imagine having a user action "save the log from the last >> run" - but that would be the user taking an action and controlling the name >> of the file to be written. >> >> _______________________________________________ >> OpenSCAD mailing list >> To unsubscribe send an email to discuss-leave@lists.openscad.org >> > _______________________________________________ > OpenSCAD mailing list > To unsubscribe send an email to discuss-leave@lists.openscad.org >

Povray has a command-line switch to enable writing. Perhaps OpenSCAD could have something similar. On Sat, Oct 22, 2022 at 9:34 AM FF Systems <joeh@rollanet.org> wrote: > I can appreciate the developers' stand on this 100% {insert a protracted > diatribe of incendiary remarks about the state of computer/internet > security in the world, etc... Blame Microsoft, etc, etc... end of rant}. > > However, might it be possible to write data to a WINDOW? OpenSCAD could > open a window, instead of a file, and write data to that window for > display. If the window processes mouse selections so that some or all of > the window can be copied and pasted into other applications, then the > spirit of the feature can be provided, whilst placing the onus of security > outside the confines of the OpenSCAD application. The user would be solely > responsible for what they do with the copied data. Of course, this limits > the "file output" to text data, but that shouldn't make it useless. > > Limit the number of open windows to some reasonable number (1, perhaps) to > keep from blowing up the system by opening too many at once, of course. > The memory allocated to the window might be similarly limited. All that > this window needs to do is process "select-all" and "copy" (to the system > clip-board) commands from the user. > > It would require a non-zero effort, but shouldn't be exceedingly onerous > to code in one's copious free time. The "operator in the loop" aspect > which forms the basis for securing the system would limit the utility > somewhat, but perhaps this would be countered by the increased utility of > the application. > > Just a series of loosely connected thoughts... > > Cheers, > > Joe > > > > On Sat, Oct 22, 2022 at 9:14 AM Adrian Mariano <avm4@cornell.edu> wrote: > >> "There's always a way of solving problems". Maybe sort of. But if it >> was really so easy, we wouldn't keep hearing about security holes in our >> software. I think the OpenSCAD developers are not interested in opening >> this can of worms. They have chosen to ensure security by not writing >> files, which is probably the only way to be 100% certain. >> >> On Sat, Oct 22, 2022 at 10:00 AM Raymond West <raywest@raywest.com> >> wrote: >> >>> >>> Hi Jordan, >>> >>> I'm not a linux user, unless I have to be, although now you can run >>> linux as a subsystem in windows. >>> >>> There's always a way of wrecking stuff. >>> >>> If it is a worry, then the export file location, name and extension >>> could be fixed in the export program e.g. export(p) would always write 'p' >>> to a fixed file in the openscad directory named 'scadexportdata.txt', say. >>> If the user wants to use it to overwrite a file in system32 directory, >>> then, he has to do that outside of openscad and in most cases, if a windows >>> user, if you are not logged in as admin, then warning messages are >>> presented if doing something that is a bit risky, and some things you can't >>> actually do at your login level.. >>> >>> I reckon that would be pretty safe. >>> >>> If that is safe, then have a dedicated directory , say 'scadexportdata' >>> and let the user chose the file names on export from openscad. >>> >>> For it to be really useful, it would need the facility to pause openscad >>> programmatically, until whatever task was undertaken by the outside program >>> was completed. >>> >>> At the moment, I can do what I want, but it is a bit hand-cranked, >>> having to write separate scripts , run the first, run the external program, >>> then run the second.. >>> >>> So, for example, I want to manipulate the shape of a polygon composed >>> from openscad squares/circles, etc. You can't bend the straight edges, >>> since there are no intermediate points. Save it as an svg. I Have to export >>> at end of program. external program inserts extra points on straight edges, >>> and saves it as a list of points in openscad format. I could easily measure >>> between points there, too, if needed. A fresh openscad program can include >>> that file wherever needed. >>> >>> Being able to save and pause, would allow this to be in one openscad >>> program, and with a fixed name/folder for export, saves fiddling around >>> with file names in the external program. I tend to use fixed names, in the >>> svg case 'scadtosvg.svg' for exporting the svg file from openscad, >>> 'svgtoscad.txt' to save the svg as a list of points from external program, >>> and 'svgtoscadextra.txt' for the list of points with the intermediates. >>> openscad can include any openscad compliant file, with any file name >>> extension, afaik. >>> >>> Searching around on the web, it seems, over the years, there have been >>> various attempts at using c++, say, and openscad >>> https://hackaday.com/2017/01/03/ditch-openscad-for-c/ but that needs a >>> knowledge of c++. By including the facility to save data from within >>> openscad, then any external programming language could be used, provided it >>> can generate a text file. >>> >>> There's always a way of solving problems. >>> >>> Best wishes, >>> >>> >>> Ray >>> >>> >>> On 22/10/2022 01:29, Jordan Brown wrote: >>> >>> On 10/21/2022 4:18 PM, Raymond West wrote: >>> >>> I'm not sure what security risk is created by exporting a list of >>> numbers from within openscad. A risk to who, or what? >>> >>> >>> You're a Linux user, right? Suppose that we had a module >>> export(filename, value) that writes the specified value to the specified >>> file. >>> >>> export(".profile", [0]); >>> >>> ... destroys the user's login script, if they run OpenSCAD in their home >>> directory. >>> >>> for (i=[1:999999], j=[1:999999]) export(str(i,"-",j), [0]); >>> >>> fills up the user's disk by creating ~1012 files in the current >>> directory. >>> >>> As it is, openscad exports/imports it's own version of svgs and dxfs, >>> which leads to errors in other programs, so I can't see a list of numbers >>> generated by the user's scripting as being any more risky. >>> >>> >>> There's a big difference between allowing the user to save the output >>> from the program to a file of their choice, and allowing the program to >>> save data to a name of its choice without the user's intervention. >>> >>> One could easily imagine having a user action "save the log from the >>> last run" - but that would be the user taking an action and controlling the >>> name of the file to be written. >>> >>> _______________________________________________ >>> OpenSCAD mailing list >>> To unsubscribe send an email to discuss-leave@lists.openscad.org >>> >> _______________________________________________ >> OpenSCAD mailing list >> To unsubscribe send an email to discuss-leave@lists.openscad.org >> > _______________________________________________ > OpenSCAD mailing list > To unsubscribe send an email to discuss-leave@lists.openscad.org >

Just write to a file. Open a terminal, and tail -f the_file. Tool-based programming. On Saturday, 22 October 2022 15:34:16 BST FF Systems wrote: > However, might it be possible to write data to a WINDOW? OpenSCAD could > open a window, instead of a file, and write data to that window for > display. -- The University of Glasgow, charity number SC004401

On 10/22/2022 7:34 AM, FF Systems wrote: > However, might it be possible to write data to a WINDOW? I think it would be entirely plausible to have a UI operation that saved the output from the run (not including the run-management noise) to a file.  That would be entirely under the control of the user, and would be easier than cutting and pasting. But: * Ray wanted a way to write a file, *run an external program against that file*, and then read it back in again.  You would have to run the external program manually, and you would have to run another OpenSCAD program manually to process it. * That scheme would only allow for one output file per run. * We'd want an output primitive that doesn't wrap "ECHO" around everything. Writing to N windows?  Shrug, maybe.

There are two interfaces in OpenSCAD, the GUI & the command-line. The GUI is for interactive use, where file saves etc. are driven by the user. The command-line is intended for integrating OpenSCAD into tool-chains. Ray's description matches the second. The command-line <https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/Using_OpenSCAD_in_a_command_line_environment> can output the echo() results for post processing (which can handle "ECHO:"), it can also take input '-D seed=<whatever>'. And a script can also use the 'include <>' method for bulk data*. Command-line creates files under script (or terminal/keyboard) control. If necessary, an OpenSCAD GUI instance can have a relevant .scad file, with "Design/Automatic reload & preview" set, to display output. * there could be minor changes to make this easier, like a line continuation <https://en.wikipedia.org/wiki/Comparison_of_programming_languages_(syntax)> mechanism or fine tuning the parser, as IIRC, my tests of a long time ago, this fails to parse: input_var= [ include <input.txt> // list of points [X,Y],... ] ; end of input_var From: Jordan Brown [mailto:openscad@jordan.maileater.net] Sent: Sun, 23 Oct 2022 09:54 To: OpenSCAD general discussion Mailing-list; FF Systems Subject: [OpenSCAD] Re: Fwd: Re: svg conversion in openscad On 10/22/2022 7:34 AM, FF Systems wrote: However, might it be possible to write data to a WINDOW? I think it would be entirely plausible to have a UI operation that saved the output from the run (not including the run-management noise) to a file. That would be entirely under the control of the user, and would be easier than cutting and pasting. But: * Ray wanted a way to write a file, *run an external program against that file*, and then read it back in again. You would have to run the external program manually, and you would have to run another OpenSCAD program manually to process it. * That scheme would only allow for one output file per run. * We'd want an output primitive that doesn't wrap "ECHO" around everything. Writing to N windows? Shrug, maybe. -- This email has been checked for viruses by AVG antivirus software. www.avg.com

One option here is to use RapCAD to write out files. I've been using a batch file on Windows to use the writeln command in it: C:\Progra~1\RapCAD\rapcad.exe  gcode.rcad -o null -r rcadgcode.nc William