Hi Jaikiran,
Thank you for this. I went through this myself yesterday in addition to what
you have below here are a few more:
7zip: -o
Info-zip: -d (MacOS version of zip)
Bandzip: -o:{dir}
jpackage: -d —dest
jlink —output
Thinking about this some more, I might suggest supporting
-C
—dir
—directory
Best
Lance
On Feb 27, 2021, at 11:19 PM, Jaikiran Pai
<[email protected]<mailto:[email protected]>> wrote:
Hello Alan,
On 27/02/21 2:23 pm, Alan Bateman wrote:
Yes, the option name will need to be agreed. It would be useful to enumerate
the options that the other tools are using to specify the location where to
extract. If you see JBS issues mentioning tar -C not supporting chdir when
extracting then it might be Solaris tar, which isn't the same as GNU tar which
has different options. It might be better to look at more main stream tools,
like unzip although jar -d is already taken. It would be nice if there were
some consistency with other tools in the JDK that doing extracting (The jmod
and jimage extract commands use use --dir for example).
I had a look at both tar and unzip commands on MacOS and Linux (CentOS) setup
that I had access to.
--------------
tar on MacOS:
--------------
tar --version
bsdtar 3.3.2 - libarchive 3.3.2 zlib/1.2.11 liblzma/5.0.5 bz2lib/1.0.6
The version of this tool has:
-C directory, --cd directory, --directory directory
In c and r mode, this changes the directory before adding the
following files.
In x mode, change directories after opening the archive but before
extracting
entries from the archive.
A command like "tar -xzf foo.tar.gz -C /tmp/bar/" works fine and extracts the
foo.tar.gz from current directory to a target directory /tmp/bar/
--------------
tar on CentOS:
--------------
tar --version
tar (GNU tar) 1.26
This version of the tool has:
Common options:
-C, --directory=DIR
change to directory DIR
Although the wording isn't clear that, when used with -x, it extracts to the
directory specified in -C, it does indeed behave that way.
Specifically, a command like "tar -xzf foo.tar.gz -C /tmp/bar/" works fine and
extracts the foo.tar.gz from current directory to a target directory /tmp/bar/
-------------------------------
unzip on both MacOS and CentOS:
-------------------------------
unzip -v
UnZip 6.00 of 20 April 2009, by Info-ZIP. Maintained by C. Spieler.
This version of the tool has:
[-d exdir]
An optional directory to which to extract files. By default, all
files and sub-
directories are recreated in the current directory; the -d option
allows extrac-
tion in an arbitrary directory (always assuming one has
permission to write to
the directory). This option need not appear at the end of the
command line; it
is also accepted before the zipfile specification (with the
normal options),
immediately after the zipfile specification, or between the
file(s) and the -x
option. The option and directory may be concatenated without
any white space
between them, but note that this may cause normal shell
behavior to be sup-
pressed. In particular, ``-d ~'' (tilde) is expanded by Unix C
shells into the
name of the user's home directory, but ``-d~'' is treated as a
literal subdirec-
tory ``~'' of the current directory.
unzip foo.zip -d /tmp/bar/ works fine and extracts the foo.zip from current
directory to /tmp/bar/
---------------
jimage and jmod
---------------
The jimage and jmod as you note use the --dir option for extracting to that
specified directory.
Those were the tools I looked at. I think using the -d option with -x for the
jar command is ruled out since it already is used for a different purpose,
although for a different "main" operation of the jar command.
As for using --dir for this new feature, I don't think it alone will be enough.
Specifically, I couldn't find a "short form" option for the --dir option in the
jimage or jmod commands. For the jar extract feature that we are discussing
here, I think having a short form option (in addition to the longer form) is
necessary to have it match the usage expectations of similar other options that
the jar command exposes. So even if we do choose --dir as the long form option,
we would still need a short form for it and since -d is already taken for
something else, we would still need to come up with a different one. The short
form of this option could be -C (see below).
I think reusing the -C option, for this new feature, perhaps is a good thing.
The -C is currently used by the update and create "main" operation of the jar
command and the man page for this option states:
-C dir
When creating (c) or updating (u) a JAR file, this option
temporarily changes
the directory while processing files specified by the file
operands. Its
operation is intended to be similar to the -C option of the UNIX
tar utility.For
example, the following command changes to the classes directory
and adds the
Bar.class file from that directory to my.jar:
jar uf my.jar -C classes Bar.class
....
Using the -C option would indeed align it with the tar command. For the "long
form" of this option, the tar command (both on MacOS and CentOS) uses
--directory. For this jar extract feature though, we could perhaps just use
--dir to have it align with the jimage and the jmod tools.
So I think the combination of -C (short form) and --dir (long form) would
perhaps be suitable for this feature.
There are other discussion points around the behavior when the target directory
exists or does not exist, to ensure there is some consistency with main stream
tools.
I'm guessing you mean the behaviour of creating a directory (or a hierarchy of
directories) if the target directory is not present? My testing with the tar
tool (both on MacOS and CentOS) shows that if the specified target directory
doesn't exist, then the extract fails. The tar extract command doesn't create
the target directory during extract. On the other hand, the unzip tool, does
create the directory if it doesn't exist. However, interestingly, the unzip
tool creates only one level of that directory if it doesn't exist.
Specifically, if you specify:
unzip foo.zip -d /tmp/blah/
and if "blah/" isn't a directory inside /tmp/ directory, then it creates the
"blah/" directory inside /tmp/ and then extracts the contents of the zip into
it.
However,
unzip foo.zip -d /tmp/blah/hello/
and if "blah/" isn't a directory inside /tmp/ directory, then this command
fails with an error and it doesn't create the hierarchy of the target
directories.
Coming to the jimage and the jmod commands, both these commands create the
entire directory hierarchy if the target directory specified during extract,
using --dir, doesn't exist. So a command like:
jimage extract --dir /tmp/blah/foo/bar/ jdkmodules
will create the blah/foo/bar/ directory hierarchy if blah doesn't exist in
/tmp/, while extracting the "jdkmodules" image.
From the user point of view, I think this behaviour of creating the directories
if the target directory doesn't exist, is probably the most intuitive and
useful and if we did decide to use this approach for this new option for jar
extract command, then it would align with what we already do in jimage and jmod
commands.
One another minor detail, while we are at this, is that, IMO we should let the
jar extract command to continue to behave the way it currently does when it
comes to overwriting existing files. If the jar being extracted contains a file
by the same name, in the target directory (hierarchy) then it should continue
to overwrite that file. In other words, I don't think we should change the way
the jar extract command currently behaves where it overwrites existing files
when extracting.
-Jaikiran
[cid:E1C4E2F0-ECD0-4C9D-ADB4-B16CA7BCB7FC@home]
Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
[email protected]<mailto:[email protected]>
