Skip to content
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

Open
PeterWhittaker opened this issue Aug 29, 2023 · 5 comments

Comments

@PeterWhittaker
Copy link
Contributor

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.)

@realtime-neil
Copy link
Contributor

realtime-neil commented Aug 29, 2023 via email

@megastep
Copy link
Owner

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.

@realtime-neil
Copy link
Contributor

realtime-neil commented Aug 29, 2023 via email

@PeterWhittaker
Copy link
Contributor Author

What if we introduced two different calling conventions, which would be easily detectable via command line argument processing?

  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?

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.

So far, so good.

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.).

This wouldn't be a breaking change, since users could continue to use the original calling convention.

@realtime-neil
Copy link
Contributor

realtime-neil commented Sep 5, 2023 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants