Am 01.05.2018 um 00:23 schrieb Joel Sherrill: > > > On Mon, Apr 30, 2018 at 3:18 AM, Christian Mauderer <l...@c-mauderer.de > <mailto:l...@c-mauderer.de>> wrote: > > Am 29.04.2018 um 23:08 schrieb Joel Sherrill: > > > > > > On Sun, Apr 29, 2018, 3:32 PM Christian Mauderer <l...@c-mauderer.de > <mailto:l...@c-mauderer.de> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>> wrote: > > > > Am 28.04.2018 um 21:45 schrieb Gedare Bloom: > > > On Thu, Apr 26, 2018 at 7:52 PM, Joel Sherrill <j...@rtems.org > <mailto:j...@rtems.org> > > <mailto:j...@rtems.org <mailto:j...@rtems.org>>> wrote: > > >> Hi > > >> > > >> Teaching the class this week, i have noticed that randomly some > > >> files are executable. I was going to change this but then > realized > > >> that we should all agree on what the permissions on the files and > > >> directories in the tree(s) should be. > > >> > > >> I lean to either: > > >> > > >> + 664 for files and 775 for directories > > >> > > >> But could be talked into tighter permissions for group and world. > > >> Whatever we do, it should be consistent and added to the Coding > > >> Conventions. > > >> > > > > > > Your proposal is sensible to me. > > > > Hello Joel, > > > > I wouldn't really have a problem with these. But I think the more > usual > > ones would be 644 and 755. > > > > If I create a new file using `touch somefile` in a directory with > 775, I > > still get a 644 file (at least on my Linux machine - I'm not sure > > whether it is configuration dependant). I think that we will get a > lot > > of patches with "wrong" permissions if we use 664 and 775. So maybe > it > > would be good to have some reasons for using these wider group > > permissions. > > > > > > The command you are thinking of is umask to set your default file > > permissions. > > > > I knew I have seen a setting sometimes. You are right: I have though of > umask. I only don't need it often enough to remember ;-) > > > > > The only setup that I could think of where such rights might could > be > > useful is one where one user updates the code while some other user > (for > > example a build bot) has to run a bootstrap to build the tree. But > I'm > > quite sure that even for that case, there are some better solutions > > (e.g. one working tree that only pushes to a build bot tree). > > > > > > If all commits go through a git or patch tester server, i would assume > > that we are getting the permissions set by the patch submitter. > > > > I suspect (no investigation) that we could have a git check that ensures > > specific permissions based on the file extension. > > > > That would be great. > > > Should we file that as an admin "wish list" item? >
I think in the long run, that would be something like the linux checkpatch.pl script that checks whether the coding style matches the ones that we accept: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/checkpatch.pl?h=v4.17-rc3 But I don't think that anyone has the time to do it. So really a long term project. Beneath that even if we already have a coding style recommendation such a script would for sure start the discussion about THE RIGHT CODING STYLE which is quite a matter of faith and therefore a really annoying discussion (and please let's not start it here and now). > > > > > Any special reasons, use cases or experiences where the 664 and 775 > > would be superior to 644 and 755? > > > > > > No. I just remember historically using those on real multi-user devel > > machines so everyone on a team could share source. > > > > I think we all agree it should be standardized. That's a good step. > > > > I will look at git, GNU recommendations and a few packages to see what > > they do. Then make a proposal which might include ways to try to keep > > this standardized. > > > > Maybe it's already decided by git: > > I did a quick test: I initialized an empty repository (called test) and > created the following files there: > > -rw-r--r-- 1 christian users 0 30. Apr 10:05 644 > -rw-rw-r-- 1 christian users 0 30. Apr 10:05 664 > -rw-rw-rw- 1 christian users 0 30. Apr 10:05 666 > -rwxr-xr-x 1 christian users 0 30. Apr 10:04 755 > -rwxrwxr-x 1 christian users 0 30. Apr 10:05 775 > -rwxrwxrwx 1 christian users 0 30. Apr 10:05 777 > > Then I did a `git add .` and commited it. If I clone that repository > with `git clone test test2` my test2 folder contains the following > files: > > -rw-r--r-- 1 christian users 0 30. Apr 10:07 644 > -rw-r--r-- 1 christian users 0 30. Apr 10:07 664 > -rw-r--r-- 1 christian users 0 30. Apr 10:07 666 > -rwxr-xr-x 1 christian users 0 30. Apr 10:07 755 > -rwxr-xr-x 1 christian users 0 30. Apr 10:07 775 > -rwxr-xr-x 1 christian users 0 30. Apr 10:07 777 > > If I re-set the permissions, that is not shown as a change. Only the > executable bit seems to be saved. All other permissions are not saved in > my test setup. > > > The reading I have done indicates that only the executable bit is > managed by git. The rest are from your umask (I thin). Great. So it's no difference whether we use 664 or 644. > > find . -type f -executable | grep -v .git | grep -v configure > > Turns up a number of source files which are executable. given that git > tracks that, I fixed those. That leaves these as executable. The worst > I see on this list is some that are likely obsolete. Do you see anything > else? > > /compile > ./cpukit/doxy-filter > ./cpukit/sapi/vc-key.sh > ./depcomp > ./install-sh > ./mdate-sh > ./missing > ./testsuites/fstests/fsdosfsname01/create_image.sh > ./testsuites/smptests/smplock01/smplock01fair.py > ./testsuites/smptests/smplock01/smplock01perf.py > ./testsuites/sptests/sptimecounter02/sptimecounter02.py > ./tools/build/cvsignore-add.sh > ./tools/build/doxy-filter > ./tools/build/multigen > ./tools/build/rtems-test-check > ./tools/build/rtems-test-check-py > ./tools/build/rtems-testsuite-autostuff > ./ampolish3 > ./bootstrap > ./bsps/nios2/nios2_iss/nios2_iss.sh > ./config.guess > ./config.sub > ./rtems-bsps > The find on my computer found a ./bsps/arm/shared/start/start.S which shouldn't be executable too. Otherwise I would be OK with that. Best regards Christian > > > > Best regards > > Christian > > > > > Best regards > > > > Christian Mauderer > > > > > > > >> Thoughts > > >> > > >> _______________________________________________ > > >> devel mailing list > > >> devel@rtems.org <mailto:devel@rtems.org> > <mailto:devel@rtems.org <mailto:devel@rtems.org>> > > >> http://lists.rtems.org/mailman/listinfo/devel > <http://lists.rtems.org/mailman/listinfo/devel> > > > _______________________________________________ > > > devel mailing list > > > devel@rtems.org <mailto:devel@rtems.org> > <mailto:devel@rtems.org <mailto:devel@rtems.org>> > > > http://lists.rtems.org/mailman/listinfo/devel > <http://lists.rtems.org/mailman/listinfo/devel> > > > > > > > _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
