scripts should be executable

[GitMensch]

@fesch Can you please do the following on the make branch?
git update-index --chmod=+x makeBigJar makeJar makeStructorizer startStructorizerAgain structorizer.sh Arranger.sh

Additional question: I want to not run but only compile/create the jar files, should I add a -start option to provide the recent behavior or a -nostart / -no-start option to suppress it?

[codemanyak]

@GitMensch
Bob did the commit 9041bbd on the master branch, so you will have to pull it to the make branch.
No idea whether the commit had a sustainable effect (can't test this on a Windows machine), but the 100 $ question is whether the executable flag will survive the next merge with the bugfix branch where I contributed changes to some make files relating to the bean shell update (discussed in #594).
ADDED:
Albeit, command git update-index suggests that the mode flags are held with the "folder" (more correctly the register) rather than with the file itself, so it might have a chance.

[GitMensch]

I've merged fesch/master to GitMensch/master via GitHub, that obviously did not work, the result is identical (you can even see the failing CI-build here ;-)

Build started
git clone -q --branch=master https://github.com/GitMensch/Structorizer.Desktop.git /home/appveyor/projects/structorizer-desktop
git checkout -qf 760ce009983e448787ef3ff8bebc793de01ad214
Running "build_script" scripts
./makeStructorizer
./makeBigJar
bash: ./makeStructorizer: Permission denied
bash: ./makeBigJar: Permission denied
Command exited with code 126
Build failed

But inspecting the git history of fesch/master doesn't show the index update (neither here nor in git cmd), I'm unsure if the index was updated with the executable bit and committed.

In the meanwhile @fesch:

Additional question: I want to not run but only compile/create the jar files, should I add a -start option to provide the recent behavior or a -nostart / -no-start option to suppress it?

[fesch]

@GitMensch I have no idea what -start nor what -nostart does or is :-/

[GitMensch]

@fesch

The current behavior of all makeXYZ scripts is to start the application after it was built. I want to add a command line option to these and would prefer to start -start, effectively changing the current behavior (because those scripts are called "make", not "start").
If you request I'll keep the current behavior adding a -nostart (or -nostart or -makeonly) option to suppress the start.

[fesch]

I don't use any of these scripts, so you are free to change them so that they fit your needs.

[GitMensch]

Just rechecked: the scripts (at least the make* ones) are still not executable.

Can anyone try again, possibly after merging #803, to set the executable bit?
git update-index --chmod=+x makeBigJar makeJar makeStructorizer startStructorizerAgain structorizer.sh Arranger.sh then push the change?

[codemanyak]

@GitMensch
Well, I suppose you have successfully achieved this in another GitHub project. Otherwise I would have may doubts that it is feasible at all considering the circumstance that the UNIX mode flags are some OS-specific thing. Contributing from a Windows platform where there are no executible bits, I wonder what would happen on a pull.
Perhaps it makes more sense to provide the suited shell command (chmod) in the README.md file, such that an adopter may simply copy and execute it after having downloaded or cloned the sources?

[GitMensch]

The VCS client is responsible for the flags - it cares for eol-style "native/lf/crlf" and also for the executable bit and other related meta data like "ignore" rules.
Parts that are not relevant (like the executable bit on a "normal" Windows machine) are just skipped. The executable bit is often only "checked" on the initial check-out.

This is true for svn and git and likely a bunch of other VCS clients, it is just important that the metadata is set on the server repo.

I don't think the README is a good place - the tar-file will already be correct (the auto-generated only if the metadata says it so) and a developer doing a checkout on a non-windows machine will likely know how to handle this. For "developer convenience" (both checkout and the auto-generated tar) it still would be nice to have the metadata correct.