Fix regression introduced in #11550. If an existing alias was present in
the moment of sourcing, and oh-my-zsh aliases were disabled for that
file, it'd be overwritten aswell. See #11658.
This change fixes the case where the compressed file (e.g. tools.tgz) only
contains a folder with the same name (e.g. tools) in its root folder.
tools.tgz:
|- tools
|- fileA.txt
|- fileB.txt
\- fileC.txt
In that case, the "smart" folder creation mechanism will extract the files in
a folder "tools", and this extraction folder will contain a single folder with
the same name.
Before this fix, the tool would try to move out the inside folder to the parent
one, but there would already be a folder named "tools", so it would generate a
conflict.
This change first renames the inside folder to a random string, and only then
it is moved outside and the old extraction folder is deleted.
Previously this was only emitted on macOS with Apple's Terminal.app (and
compatible clones like iTerm2), but it is used by other terminal emulators
as well to obtain the actual current working directory wiht symlinks intact.
All non-supporting terminal emulators tested gracefully ignored this value,
so emit this on these as well in case they (or some other app masquarading
as them) add future support for this value.
Closes#9914
Co-authored-by: Marc Cornellà <hello@mcornella.com>
BREAKING CHANGE: the previous zstyle setting to disable `lib/directories.zsh` aliases has
been changed to the new syntax: `zstyle ':omz:lib:directories' aliases no`. See
https://github.com/ohmyzsh/ohmyzsh#skip-aliases to see other ways you can use this setting.
Co-authored-by: Carlo Sala <carlosalag@protonmail.com>
The previous code would remove the extract directory if the command failed.
This could be bad because we're not checking if the extract directory
already existed (since we're using `mkdir -p`), so it could be possible
that the extract operation failed, and we'd be removing a directory that
already existed and had files in it.
This change only removes the directory if there are no files in it, regardless
of whether the extract operation was successful or not. This is much safer.
