Naming conventions and consistency

[Izzur]

First off, I really like ble.sh – it's a nice project!

As I've been getting more familiar with it, I notice something regarding naming conventions
My experience with many CLI tools is that they often maintain a consistent name across different aspects. For example, a tool named foobar might typically have:

• Repository: githubcom/foobar/foobar
• Config directory: ~/.config/foobar
• RC file: ~/.foobarrc
• Commands/subcommands: foobar-debug or foobar/debug

With ble.sh, I've noticed a few variations from this pattern:

• Repository: /ble.sh (ends with .sh)
• Config directory: ~/.config/blesh (no dot sh)
• RC file: ~/.blerc (no sh)
• Debug command: $ ble/debug (no sh)

I was wondering if there's a specific rationale behind these different naming. These slight differences can make it a tad less intuitive to guess paths or commands when first starting out.
Would love to hear any thoughts

Thanks for this great tool!

[akinomyoga]

I was wondering if there's a specific rationale behind these different naming.

No.

It's just for historical reasons. I also recognize the inconsistency and thought about it for some time when determining the package name, but I currently don't think there is a good reason to change the name of the project just for such a small consistency. There are many tools with similar inconsistencies, but I don't think they must change the project names altogether.

ble.sh technically started with the name "ble". However, "ble" is too short as a specific name. I named the GitHub repository with the suffix .sh with the emphasis on the fact that it is written in a shell script (unlike ZLE from Zsh). At the time, there was an existing case with a similar repository name, acme.sh. The situation with the package name is similar. Initially, I hadn't assumed that people would request a package just for a shell configuration. When determining the package name, "ble" seems too short again, and it is not so memorable, too. A problem with "ble.sh" is that some package systems may not allow a special character . inside the package's name. Then, to avoid a situation where the package name is ble.sh in some package managers, ble-sh in some others, and blesh in the others, I decided to normalize the package names to be blesh. The directory structures for the packaged version follow the package name.