DANGEROUS BUG: specifying ~/ as path results in a literal folder "~" being created

[spaceunifyfifty]

On MacOS.

If you manually enter a path for your project destination beginning with the unix shortcut for user home directory, i.e ~/libktx-game, it will create the game folder at ~/~/libktx-game instead of ~/libktx-game, which makes removing that folder ~ via rm extremely dangerous. I imagine the source of the bug is it interpreting ~ as a literal character for the folder name instead of resolving it as a shortcut for /Users/USER/.

Reproduce

1. manually specify a path

2. click "Create folder"

3. click generate project

4. observe that there is now a ~/~/libktx-game folder

cd ~/
cd "~/"
cd libktx-game/
pwd # ~/~/libktx-game/

This is extremely dangerous

after noticing the erroneous file location, I instinctively went to remove it via rm -rf ~/, only realizing immediately after pressing enter that this would remove my entire home directory Users/USER/, instead of the "~" folder in Users/USER/~. Fortunately, I don't see anything missing in my home folder. I am not sure why the command failed; my user has sudo privileges, and I saw no output after running the command. Perhaps the command was partially successful and I will soon find dozens of deeply nested and important files gone (I hope not)...

Very close call, this should be patched ASAP.

[SonicGDX]

I can confirm this is an issue.

Although, the fact that the rm command had no output is very odd. I would have thought there would at least be some permission errors when deleting parts of the Library folder. You say you have sudo privileges (i.e. you can "become" the superuser using sudo) but I'm assuming you didn't actually use sudo or a root shell for running that command right? And even if you were using sudo, I still got outputs of file permission issues when I tried running sudo rm -rf ~/ whilst logged in as a test user.

Maybe it somehow actually didn't delete your home directory?

Also, did you check if the /Users/USER/~ folder was still present after running it?

As an aside, if you did use sudo I would advise against using sudo for regular commands except for ones where you know you need it for the command to execute successfully or do what you expect it to (e.g. when you know you're editing a system configuration file that you wouldn't otherwise have permission to modify). https://unix.stackexchange.com/a/237222

[tommyettinger]

As reiterated by various users across the libGDX Discord, where you (a guest user here) posted as WarioStrikes, acted rudely, and then deleted all of your posts, this isn't actually a bug with Liftoff. You also had claimed that you were on Linux there, and now you're saying MacOS, which calls the rest of this into doubt. First, you are making an assumption that all tools on all OSes act like, for instance, Bash does, and replace the path ~ with the absolute path to the user home directory. On Windows, and as you just found out, on MacOS (as well as Linux), a folder can have the name ~, and if you create a folder with that name you need to be able to delete that folder like any other. That means deleting it using an escaped filename, like you would with a path containing spaces. Liftoff allows creating projects with spaces in the path, of course.

Second, and also as stated a few times on Discord, other major languages don't act like Bash does; Python 3, for instance, allows creating a folder called ~ that is distinct from the user home folder, and the syntax for a folder ~ refers to a relative path to a folder named ~, not the user home directory. "Other major languages" includes Java, also, so you might want to direct your issue towards OpenJDK, which doesn't use GitHub to track issues anyway (they use JIRA). I'm curious what they think, since this is presumably a long-standing behavior.

On UNIX, when using the command line, you should be keenly aware that any command can have consequences if you aren't conscious of what you are doing. If you are by default in super-user mode, which no professional would ever recommend and I hope you weren't doing, then you must by even more keenly aware that the consequences can be worse. If you actually were on MacOS, then you absolutely had access to an excellent GUI for the filesystem. You can delete folders there, too.

The bug here is that you even considered entering an rm -rf command without checking what you were deleting first. At some point we just need to hold ourselves personally accountable when we make mistakes.