Added links to usage of lua-zip

[nonunicorn]

• https://onelinerhub.com/lua/how-to-extract-zip-file
• https://onelinerhub.com/lua/how-to-compress-a-file-to-zip-archive

[MisterDA]

Instead of linking to an external website you should rather add the example in the repo or add them as tests.

[nonunicorn]

That's exactly what we did - added it to a github repo - a collection of code solution (external site is just a navigation UI):

• https://github.com/Onelinerhub/onelinerhub/blob/main/lua/how-to-compress-a-file-to-zip-archive.md
• https://github.com/Onelinerhub/onelinerhub/blob/main/lua/how-to-extract-zip-file.md

[brimworks]

@nonunicorn - a few documentation suggestions for onelinerhub:

• Since this (brimworks.zip) is an external library, I'd suggest adding to the onelinerhub documentation information on how to install the library with luarocks (which seems to be the lua ecosystem default package manager).
• For file extraction, I think most people will be interested in extracting either the entire zip, or a specific file within the zip. To support the latter, I'd suggest adding documentation for zip_arc:name_locate(filename) at a minimum. For example:

  
  zip = require 'brimworks.zip'

local zip_arc = zip.open('/tmp/file.zip') print("# of files in archive" .. #zip_arc) local test_index = zip_arc:name_locate("test.txt") local file = zip_arc:open(test_index) local stat = zip_arc:stat(test_index) local str = file:read(stat.size) file:close()

print(str)

zip_arc:close()

- Also note that you need to close your file extraction handles. More specifically, you are missing a call to `file:close()`
- Finally, I'd recommend linking https://github.com/Onelinerhub/onelinerhub/blob/main/lua/how-to-extract-zip-file.md back to https://github.com/Onelinerhub/onelinerhub/blob/main/lua/how-to-compress-a-file-to-zip-archive.md so one can see  a round-trip of "/tmp/test.txt" getting archived and then extracted.

@MisterDA - I think the intent here is to add back-links... since onelinerhub is proposing to add usage of this library in their reference documents. Otherwise, I would have tended to agree with you, that in-repository documentation is better.

[nonunicorn]

Thanks man! Will update that shortly.