[Feature Request]: Creation or extraction archive file in one line

[davidds1990]

Feature description

Hi
Can you provide a static function that takes the same arguments as the 7z CLI App? (Similar to the main function in 7z)
This function can be very useful (creation or extraction archive file in one line).

CLI:

7z.exe x archive.7z
7z.exe a -t7z -m0=lzma2 -mx=9 -mfb=64 -md=64m -ms=on -mhe=on -p"Hello world!" archive.7z your_dir

Static function (for example):

int ret = bit7z::cli7z("7z.dll", "x archive.7z");
int ret = bit7z::cli7z("7z.dll", "a -t7z -m0=lzma2 -mx=9 -mfb=64 -md=64m -ms=on -mhe=on -p\"Hello world!\" archive.7z your_dir");

Additional context

No response

Code of Conduct

• By submitting this issue, I agree to follow bit7z's Code of Conduct

[rikyoz]

Hi!
Unfortunately, the 7-Zip DLLs do not provide a direct way to execute the CLI arguments, so bit7z would need to implement a parser that, given the string of arguments, will execute the corresponding command with the given options.
It's not a top priority for the project, as I still need to implement some missing and complex features, but I'll definitely evaluate providing such functionality.
Thanks for pointing it out!

[levicki]

@rikyoz I think this should be out of scope of your bit7z library.

Rationale:

1. Writing such a parser is a significant feature creep for little to no benefit for most library users who want to use the API and supporting all the versions of 7-Zip SDK and all the command line options past and future would take away a lot of your time which could be better used to maintain the bit7z library in sync with 7-Zip SDK and modern C++ features.

2. Writing such a parser would duplicate already existing code written by Igor Pavlov. Those wanting to use command line arguments and a single function call instead of several low-level API calls should just call CreateProcess or ShellExecute on 7za.exe with those arguments instead of using a library with a low-level API and expecting command line arguments to work there.

[rikyoz]

I think this should be out of scope of your bit7z library.

Rationale:

1. Writing such a parser is a significant feature creep for little to no benefit for most library users who want to use the API and supporting all the versions of 7-Zip SDK and all the command line options past and future would take away a lot of your time which could be better used to maintain the bit7z library in sync with 7-Zip SDK and modern C++ features.
2. Writing such a parser would duplicate already existing code written by Igor Pavlov. Those wanting to use command line arguments and a single function call instead of several low-level API calls should just call CreateProcess or ShellExecute on 7za.exe with those arguments instead of using a library with a low-level API and expecting command line arguments to work there.

I definitely agree with your points!
As I said, this feature is definitely not a top priority for bit7z.

I'm currently working on the next v4.1, which will have some (relatively big) new features (e.g. nested archive support) and performance improvements.
I'm also thinking about the next v5.0, which will probably see some heavy code cleanup and the removal of support for old compilers and C++11/C++14 standards.
This will allow me to improve the overall API of the library.
After all, the main reason I created this library is to improve my knowledge of C++.

So yes, there's a lot of higher priority work.
I don't want to completely rule out this feature though, as I think it could help in some marginal use cases; but I won't be implementing it any time soon.

[levicki]

I don't want to completely rule out this feature though, as I think it could help in some marginal use cases; but I won't be implementing it any time soon.

As a matter of fact I believe you should rule it out completely -- people should learn to use the proper tool for the job instead of going around and trying to coerce developers to turn every tool into every other tool with everything and a kitchen sink included.

• If you need to work with low level 7-Zip compression and decompression API use the bit7z library.
• If you need to work with 7-Zip compatible command line options then just use the 7za.exe command line executable.

It really is and should be that simple.

If someone doesn't know how to launch a command line process, pass arguments to it, create and use pipes to track progress written by the command line tool to STDOUT then that's their problem, not yours -- all those things are trivial to implement with example code readily available and would suit their use case better.

The reason I am so adamant about this is that I recently saw some idiots who requested to change TOML specification to allow line breaks in INLINE tables. That not only breaks the meaning of the word inline and the purpose of those tables, but it also turns TOML into something more resembling JSON. So now instead of having one human-readable TOML and one not human-readable JSON we will have two configuration file formats which will both be almost equally unreadable. That kind of insanity needs to be stopped, not encouraged.

[rikyoz]

As a matter of fact I believe you should rule it out completely -- people should learn to use the proper tool for the job instead of going around and trying to coerce developers to turn every tool into every other tool with everything and a kitchen sink included.

• If you need to work with low level 7-Zip compression and decompression API use the bit7z library.
• If you need to work with 7-Zip compatible command line options then just use the 7za.exe command line executable.

It really is and should be that simple.

Yeah, I have given it some more thought and I completely agree with you: I will not implement such a feature.
However, I may add some sections to the documentation explaining how certain common 7z commands can be translated into bit7z code. So I'll leave the issue open as a reminder.

The reason I am so adamant about this is that I recently saw some idiots who requested to change TOML specification to allow line breaks in INLINE tables. That not only breaks the meaning of the word inline and the purpose of those tables, but it also turns TOML into something more resembling JSON. So now instead of having one human-readable TOML and one not human-readable JSON we will have two configuration file formats which will both be almost equally unreadable. That kind of insanity needs to be stopped, not encouraged.

This is really insane and I totally understand your point of view!