On Wed, 21 May 2025 20:21:18 GMT, Lance Andersen <lan...@openjdk.org> wrote:
>> src/jdk.jartool/share/man/jar.md line 223: >> >>> 221: As a jar archive is based on ZIP format, it is possible to create a >>> jar archive using tools >>> 222: other than the `jar` command. The --validate option may be used to >>> perform the following >>> 223: integrity checks against a jar archive: >> >> Nit - "integrity checks against a JAR file:" > > I think we have other inconsistencies that we can clean up at a later time in > the help and man page for the jar tool in the usages of archive/file. > > The man page description can use a further overhaul as we still reference > applets. So we can do this also as follow on work I changed references in the new content and leave the retrofit to future works. >> src/jdk.jartool/share/man/jar.md line 235: >> >>> 233: versions. >>> 234: >>> 235: The jar tool returns a status code of 0 if there were no integrity >>> issues encountered, otherwise >> >> Nit - we should call it exit code instead of status code, both for 0 and >> non-zero exit codes. > >> Nit - we should call it exit code instead of status code, both for 0 and >> non-zero exit codes. > > I don't have a preference but unix/MacOS commands vary: > > - ls command: The ls utility exits 0 on success, and >0 if an error occurs. > - grep command: > >> The grep utility exits with one of the following values: > > 0 One or more lines were selected. > 1 No lines were selected. > >1 An error occurred. > > - unzip command: > >> The exit status (or error level) approximates the exit codes defined by >> PKWARE and takes on the > following values, except under VMS: > > 0 normal; no errors or warnings detected. > > 1 one or more warning errors were encountered, but > processing completed successfully > anyway. This includes zipfiles where one or more files > was skipped due to unsupported > compression method or encryption with an unknown > password. > > 2 a generic error in the zipfile format was detected. > Processing may have completed > successfully anyway; some broken zipfiles created by > other archivers have simple work- > arounds. > 3 a severe error in the zipfile format was detected. > Processing probably failed > immediately. > > 4 unzip was unable to allocate memory for one or more > buffers during program > initialization. > > 5 unzip was unable to allocate memory or unable to obtain > a tty to read the decryption > password(s). > > 6 unzip was unable to allocate memory during decompression > to disk. > > 7 unzip was unable to allocate memory during in-memory > decompression. > > 8 [currently not used] > > 9 the specified zipfiles were not found. > > 10 invalid options were specified on the command line. > > 11 no matching files were found. > > 50 the disk is (or was) full during extraction. > > 51 the end of the ZIP archive was encountered prematurely. > > 80 the user aborted unzip prematurely with control-C (or > similar) > > 81 testing or extraction of one or more files failed due to > unsupported compression methods > or unsupported decryption. > > 82 no files were found due to bad decryption password(s). > (If even one file is successfully > ... I use exit code, but still keep non-zero instead of > 0. Leave that to future work if we want to have more specific value for exit code for different situations. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2101457168 PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2101458911
