feat: builtin funtion rm.

[MuhamedMagdi]

It uses the -rf flags by default.

ref #215

[Ph0enixKM]

I'm thinking... can we insert some kind of runtime detection for removing some directories like /, ~, /bin, /sbin, /dev, /etc, /usr etc.

To prevent this command from running - this is usually not the intended use of this command. If user really wants to remove the /, then they must use the command $rm -rf /$ syntax.

[Mte90]

maybe a prefilled parameter that the developer can define, the code automatically should check if the path is part of that and shows an alert.

[Ph0enixKM]

@b1ek @KrosFire What do you think?

[KrosFire]

Bash scripts are pretty unsafe by design. I would allow this as it is, it's just a syntax sugar for what you can already do.

But I'm thinking, if we could create some kind of "secure compile" mode or "debug", where we create script but with something like strace so that someone can be sure, that the script is not doing anything funky. But that's a topic for another day

[Mte90]

@KrosFire there is #219 for debug more :-)

[RokkuCode]

Having a built in "rm" command that has "-rf" by default is for me a violation of principle of last suprise. default rm does not work like this. why should the build in rm more dangerous than the $rm -frv /$? The developer who wrote this command stmt wants explicitly use this dangerous command, but the user who uses the built-in rm command does not. the builtin rm keyword should work as the rm on the shell, if not dont call it rm. name it deleteFile/deletePath and provide it via the standard library.

in the end i dont see any benefit of having it as built in. it is better placed as part of the std library.

[Mte90]

I think that needs just one parameter, to remove folders and a sanitization for the path.
I think that other languages just do that, it is a task for the developer to do more.
We can extend the rm builtin in the stdlib with a safety version later that does more checks.

[Ph0enixKM]

Okay. My stance on this is that if this builtin is destructive (dangerous) then let's keep it as a function library.

I'm closing it and will update the built-in guidelines. If you think otherwise - please reopen and we can have a discussion on it.