Re: [Savannah-hackers-public] requirements of a new project in GNU Savannah

[Karl Berry]

    1. Files with whitespaces

I think what you do (report them and abort) is fine.  The message makes
it clear that file names containing whitespace aren't a stopper for
acceptance, just a practical recommendation.

    2. compiled binary files

Ok, I guess.

    3. long text files without recognizable copyright
    4. long text files without recognizable license

Looking at the output from coreutils and grep: you should add regexps to
find those "all-permissive" licenses.  Some of them probably also failed
because they omitted the (C).

Ultimately, a nice goal would be for coreutils, grep, and other active
(and very carefully maintained) packages to run without warnings.  But
it's very useful as it stands.

    5. plain-text license file

You could also grep everything at the top-level for some snippet from
the GPL, which might find a few more cases.

    6. binary data files (e.g. png/jpg)

Perhaps it would not be so hard for the script to check if a README
somewhere in the project contains those file names.

    7. misuse of the term 'linux'

Good, and please also check for "open source", as I wrote you separately.

     https://savannah.gnu.org/register/requirements.php
     http://savannah.gnu.org/maintenance/HowToGetYourProjectApprovedQuickly

Seems like both urls should be https, or both http.  I see other http
urls in the script ...

Anyway, in addition to everything else you're doing, can you start
drafting some changes for the wiki, both related to the script and the
other stuff we've talked about?

Thanks much,
Karl

P.S. Aside on random coding style:

- personally, I'd find the script easier to follow if all the functions
related to a given test were together (and separated by ^L's for Emacs),
instead of putting all the filter functions first, then the find
functions, then the check fns, etc.

- It might also be clearer if the main execution path was in a function
main(), and the script only calls main at the top level.  It's always a
question, especially in shell scripts, where executable stuff is
happening :).

- could just be me, but I find code much more readable when the
operator in a continued expression is at the start of a line instead of
the end.  (I think the coding standards even mention this, for C.) 
As in:
  echo "$FILES" | filter_text_files | find_term_linux \
      && check_warn_term_linux
instead of
  echo "$FILES" | filter_text_files | find_term_linux &&
      check_warn_term_linux

Likewise,
  foo \
  | bar
instead of
  foo |
  bar

Sure, it's an extra backslash instead of "cleverly" taking advantage of
shell syntax, but whether the code is doing && or || or | or whatever is
of crucial importance, and IMHO better not relegated to the end of an
often-long line.

FWIW ...