How can I ensure that binaries installed by my install script are executable?

I've just created my first github repository: https://github.com/WinEunuuchs2Unix/eyesome

I've uploaded all the files but have concerns with how the end-user will copy them after download.

Here is the copy-files script (abridged) they would run:

copy-files

!/bin/sh

if [ $(id -u) != 0 ]; then # root powers needed to call this script
echo >&2 $0 must be called with sudo powers
exit 1
fi

cp -v ./eyesome.sh /usr/local/bin/
cp -v ./eyesome-cfg.sh /usr/local/bin/
cp -v ./eyesome-src.sh /usr/local/bin/
cp -v ./eyesome-sun.sh /usr/local/bin/
cp -v ./wake-eyesome.sh /usr/local/bin/
cp -v ./start-eyesome /etc/cron.d/
cp -v ./daily-eyesome-sun /etc/cron.daily/
cp -v ./systemd-wake-eyesome /lib/systemd/system-sleep/

exit 0


My first thought is after someone downloads the files none are marked as executable?

The copy-files script has a section for "uninstalling" that is inactive. Is this a common courtesy to provide?

copy-files

Comments on further reading to improve my github and refine my copy-files code are also appreciated.

github

copy-files

2 Answers
2

You say: "My first thought is after someone downloads the files none are marked as executable?" git allows you to mark the files executable and preserve permissions. Before doing git commit -a -m 'Some changes';git push just run chmod +x on the files.

git

git commit -a -m 'Some changes';git push

chmod +x

Currently all your files are in top level of directory. This looks kinda messy and disorganized. It's best to have directories and organize things. If you look at professional organizations, they have doc/, scr/ directories, or at least project's top level module name directory with submodules inside.

doc/

scr/

When user downloads zip file and extracts everything, what will they see ? Tons of files scatered all over the directory where they extracted it. So having directories in your project helps to minimize the clutter.

Some repositories I have do follow same thing - everything is in top level. But I don't change that because I already have instructions written in my Ask Ubuntu answers, so going back and trying to figure out what answers to change is too problematic.

Have an installation script. Instead of writing too many instructions to the user, this one thing can save time for them and you.

Figure out how to use develop and master branches. You can keep a working version in master and work on changes in develop. That way users have working code, and you're not freaking out about code being broken and users unhappy.

develop

master

master

develop

Your README.md is bare. Add some useful information. Particularly, outline things that are necessary as dependencies for the project, specifically commands not installed on default Ubuntu system ( which is what your projects generally tend to aim at).

README.md

install

copy-files

.deb

.deb

Instead of using cp, take a look at install, e.g.

cp

install

install ./eyesome.sh /usr/local/bin/


By default, it will use mode 755, but you can override that with the -m option if you need something different.

-m

The next logical step would probably be to build a proper package for the operating system(s) you're targeting.

install

install

copy-files

install.sh

Thanks for contributing an answer to Stack Overflow!

But avoid …

To learn more, see our tips on writing great answers.

Required, but never shown

Required, but never shown

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy