launcher script appends -1 to every project created

if [ "${n}" -gt 0 ]; then
  NAME=${NAME}-$((n + 1))
fi

This looks correct, but I see one issue: if I run the script again by mistake, it will create a new project each time instead of starting the current project. It keeps appending a numeric suffix to the name each time it runs.

With @stasadev's suggestion, I see another issue. If we try to install it inside inner directories of any DDEV project, it will not work as expected. This is because `ddev describe` will return the project from the parent directory instead of the current directory. So, a more reliable approach could be:

# Check if a DDEV project exists in the current directory only
if [ ! -f .ddev/config.yaml ]; then
  NAME=$(basename $PWD)
  # If there is any other DDEV project with the same name, add a numeric suffix
  if ddev describe "${NAME}" >/dev/null 2>&1; then
    NAME="${NAME}-1"
  fi
  # Configure a new project
  ddev config --project-type=drupal11 --docroot=web --php-version=8.3 --ddev-version-constraint=">=1.24.0" --project-name="$NAME"
fi

> With @stasadev's suggestion, I see another issue. If we try to install it inside inner directories of any DDEV project, it will not work as expected. This is because `ddev describe` will return the project from the parent directory instead of the current directory.

I am not sure if this is the right approach to create a DDEV project inside another DDEV project.

By the way, in the next release of DDEV, it will not be possible to configure a DDEV project inside another DDEV project using the command line (`.ddev/config.yaml` still can be created manually) https://github.com/ddev/ddev/pull/6852

Thanks, @stasadev, for highlighting the upcoming change in DDEV!

You're absolutely right—it’s not an ideal approach to create a DDEV project inside another DDEV project. However, since it was allowed previously, I considered that scenario.

I updated my code in the issue summary, which should better handle the edge cases described.

I just tested as follows:

1. I already had these installed: drupal-cms-dev and quant-drupal-cms-1
2. Installed using composer create-project drupal/cms with the old script
3. It created cms-3 which makes sense based on the old logic
4. Installed again using the new script and it created cms which makes sense because it's using an exact name match
5. Installed again and it created cms-1
6. Installed again and it created cms-2
7. Installed again and it created cms-4
8. I deleted cms-2 and installed again and it created cms-2 as expected

So, the logic works, but I'm not sure if the code looks okay.

Actually... this needs work because, when I use a different directory name, then it doesn't work:

macbookpro:testing_drupal_cms kristenpol$ ./launch-drupal-cms.sh
Creating a new DDEV project config in the current directory (.../Sites/quant/another_cms/testing_drupal_cms) 
Once completed, your configuration will be written to .../Sites/quant/another_cms/testing_drupal_cms/.ddev/config.yaml
 
Configuring a 'drupal11' project named 'testing_drupal_cms' with docroot 'web' at '.../Sites/quant/another_cms/testing_drupal_cms/web'.
For full details use 'ddev describe'. 
failed to validate config: testing_drupal_cms is not a valid project name. Please enter a project name in your configuration that will allow for a valid hostname. See https://en.wikipedia.org/wiki/Hostname#Syntax for valid hostname requirements 

We should be able to use a different name.

> when I use a different directory name, then it doesn't work

Thanks, should be fine now.

Changes:
- check for underscores and spaces in the directory name
- early check for DDEV v1.24.0 before doing any action
- remove fragile code that depended on `jq` and `docker`
- replace infinite "while" loop with "for 1 to 1000"

I do have a question here that is a bit meta. Why are we using a complex launcher script that requires all this maintenance, when we can do the exact same thing with `ddev composer create` as with the suggested `composer create-project`? The DDEV-recommended technique in https://ddev.readthedocs.io/en/stable/users/quickstart/#drupal-drupal-cms is to do the `ddev composer create` and it's very easy. I'm baffled why we need a launcher script and a zipball. Or perhaps if we want a launcher script, why doesn't it just do the `ddev composer create` ?

I'm happy to open another issue, but this one could be put aside if we just went with simpler instructions.

The changes look okay but there are some out-of-scope things that should be done in other issues.

@rfay's point is also a good one - we have to find the right balance between making this easy for people and driving ourselves nuts. Given the way things look on new.drupal.org -- where the DDEV instructions are linked to on a separate page -- the value of the launcher script is looking very dubious indeed. This is a product decision, though, and therefore needs to be run by @pameeela.

So, assigning to her and postponing any further action until we've decided if this launcher script is worth it to us.

I'm inclined to agree now that there is dedicated Drupal CMS documentation for DDEV. The existence of this launcher script is (I think) also causing some folks to think that DDEV is the only way to install from the zip.

So probably we need to create a new issue to remove the launcher script in the next release, and coordinate all necessary updates to documentation. As part of this, we should also make it clear that DDEV is a suggestion and not a requirement.

And then we can close this as won't fix.

The launcher was removed in #3501605: Replace the launcher script with better documentation, so this is not gonna get fixed. :)