Archive creation with z fails when current target directory path contains spaces

[Skribinto]

When using the built-in archive function in nnn via z, creating a ZIP archive works correctly if the current directory path does not contain spaces. However, if the current directory path contains spaces, the archive path appears to be split incorrectly. As a result, the ZIP file is created in a wrong parent directory and with a wrong truncated filename.

This happens even when I only enter a simple archive filename, e.g. FOD-28269.zip, without any path component.

The selected input files themselves appear to be handled correctly, including files located in directories with spaces. The problem seems to affect the generated archive output path, i.e. the destination path derived from the current working directory plus the archive filename.

Environment:

• OS: Fedora Linux
• Shell: bash
• nnn version: 5.2
• zip version: 3.0
• atool version: 0.39.0
• Terminal: Kitty

Relevant .bashrc configuration:

export PATH="/usr/bin:$PATH"
export NNN_PREVIEWWIDTH=${NNN_PREVIEWWIDTH:-1920}
export NNN_PREVIEWHEIGHT=${NNN_PREVIEWHEIGHT:-1080}
export NNN_TRASH=2
export NNN_PLUG="n:nuke;o:ocr;p:preview-tui;c:newcase;z:zipadd;r:redline_run"
export NNN_FIFO="${XDG_RUNTIME_DIR:-/tmp}/nnn.fifo.${USER}"
export NNN_SEL="${XDG_CONFIG_HOME:-$HOME/.config}/nnn/.selection"

alias nnn='nnn -de'

I have installed the archive-related tools:

sudo dnf install atool zip unzip libarchive

Steps to reproduce:

Create or open a directory whose path contains spaces, for example:

mkdir -p "$HOME/tmp/nnn zip test/1 - My Files"
cd "$HOME/tmp/nnn zip test/1 - My Files"
touch "file one.txt" "file two.txt"
nnn

In nnn, select one or more files.
Press z to create an archive.
Enter only a plain archive filename, without any path:
test.zip

Expected behavior:
nnn should create the archive here:

$HOME/tmp/nnn zip test/1 - My Files/test.zip

The archive filename should be exactly:

test.zip

Actual behavior:
The archive is not created in the current directory. Instead, it is created higher up in the directory tree, apparently before the first path component containing spaces. The filename is truncated or derived from the beginning of the following path component.

In my real case, the current directory was similar to:

/home/marcel/Dokumente/Büro/0 - ToDo/260506 - ABC Test/1 - Meine Dateien

When entering only:
Test.zip

the resulting ZIP file was not created inside 1 - Meine Dateien. Instead, it was created in the parent path before the directory containing spaces, and its filename was derived from the path component up to the first space.

In another run, when using a path with spaces, zip printed warnings such as:

zip warning: name not matched: Akten/ETL/Fod-28269/1
zip warning: name not matched: Meine
zip warning: name not matched: Dateien/FOD-28269.zip
  adding: - (stored 0%)

This suggests that the archive destination path is not quoted or escaped correctly before being passed to the archive command.

Control test:
The same workflow works correctly when the current directory path contains no spaces. For example, creating a ZIP archive from within a directory such as:

/home/marcel/tmp/nnnziptest

works as expected.

Additional observation:
The selected input files seem to be passed correctly, even when their paths contain spaces. The failure appears to concern only the output archive path generated from the current directory and the entered archive filename.

Possible cause:
The archive output path may be constructed as an absolute path and then passed to the archive command without proper shell quoting or without being treated as a single argument. This causes paths like:

.../1 - Meine Dateien/FOD-28269.zip

to be split into separate arguments.

Thank you for any help!