6

I have created a simple package using this guide, but I can't run the script inside it.

There is a folder named mypack, which includes /usr/bin/myscript.sh with some command in it (let's say it just echoes a message like "Hello World"), and a folder named DEBIAN with a control file with this text inside:

Package: mypack
Version: 1.0-1
Maintainer: Alex
Architecture: all
Section: misc
Description: echo me

I built and installed it using dpkg-deb --build mypack; dpkg -i mypack.deb as the guide says.

Finally, when I wanted to run the script script to see if it is works, I could not. I have tried:

  1. myscript (returns myscript: command not found)
  2. myscript.sh (returns bash: /usr/bin/myscript.sh: Permission denied)
  3. sudo myscript.sh (returns sudo: myscript.sh: command not found)
  4. mypack myscript and mypack myscript.sh (both return mypack: command not found)

How can I execute it then, so it actually works, or am I missing some important steps, which doesn't let me run the script?

1
  • Does your script have the executable bit set? What is the output of ls -la /usr/bin/myscript.sh?
    – derHugo
    Dec 11, 2017 at 17:46

1 Answer 1

9

Your script isn't set as executable; just like a script not installed by packaging, you need to make sure it has the executable bit set.

You have two options:

  1. When creating the package, make sure that your script has the executable bit set before creating the package, by running this in your work directory Before building the package:

    chmod +x /path/to/script.sh

OR...

  1. Use the postinst script for your package to set the executable bit after installation. Add a command to the .postinst script similar to the following:

    chmod +x /usr/bin/myscript.sh

For some of my things, I use both methods just to make sure it sets things as executable. That introduces headaches sometimes, but it's better to make sure than not make sure. At least, in my opinion.


As for the script not being able to be executed as myscript, that's because myscript and myscript.sh are different objects.

If you want that, do the following in your .postinst script for your package:

ln -s /usr/bin/myscript.sh /usr/bin/myscript

... and then assuming you fix the executable bit problem, it should then 'just work' for both of the versions you were trying, both myscript.sh and myscript.

HOWEVER the proper way to do this is, instead, to just package the script as myscript and not include the shell extension. You should then include a shebang line at the beginning (#!) indicating the interpreter to use. Since .sh could be anything. Then, set up the package to just install myscript. As muru stated, you should avoid making links in your postinst, but it's up to you what you want to do. There's many different ways to achieve your goal, but not really much strict guidance in the documentation for packaging.

3
  • Is it this postinst or .postinst? Dec 11, 2017 at 21:46
  • @GeorgeUdosen A plain postinst if the source package only creates one binary package, or <packagename>.postinst if multiple binary packages are created.
    – muru
    Dec 12, 2017 at 1:25
  • 1
    None of these should be done in the postinst, IMO. File permissions and links should be part of the package, unless they cannot be (for example, if the link is to somewhere in /usr/local, or part of the alternatives system). Otherwise you have to take care in your postrm to remove the links.
    – muru
    Dec 12, 2017 at 1:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .