[Feature Request] Better scripting support

[will-ca]

Is your feature request related to a problem? Please describe.
Scriptable tools are useful. Treating "profiles" as opaque units, while possibly convenient for some uses, also hurts flexibility.

Describe the solution you'd like
Support for a simple option like --stdout, --save -, --save /dev/stdout, or --print <profile> would be great.

If you want to take it further, accepting input from STDIN (E.G. --i -) could also be interesting. Then you could do stuff like nc -l -p 1234 | konsave -i - on one machine and konsave -s - | nc newLaptop.localLAN 1234 to instantly transfer or synchronize your configuration.

Describe alternatives you've considered
The alternative is the current system of opaque "profiles" and ".knsv" files, which can be both messy in workflow (I.E. requires mucking with files) and messy in its effect on the system (I.E. saves state in persistent files, ironically creating even more hidden configuration to worry about, plus filepath collisions and so on).

Additional context
Since it appears that profiles are file hierarchies and ".knsv"s are ZIP archives, it's not clear what exactly should be emitted.
Personally I think either raw binary data or Base64 would be fine, as long as it's specified in the help text.

[Prayag2]

Can you give example usage of the --stdout, --save, --print options?

[will-ca]

Can you give example usage of the --stdout, --save, --print options?

Well, I meant those as different names for the same thing, just not sure what it should be called.

E.G.:

Instead of saving the profile in ~/.config, send it to port 1234 at the IP address 5.6.7.8:

$ konsave --save /dev/stdout | nc 5.6.7.8 1234

Instead of saving the profile in ~/.config, compress it and then save it in ~/Downloads:

$ konsave --save /dev/stdout | gzip > ~/Downloads/Profile.gz

Instead of importing the profile from ~/.config, listen on network port 1234 for data and import that as a profile. So if you combine this with the other nc example, you can directly transfer your profile between machines without having to copy any files:

$ nc -l -p 1234 | konsave --apply /dev/stdin

These examples do not make perfect sense however, since the profiles are saved as directory structures so there's no way to directly represent them as a stream. That could possibly be solved by E.G. using .tar as the format instead of naked folders. For the export (-e) option, the .zip itself can just be used as the bitstream though.

---

Mainly this is about workflow and automation. A lot of Unix-style tools are built around the idea of connecting multiple processes together with pipes and redirections, so being able to output to STDOUT or take input from STDIN opens a lot of flexibility. For example, I have a script that runs konsave plus a couple other commands to generate a snapshot of multiple aspects of system configuration— Currently it has to invoke konsave and then tar separately because konsave itself does not output to STDOUT (which in turn also means that the tar command needs to hardcode the expected konsave output path in ~/.config, which is then also more fragile, messier, and less flexible, etc.).

[Prayag2]

Okay, I somewhat get what you're trying to say.
From what I understand, I can try to implement the following:

1. Read path to the profile from stdin using a - in the apply and import options (like ls | grep profile | konsave --apply -.
2. An --stdout option that would send the "path" to the saved/exported profile to standard output. (like konsave --export myProfile --stdout would send, for example, /home/user/profile.knsv to stdout)

I'm not sure how one would send a whole profile (which is a directory) to a stream, so I can try to send the "path" instead.
Also, I've never used nc or gzip so it's a bit unclear to me. Can you show me examples with simpler tools like cp, mv, unzip etc..?

[will-ca]

so I can try to send the "path" instead.

Hm. That could work. Although I think most other tools expect data to come in on STDIN and paths to be given as command line parameters, so it would probably require xargs to be added to the command or command substitution to be used instead of pipes.

In the first example, nc is taking a byte stream in its STDIN from konsave's STDOUT and sending it unmodified over the network. In the third example, nc is listening for a byte stream from the network and piping it through its STDOUT to konsave's STDIN.

In the second example, gzip is taking a byte stream in its STDIN from konsave's STDOUT and outputting a compressed version of that stream, which the shell is redirecting and saving into a file. You can replace gzip with zip in that command, and I think it should do the same kind of thing:

$ konsave --save /dev/stdout | zip > ~/Downloads/Profile.zip

I'm not sure there's much point to doing this with cp or mv— I guess cp and mv operate only on paths in the filesystem/metadata, whereas piping is best for tools that operate on data/file contents. Another one that I have been using, though, is base64— That lets you embed it in JSON files and such. You can also do one-line scripts with Python or QuickJS:

$ konsave --save /dev/stdout | python3 -c 'import MyModule, sys; MyModule.addTodaysSnapshotToDatabase(sys.stdin.read())'

$ konsave --save /dev/stdout | base64 | qjs --std -e 'doSomeStuff(sys.in.readAsString())'

I'm not sure how one would send a whole profile (which is a directory) to a stream

I was actually wondering— Might it be beneficial to change the entire output format to .tar, instead of a directory?

[Prayag2]

I was actually wondering— Might it be beneficial to change the entire output format to .tar, instead of a directory?

It might be and I can do that. It's not much work but I had a question, do we just send the path to the .tar file to stdout or does it actually send the "data" in the file? Wouldn't sending an entire file (in some cases the file size can reach 1gb) require storing it in memory?

[will-ca]

It's not much work but I had a question, do we just send the path to the .tar file to stdout or does it actually send the "data" in the file?

Hm. I guess pipe syntax (E.G. cat RawFile | gzip > Compressed.gz) works best with sending the actual file data, while command substitution (E.G. gzip $(cat FilePaths)) would work better for sending the path. When I mention outputting to STDOUT, I'm mainly thinking of piping the whole file data as that lets commands be chained without messing with the filesystem.

Wouldn't sending an entire file (in some cases the file size can reach 1gb) require storing it in memory?

Depends on how it's handled I guess? I suppose in this case if the file can get that big you might want to save it to disk in a temp file first, and then stream it. Or, if the file structure makes it feasible, the "right" way to do it would probably usually be to output the data in sequence as the file is built. But there shouldn't ever be any need to store the whole file in memory at once— It can be output to STDOUT line-by-line, block-by-block, or even one byte at a time.