Repository navigation
Some lang names guessed by bblfsh has a different driver name #162
Description
Activity
In enry/linguist there is just
Shell, notBash. Everything else are just aliases forShell.
The problem here is that our driver manifest asserts it supports "bash", but that is not a language that enry can output.The Bash driver should work with any valid Bash subset, it would even support most code for Zsh, which is not a subset but it's pretty similar. That covers most shells and most shell code. However, I think it will never support csh/tcsh syntax.
Whatever solution you pick, I think it's safe to assume that the Bash driver is everything we'll need for shell language in the foreseeable future.
We spoke some time ago about supporting more language aliases in the manifest to cover drivers supporting more languages (like Python2/3, TypeScript/Javascript, etc). But while we do that I'm ok with renaming to Shell if we agree.
Reacted by Denys SmirnovWill do.
The name of the drivers are the name of a language,
shellis not a language name, so we should keep the name of 'bash', what we can do... if worth it, is identify bash in Enry, but this is not a bblfsh issueOpened a separate issue to decide what to do with the Bash/Shell case: bblfsh/bash-driver#39
When sending to bblfsh a code with a filename
whatever.sh, it is tried to be parsed withshelldriver, but this driver should be identified asbash; when it happens, the request fails because bblfsh is not able to routeshellrequests tobashdriver.As suggested by @juanjux (via Slack), it could be interesting to have language aliases defined in the driver's manifest and then bblfshd could read and route those names to the proper driver.