fix: Skip hidden directories when creating commands

[GuySartorelli]

The Issue

DDEV thinks hidden directories in ~/.ddev/commands/ hold commands for services with names that start with a .

This can result in commands like this showing up:

Note that the composer.lock, composer.json, and config.yml files all live in a hidden directory.

(For reference, .php-utils/ here contains code and dependencies that my global host commands share - see https://github.com/GuySartorelli/my-ddev-commands if you're curious)

How This PR Solves The Issue

Skips hidden directories, so that files in those directories are not treated like commands.

Manual Testing Instructions

Add a hidden directory in ~/.ddev/commands/ with some files in it and run ddev - before the PR they will show up in the commands list, but afterwards they shouldn't.

Automated Testing Overview

Tests that a command in a hidden directory doesn't show in the commands list

Related Issue Link(s)

N/A

Release/Deployment Notes

In the very unlikely scenario where someone does actually have a service where the name of the services starts with a ., they will no longer be able to add global commands for it. That strikes me as exceedingly unlikely though.

[github-actions]

Download the artifacts for this pull request:

• all-ddev-executables.zip
• ddev-linux-amd64.zip
• ddev-linux-arm64.zip
• ddev-macos-amd64.zip
• ddev-macos-arm64.zip
• ddev-windows-amd64-installer.zip

See Testing a PR.

• Test on Gitpod.
• Test on GitHub Codespaces.

[GuySartorelli]

If this is at all controversial I can live with moving my directory .phputils directory into commands/host/.phputils instead since that will be ignored - but this seems like something someone else will eventually run into as well so I figured I'd offer up this solution first.

[rfay]

So you use directories named .something in your ~/.ddev/commands directory? What are they for?

I think it's totally reasonable to skip hidden directories, but interested in how you ended up here.

[GuySartorelli]

So you use directories named .something in your ~/.ddev/commands directory? What are they for?

It's right in the PR description. :p

(For reference, .php-utils/ here contains code and dependencies that my global host commands share - see https://github.com/GuySartorelli/my-ddev-commands if you're curious)

[rfay]

It would be nice to come up with a standardized way for commands to share libraries. We got stuck on this with the launch refactoring.

[GuySartorelli]

I don't think we did get stuck - I mentioned an approach in that PR but the implementors decided to go with a different approach.
xhprof and xdebug for example have a function which is defined elsewhere. For any bash commands provided by DDEV we can do the same thing to provide any manner of utility scripts that can be shared across commands.

For custom commands outside the DDEV codebase that obviously won't be as helpful - maybe it's worth opening an issue about that.

In any case the scope of this PR is intentionally very narrow to fix what I perceive to be a bug with how hidden directories in the ~/.ddev/commands/ directory are treated.

[stasadev]

Tested, it looks good to me 👍

[rfay]

Thanks for this! There's only one problem that I see... changing the code for exactly one dev's workflow :) But that one person is a valued contributor, so thanks! And thanks for checking the test coverage while you were there.

[GuySartorelli]

changing the code for exactly one dev's workflow

One developer's workflow today ;p Fixing small issues like this can reduce friction for others to do similar things if they want to.