On 18.12.22 17:40, gene heskett wrote:

Yes, and that's the reason why it has no automatic meaning
inside OpenSCAD trying to open a file via the file system
API as that does not know about environment variables or
other special handling like "~".

OpenSCAD would need to specifically implement that logic.
I'm not sure that's easily supported by the libraries we
use. Other languages like python have dedicated functions
to resolve those, e.g. Path.expanduser() so while easily
available, it's still not always active when just opening
a file by path.

ciao,
Torsten.

On 12/18/22 11:49, Torsten Paul wrote:

While I understand that asking bash to supply that function also
opens up OpenSCAD to all the other system security loopholes, filtering
down to just that seems easy enough. Maybe add it to the prefs the user
can set?

OTOH, I understand just enough about all this to be dangerous.
Probably multiplied somehow by the fact that I run the latest AppImage
here. Which A/O ten minutes ago, seems to run all my wild hares just
fine. ;o)>

Thanks Torsten. Take care, stay warm and well.

Cheers, Gene Heskett.

"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.

• Louis D. Brandeis
  Genes Web page http://geneslinuxbox.net:6309/

On Sun, Dec 18, 2022 at 05:49:06PM +0100, Torsten Paul wrote:

Right!

And doing that would lead to inconsistencies.

In DOS 3.3 each program implemented their own wildcard expansion.

So "DIR *." would list all files, and "DEL *." would remove only files
without an extension. Now that's the "safe" behaviour between
all the options, but being consistent would be preferable.

(e.g. a program might want to offer the user "clean up arbitrary
files" and ask for the filename or wildcard. Then use "DIR $input" to
ask the user: "You're going to delete the following files: ... Are you
sure?", and then call "DEL $input" when confirmed. Such things cause
headscratching and make people call computers unreliable. "Oh,
sometimes it doesn't delete them when you use wildcards", because they
don't understand why it sometimes happens.

Similarly VAX VMS had each program interpret the wildcards and stuff
themselves. You can create some consistency by having a good library
function that handles it, but inevetably there will be someone who
writes a program with an own implementation that isn't 100%
compatible. I don't remember an example.

So on Unix, the wildcard and ~ expansions are handled by the
shell(s). The inconsistencies between the shells often go unnoticed
because people tend to stick with the shell they got by default.

Try

$ ls
this1 this2 thedir
$ find . -name that*
./thedir/that1
./thedir/that2
$

% ls
this1 this2 thatdir
% find . -name that*
find: No match.
%

(the (t)csh behaviour is better:

$ touch that23
$ find . -name that*
./that23
$

)

The shell doing the expansion for you without you seeing it means that
you don't realize it is the shell doing it for you. Resulting in
questions like this.

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.

On Sun, 2022-12-18 at 11:40 -0500, gene heskett wrote:

OpenSCAD on the Linux I am running (Ubuntu 22.04.1 LTS) is an appimage,
and you cannot expect shell expansions to work.