file mode changes

[Cohen-Carlisle]

add bin/* files to enable-executable and executable-status-check
generator now makes test files executable
make enable-executable chmod consistent with current file modes

[kotp]

Looks good. Waiting on Travis.

[Cohen-Carlisle]

Methods can't go to 11!
I can fix that.
I also noticed that the enable-executable and executable-status-check don't work if you are cd-ed into bin.
I'll throw that fix in as well.

[kotp]

You shouldn't need to change folders into any other folder in order to use the tools.

In fact you should be able to add that (the bin folder) to your path and run them from anywhere. Though normally, I suppose, it would be the project root.

You don't change directory to work on the exercise files, (do you?) you shouldn't need to run the bin files.

[Cohen-Carlisle]

Its not that you need to cd to use them, its that if you do, you can't!
I'm usually at project root, but it threw me for a loop when I cd-ed into bin while experimenting with file modes because I got tired of typing ll bin/* and wanted to just type ll.

[Cohen-Carlisle]

@kotp, are you against having enable-executable and executable-status-check use pathing from the current file in their Dir.globs? It does kinda seem like overkill, but on the other hand... if someone cds into bin it saves them some confusion.

[kotp]

Why the expanded privileges here? 744 should be fine, and technically more permissive even than necessary.

[Cohen-Carlisle]

These are the permissions of current executables, so I updated the chmod for consistency.

[Cohen-Carlisle]

Actually, putting bin on your path is kinda scary! Because Dir.glob is relative to pwd, that can change file permissions on a whole lotta stuff (if for example, used from home).

[kotp]

I guess I just don't change into folders, to have noticed it. I set the permissions to be minimally permissive, and even 744 is maybe more than is needed.

Realize that the git hooks are using (some of) these files too. (see bin/setup-git-hooks) That script should maybe be re-written as well to add content, not strictly overwrite the pre-push hook. That is a different issue though.

[Cohen-Carlisle]

Just pushed my latest changes up. Let me know what you think.

[kotp]

Current view on that branch looks like:

total 64
-rwxrwxr-x 1 george curious 342 Apr 11 22:37 enable-executable
-rwxrwxr-x 1 george curious 349 Apr 11 22:37 executable-tests-check
-rwxr--r-- 1 george curious 640 Apr  4 14:53 fetch-configlet
-rwxr--r-- 1 george curious 140 Apr 11 01:06 generate-clock
-rwxr--r-- 1 george curious 186 Apr  4 14:53 generate-difference-of-squares
-rwxr--r-- 1 george curious 155 Aug 16  2015 generate-gigasecond
-rwxr--r-- 1 george curious 146 Aug 16  2015 generate-hamming
-rwxr--r-- 1 george curious 157 Apr 11 00:59 generate-hello-world
-rwxr--r-- 1 george curious 189 Apr 11 00:59 generate-largest-series-product
-rwxr--r-- 1 george curious 137 Apr 11 00:59 generate-leap
-rwxr--r-- 1 george curious 146 Apr 10 23:17 generate-pangram
-rwxr--r-- 1 george curious 150 Apr 11 00:59 generate-raindrops
-rwxr--r-- 1 george curious 175 Apr  4 14:53 generate-rna-transcription
-rwxr--r-- 1 george curious 166 Apr 11 00:59 generate-roman-numerals
-rwxr--r-- 1 george curious 407 Apr  4 14:53 local-status-check
-rwxr--r-- 1 george curious 114 Aug 16  2015 setup-git-hoooks

Your changes introduce another level of access that may not be necessary. Compare to the rest of the files permissions. Yours are 775, while the rest are 744.

[Cohen-Carlisle]

A fresh clone of master has this for me:

-rwxrwxr-x 1 cohen cohen 224 Apr 11 22:50 enable-executable
-rwxrwxr-x 1 cohen cohen 246 Apr 11 22:50 executable-tests-check
-rwxrwxr-x 1 cohen cohen 640 Apr 11 22:50 fetch-configlet
-rwxrwxr-x 1 cohen cohen 186 Apr 11 22:50 generate-difference-of-squares
-rwxrwxr-x 1 cohen cohen 155 Apr 11 22:50 generate-gigasecond
-rwxrwxr-x 1 cohen cohen 146 Apr 11 22:50 generate-hamming
-rwxrwxr-x 1 cohen cohen 157 Apr 11 22:50 generate-hello-world
-rwxrwxr-x 1 cohen cohen 189 Apr 11 22:50 generate-largest-series-product
-rwxrwxr-x 1 cohen cohen 137 Apr 11 22:50 generate-leap
-rwxrwxr-x 1 cohen cohen 146 Apr 11 22:50 generate-pangram
-rwxrwxr-x 1 cohen cohen 150 Apr 11 22:50 generate-raindrops
-rwxrwxr-x 1 cohen cohen 175 Apr 11 22:50 generate-rna-transcription
-rwxrwxr-x 1 cohen cohen 166 Apr 11 22:50 generate-roman-numerals
-rwxrwxr-x 1 cohen cohen 407 Apr 11 22:50 local-status-check
-rwxrwxr-x 1 cohen cohen 114 Apr 11 22:50 setup-git-hoooks

[kotp]

But that wasn't coming from the prior version. I just checked against what it was handling, which is the test files...

I get this:

-rwxr--r-- 1 george curious 3062 Apr 11 19:45 exercises/clock/clock_test.rb

for example, which is to say 744.

[Cohen-Carlisle]

It appears there is some git magic afoot. I'll update to using FileUtils.chmod('+x', file).

[Cohen-Carlisle]

Should be all squared away now. /knocks on wood

[kotp]

Is this available in all languages? We should leave the file executable bit to the helper tool in bin. It is outside the concern of the generator.

[kytrinyx]

When you say all languages do you mean on all platforms?

[Cohen-Carlisle]

I gather that this will either be a no-op or will work on Windows, depending on who you ask. The docs don't really say either way. But it definitely shouldn't blow up.

@kotp I'm curious as to why you think we shouldn't change the file mode here?

My argument for changing it here is that it will relieve contributors from the burden of having to remember to run another script or chmod it themselves. People will predictably forget to chmod the file and we will have to tell them to update it. Or, people might manually change the file mode in weird ways. This standardizes the file mode automatically.

[kotp]

Yes, yes, I do. Specifically, does this exclude Windows.

[kotp]

@Cohen-Carlisle, the enable executable tool does the same thing though, correct? And it is specific to its responsibility.

[Cohen-Carlisle]

The nice thing about this is that you will often generate the file a few times while working iteratively toward a solution. This makes it so that you don't even have to worry about the file mode each time you generate the test file.

[kotp]

I understand and can see that it would be a convenience.

If this is to be changed, I would think it should be a different pull request.

If the current pull request would need to be reverted for any reason, it would not effect pulling this change, which I consider to be unrelated.

[kotp]

I think the generator file doesn't belong in this commit? Seems out of place, and I think it naturally leaves if we leave executable bit functionality to the tools to address that.

[Cohen-Carlisle]

@kotp With regards to if the generator should change the filemode, see my comments on the diff. Perhaps we could tag @kytrinyx for an opinion?

[kytrinyx]

I'd rather not have the generator change the file mode, as it seems like a completely unrelated change.

The whole "make the tests executable" is a weird edge case that we threw in to make someone happy. I personally do not see the value of it, but it doesn't seem to hurt to have it. That said, at some point I'm going to write an article about all the ways you can run the tests quickly or automatically (rerun, guard, vim keybindings, etc, etc), at which point I'd like to rip out the #!s and the stuff where muck with the execution bit, because at that point we can just point to the article and suggest that these are all good ways to do it.

If we stick it in the generators, now we'll have to rip it out of 60 different places.

Does that make sense?

[petertseng]

Regarding the test cases being executable or not:

I'm sorry to butt in here because I may be making a statement that is based on an incomplete understanding of all the issues at hand here, but I would note that despite https://github.com/exercism/xruby/blob/master/exercises/hello-world/hello_world_test.rb currently being executable (See "Executable file" written on the page), exercism fetch ruby hello-world does not make it executable.

In cli the file is always written non-executable by fetch due to https://github.com/exercism/cli/blob/master/user/item.go#L71 . We also briefly discussed in exercism/cli#276 (note that the issue proper discusses download not fetch but the decision covered fetch as well).

Basicaly I'm saying, if desiring to make the test files executable, some work will have to be done in CLI.

Of course whether the file is executable will affect those who clone the repo directly instead of going through exercism fetch (Anyone who works on a PR or contributes to this repo). So still worth thinking about. But for what I suspect is a vast majority of students, they will always see non-executable

[kotp]

Yes, the client code not being executable is understood. Thanks @petertseng, reminded me about that. I am not sure we would or should make clients files executable in general, without good reason. Plus it is one more learning point. How do you automate your tests. I use rerun gem often, or guard when it is a full project. But my editor is my test launcher otherwise.

The generator is only one file, and effects those (hopefully soon to be) sixty, but is only one file to change later. Honestly, the benefit is while the generated test is being created. It is a limited convenience.

However, the generator change should not be in this PR.

[kytrinyx]

Basicaly I'm saying, if desiring to make the test files executable, some work will have to be done in CLI.

I forgot about that. We did that on purpose.

The generator is only one file

Oh, right. I wasn't thinking.

the benefit is while the generated test is being created

OK, now I really don't understand. Why does it help to make the test file executable when generating it?

[kotp]

That is more feedback that I have been told, rather than what my experience has been, not sure if they are using automated tools to run on change, or just not using the command line history to get the line ruby exercise/something_test.rb. It is probably more of a "someone is working harder than they need to be" kind of thing.

So probably too much weight in regards to the benefit being during creation. Though that would be the time when it is likely to be ran in quick succession through the iterations.