-
-
Notifications
You must be signed in to change notification settings - Fork 376
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
makeself removes directory name when specifying directory without sub-directories #314
Comments
If I understand correctly, makeself doesn't support multiple source
directories.
…On Tue, Aug 29, 2023, 11:01 Peter Whittaker ***@***.***> wrote:
Given a directory bin containing two files, test1 and test2, I would
expect different behaviour when running the two commands
makeself --current ./bin ~/test.sh test_label
cd bin; makeself --current . ~/test.sh test_label
but the results are exactly the same:
Adding files to archive named "test.sh"...
./test1
./test2
The second command does what I would expect: it creates an archive
containing the contents of bin, but without any path information. This is
consistent with cd bin; tar cf ../test.tar ., for example. Perfect!
But I would expect the first command to be consistent with tar cf
test.tar ./bin, that is, I would expect it to preserve the relative path
information. In other words, I would expect
Adding files to archive named "test.sh"...
./bin/test1
./bin/test2
After all, if I go to bin's parent directory, and execute makeself
--current . test.sh somelabel, I get
Adding files to archive named "test.sh"...
./bin/test1
./bin/test2
which, again, is consistent with cd ..; tar cf test.tar . (assuming one
started in bin).
FWIW, I discovered this while attempting to incrementally build a
self-extractor of only parts of my current working directory. E.g., I have
a directory containing .git, bin, etc, var, lib, wlp, examples, README,
Makefile, testing, etc., and I only want to include bin, etc, lib, and var
in my archive.
In other words, I wanted to do
makeself --current ./bin test.sh somelabel
makeself --append ./lib test.sh somelabel
makeself --append ./etc test.sh somelabel
makeself --append ./var test.sh somelabel
but everything ends up being flattened, which is not what I expected.
The only supported way to do this is to use --tar-extra --exclude=wlp
--exclude examples --exclude Makefile..., which is a bit clunky, since I
may have far more directories that aren't bin, etc, lib, or var. (I've
tried getting a man 7 glob pattern that works but have had no luck.)
—
Reply to this email directly, view it on GitHub
<#314>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AKY6BKLPY4RNZJ6Q3FJYA2LXXX743ANCNFSM6AAAAAA4DDGIPA>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Yeah, that's the way it has been for a long time and changing this behavior would probably break the way people use the tool already. That said I'd be open to enabling a new kind of behavior over time to make this easier. |
Agreed. When and if the "calling convention" for creation/appendation is
changed to support multiple tar arguments, this would become feasible.
…On Tue, Aug 29, 2023, 18:19 Stéphane Peter ***@***.***> wrote:
Yeah, that's the way it has been for a long time and changing this
behavior would probably break the way people use the tool already.
That said I'd be open to enabling a new kind of behavior over time to make
this easier.
—
Reply to this email directly, view it on GitHub
<#314 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AKY6BKKVOVFPSUL2RUGUZVLXXZTGPANCNFSM6AAAAAA4DDGIPA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
What if we introduced two different calling conventions, which would be easily detectable via command line argument processing?
For sake of argument, assume that So far, so good. Then we add a flag, e.g., Under this scheme, This wouldn't be a breaking change, since users could continue to use the original calling convention. |
What if we introduced two different calling conventions, which would be
easily detectable via command line argument processing?
Okay, I see where you're going with this. If I understand correctly, then I
have some criticisms I would like to share.
1. The current positional scheme, in which self-extractor name and label must always be present, and
2. A flagged scheme, in which all arguments are specified via flag?
Yes, this trick is familiar to me. My general criticism is that it complicates
the parsing logic for the option flags, option arguments, and positional
arguments. Because users make mistakes, you can expect `makeself` to be invoked
with every possible combinatorial expansion of opts and args. This usually
forces you to do at least one of the following:
* Absorb (and save) the entire `argv` before attempting to parse it.
* Parse each option iteratively while aggressively vetting each to defend
against mutually conflicting options.
For sake of argument, assume that `-s ...` denotes the name of the
self-extractor and and `-l ...` denotes the label. Then, under the new
convention, `-s ... -l ...` would be required, unless `--append` was
supplied, in which case only `-s ...` was supplied.
Consider the case where the caller invokes
makeself.sh -s foobar -l 'Foo Bar' mything mything.run 'My Thing' ./start.sh
The caller's invocation _seems_ incorrect until you consider the possibility
that any of the non-option positional arguments could be an intentional
reference to a directory in `$PWD`. You can't know they don't exist until `tar`
fails to add them.
Then we add a flag, e.g., `--root` or `--base`, which, regardless of the path
elements to include in the archive represents the top level directory of the
archive, from which all included files are interpreted.
Under this scheme, `--root/--base` would be required inly under creation, not
under `--append -s ...`, which would respect this initial setting (and
initial `-l label` as well, e.g.).
I like this even less. If `makeself` must grow an option denoting a "starting
directory", then imho it should be `-C` and behave identically to that of
`tar`. In fact, I'm going to go on record and say: the closer we can push the
`makeself` calling convention to that of `tar`, the better.
This wouldn't be a breaking change, since users could continue to use the
original calling convention.
You're correct in that the change you propose wouldn't break the interface
embodied by the calling convention. It would, however, require:
* at least 3 additional options; i.e., one for each of the current
non-`archive_dir` positional arguments
* `argv` accumulation before parsing and/or aggressive vetting during `argv`
iteration
The problem here is really that, in its current form, `makeself` takes a
_singular_ input directory and an _arbitrary_ quantity of `script_args`. To
turn this convention on its head is non-trivial.
|
Given a directory
bin
containing two files,test1
andtest2
, I would expect different behaviour when running the two commandsmakeself --current ./bin ~/test.sh test_label
cd bin; makeself --current . ~/test.sh test_label
but the results are exactly the same:
The second command does what I would expect: it creates an archive containing the contents of bin, but without any path information. This is consistent with
cd bin; tar cf ../test.tar .
, for example. Perfect!But I would expect the first command to be consistent with
tar cf test.tar ./bin
, that is, I would expect it to preserve the relative path information. In other words, I would expectAfter all, if I go to bin's parent directory, and execute
makeself --current . test.sh somelabel
, I getwhich, again, is consistent with
cd ..; tar cf test.tar .
(assuming one started inbin
).FWIW, I discovered this while attempting to incrementally build a self-extractor of only parts of my current working directory. E.g., I have a directory containing .git, bin, etc, var, lib, wlp, examples, README, Makefile, testing, etc., and I only want to include bin, etc, lib, and var in my archive.
In other words, I wanted to do
but everything ends up being flattened, which is not what I expected.
The only supported way to do this is to use
--tar-extra --exclude=wlp --exclude examples --exclude Makefile...
, which is a bit clunky, since I may have far more directories that aren't bin, etc, lib, or var. (I've tried getting aman 7 glob
pattern that works but have had no luck.)The text was updated successfully, but these errors were encountered: