Star (*) is expanded into archive name in output path for 7z x command
A free file archiver for extremely high compression
Brought to you by:
ipavlov
7z seems to expand star (*) in the output (-o) path to archive's name. To reproduce:
mkdir test; cd test
touch file.txt
mkdir -p './star*path/output'
7z a NAME.7z file.txt
7z x -o'./star*path/output' NAME.7z
The result is creation of ./starNAMEpath/output/file.txt . Looks like a bug, since star is a legit path symbol and there is no mention that 7z expands it into anything in path as far as I can tell.
Also tried to add backslashes - they do not do anything(aside from appearing in path).
system: debian 13
7z version: 7-Zip 25.01 (x64) : Copyright (c) 1999-2025 Igor Pavlov : 2025-08-03
64-bit locale=en_US.UTF-8 Threads:20 OPEN_MAX:524288, ASM
Sorry, first time using sourceforge, did not know it fucks up newlines in code formatting. Here is the thing in code block, but with new lines:
mkdir test; cd test
touch file.txt
mkdir -p './star*path/output'
7z a NAME.7z file.txt
7z x -o'./star*path/output' NAME.7z
It does not.
`
line 1
line 2
line 3
`
line 1 line 2 line 3```
line 1
line 2
line 3
```
Markdown Syntax Guide
Last edit: Sam Tansy 2026-02-06
Okay, so sourceforge use markdown, good to know. But "Code" button gives just ``, not triple backticks. And I cant find a way to edit original post.
This is completely unrelated to the bugreport issue and a problem on the sourceforge poor interface (hiding this information behind a button does not help much for first time users like me. Simple notation "We use markdown" would be much better - I cant be bothered to read documentation on formatting of a site I do not intend to use more than one time).
I would much prefer at least a word on current topic - is this by chance intended behavior or not. Because if it is intended - '-o' is almost useless - because it does not treat path string just as string, but a path template, I now extract into temp folder for which I control path, to make sure contents does not go somewhere unpredictable or cause some wild issue from unintentional expansion of * into something malicious.
Last edit: lynx 2026-02-06
Eeeeehhh.
That's what I get:
Which (~~~) is equivalent to ```.
--
Own ticket modification is impossible
You can join feature request, maybe if more people request it, it will work.
Last edit: Sam Tansy 2026-02-06
Right, this is what you get when you press Code button on empty selection. I pressed it on a string and got `string` which then used to create multi line code snippet that gobbled up newlines. If you press Code on multi-line selection it will give block framed by triple tilde. Is any of these things explained anywhere in button description? No.
(Yeah, I could do some guessing about it or reading about formatting before posting, but who does that before first post? Inability to edit ticket even for short duration like ~1h to iron out formatting or other errors is a bummer to say the least.)
Last edit: lynx 2026-02-10
It's feature for Windows version:
Linux version was released later. So it still uses that feature.
You can do it so now : create directory, change current directory to that created path, and then extract archive to that current directory.
Maybe we need new additional switch to turn off that feature in Linux.
Last edit: Igor Pavlov 2026-02-06
Info-zip, and many other tools, use `--' for that purpose.
It's not only switches pathname expansion off but does it 'locally' i.e. only after switch all arguments are treated as paths, before expansion works as usual.
Thanks, it would be nice to have a mention of this feature in
man 7zor7z --helpso it would not be that surprising to find it by chance when something in path given to '-o' contains a star.I can see why it would be useful on Windows with its poor cmd shell, but even then there is a for loop for this kind of thing. With a fast google search it gives some ugly cmd style snippet doing
7z x *.zip -o*asWhich is not that far from its bash equivalent, so I guess this feature is not that needed? Not sure how much people depend on 7z internal expansion of * into archive name. I think leaving string and path manipulation to a shell (and utilities like tr,cut,awk,find,... created for this) is generally a more sane approach.
Last edit: lynx 2026-02-10
I use it regardless of operating system. It's useful when you want unpack specific files in archive like:
You can do that right now:
will expaded by shell, and
will be expanded by 7z.
That's exactly why turning expansion if would be useful feature. If you wanted to pass list of files, and they contained 'crazy' characters like '*', '?\ , or '-' you can be scrwd. by 7-zip, but if you disabled expansion at given point, like '--' does in zip, then everything would be fine and you didn't have to worry about unexpected, unhandled fall over.