not all directory names are valid project names

[urbanjost]

Currently the "new" subcommand is given a name that is also suitable as a module name and a project name. Should that be the case? More and more systems support Unicode names for directories and so on. As a simple example if you enter
something like

fpm new 1
fpm new project.1

you can see the problem

[everythingfunctional]

This is one of many things I didn't consider to be necessary to deal with in the prototype, but we should absolutely tackle in the Fortran version. There are essentially 2 ways to handle this specific problem:

1. Reject names that are not valid Fortran identifiers and issue an error message to the user without doing anything
2. For anywhere that the name appears as an identifier in the code, convert invalid symbols to _, but still need to reject the name and issue an error message if the first character is not an ASCII letter

I would prefer option 1 as it is more concise and simple, but if there is sufficient support for 2 I think it would be acceptable.

[urbanjost]

I happen to have an example for the VERIFY(3f) intrinsic

program demo_verify
implicit none
character(len=64)  :: line
integer            :: ios
   do
      read(*,'(a)',iostat=ios) line
      if(ios.ne.0) exit
      if( fortran_name(line) )then
         write(*,*)trim(line),' passed'
      else
         write(*,*)trim(line),' failed'
      endif
   enddo
contains
function fortran_name(line) result (lout)
! determine if a string is a valid Fortran name ignoring trailing spaces (but not leading spaces)
character(len=*),parameter   :: int='0123456789'
character(len=*),parameter   :: lower='abcdefghijklmnopqrstuvwxyz'
character(len=*),parameter   :: upper='ABCDEFGHIJKLMNOPQRSTUVWXYZ'
character(len=*),parameter   :: allowed=upper//lower//int//'_'
character(len=*),intent(in)  :: line
character(len=:),allocatable :: name
logical                      :: lout
   name=trim(line)
   if(len(name).ne.0)then
      lout = .true.                                  &
       & .and. verify(name(1:1), lower//upper) == 0  &
       & .and. verify(name,allowed) == 0             &
       & .and. len(name) <= 63
   else
      lout = .false.
   endif
end function fortran_name
end program demo_verify

That I could put in put in fpm_strings.f90 if the preference is 1) , Not sure why I have the redundant ".true." in there, but I would take that out.

[LKedward]

I would support method 1) as the way to handle this problem.

There is actually already a fortran name validation function buried in fpm_sources.f90:

fpm/fpm/src/fpm_sources.f90

Lines 405 to 439 in 90ddc6f

	function validate_name(name) result(valid)
	character(*), intent(in) :: name
	logical :: valid
	integer :: i
	if (len_trim(name) < 1) then
	valid = .false.
	return
	end if
	if (lower(name(1:1)) < 'a' .or. &
	lower(name(1:1)) > 'z') then
	valid = .false.
	return
	end if
	do i=1,len(name)
	if (.not.( &
	(name(i:i) >= '0' .and. name(i:i) <= '9').or. &
	(lower(name(i:i)) >= 'a' .and. lower(name(i:i)) <= 'z').or. &
	name(i:i) == '_') ) then
	valid = .false.
	return
	end if
	end do
	valid = .true.
	return
	end function validate_name

Though this implementation is not as elegant as yours @urbanjost, so would support replacing it with yours if/when you put it in fpm_strings.f90.

[certik]

I would reject names that are not valid Fortran program names.

Later, we can relax this restriction in various ways if there is demand.

[urbanjost]

IThanks; but right now I want to change as few files as possible until things catch up. I was just going to put your routine into the strings library as it is actually likely faster and mine was just a demo I made for someone to show them how VERIFY could be used, which is not intuitively obvious to a lot of peope, apparently. So I just used mine directly in the fpm_command_line.f90 file for now If the NEW PR gets accepted I will move one to the fpm_strings.f90 so we can both use it if no one beats me to it, but I would like to see master updated first and then that can just be a simple stand-alone PR that should be easily reviewable/merged. I have too many little changes in NEW already, I think. Hoping this is acceptable and can be merged. Please review and let me know what needs changed!