More file extensions than just "*.sh"?

[nwinkler]

It would be great if the user could provide more file extensions to parse. At the moment, only *.sh files are found and parsed:

https://github.com/mads-hartmann/bash-language-server/blob/00941c001ca342c8a9c1b647b2a1b7ea703e5fc6/server/src/analyser.ts#L47

When working with Bash scripts that use a different extension, e.g. .bash, the bash language server currently does not work.

It would be great if there was a configuration option that would allow to list the extensions that should be scanned...

[mads-hartmann]

@nwinkler This is a great idea. I'd be more than happy to merge a PR adding this feature 👍

[nwinkler]

It's been a while since I've done any Node.js/TypeScript, and I've never worked on an extension for VSCode, but that shouldn't stop me...

[nwinkler]

Found the developer guide - I'll take a look at that and see how far I can get. More time in the day would be nice...

[mads-hartmann]

@nwinkler Awesome 👏 Let me know if you have any questions

[Lucretia]

I also use .inc for include files. I'm not the only person who does this.

[bunam]

add .command on mac ?

i think a better solution is to look in the 1st line for began by '#!' and containing 'bash' 'sh' ... ? #!/usr/bin/env bash

[maximbaz]

Or rely on mime type, as that one already respects shebang and all possible file extensions:

❯ file --mime-type $(readlink -m ~/bin/backup)
text/x-shellscript

Example with readlink may not be cross-platform, I just wanted to point out that symlinks need to be correctly handled.

[skovhus]

Good point with the symlinks @maximbaz

Any PRs would be much appreciated.

[skovhus]

So we have two use cases:

1. files without .sh extensions that are bash scripts
2. file with .sh extensions that are not bash scripts

Suggested solution: Read the shebang line for all potential shell script files (.sh, .command, .inc, and no file extension).

As a nice to have on top, we should make the glob pattern configurable.

[przepompownia]

@skovhus after merging the current master into your branch I looked if and how it works (see #156 ).

The essence of your change is that you make an intersection of having shebang and matching the glob pattern. It is not what I expect. I would like to use an alternative of these to determine the type. In such case we probably need to scan rootPath twice: first against the custom glob pattern, then against shebang, with another (less restricted) glob pattern.

[skovhus]

I’m more than open to another implementation. As you might have noticed my other PR was stale and just work in progress. Are you for creating a new PR?

[skovhus]

When working with Bash scripts that use a different extension, e.g. .bash, the bash language server currently does not work.

Sorry for the confusion here. This is actually not true, although it looks like this based on the glob.

Clients (such as VS Code) will call the LSP when a bash file is opened (they detect this using shebangs or mime types I assume). The glob is only used to preload all .sh files.

[skovhus]

Currently we just preload .sh files, but I'm actually not sure we use that for anything besides caching. We don't need to read all the files in a project and handle shebangs–unless we want to do jump-to-definition across files (which required a lot of work).

Isn't this correct @mads-hartmann? :)

[przepompownia]

unless we want to do just-to-definition across files (which required a lot of work).

I have lots of scripts with calling to functions defined somewhere outside and cannot simply jump to these definitions using bash-language-server.

[mads-hartmann]

A quick clarification: Jump to definition across files already works ☺️ But it only works for the files that we've processed. Right now we process a file when:

• The server is loaded. It scans for all files ending in .sh
• When you open/edit a file with the Shell Script language mode enabled.

I think we have at least two different improvements we could make:

1. Allow the user to configure an array of glob patterns that we use when scanning. This would also allow people to use patterns outside of the VSCode workspace.

2. Extend the default glob pattern to include more files - we'd probably need to guard against files that turn out to not be bash file if we pick a very permissive glob.

[przepompownia]

I use bash-language-server with vim. Probably it no matters in such case.

Right, editing single file with filetype sh invokes using the server.

I could rename my own scripts to sh extension to access its definitions from outside but sometimes I need to use definitions from files belongs to public projects like initramfs-tools.

There is lots of cases when I would like to manually add paths to scan at my own risk.

[przepompownia]

Is it possible that the file is analyzed but I still cannot access definitions from it?

[skovhus]

We have just released [email protected] (the LSP server) that:

• Extends file glob used for pre-analyzing files from **/*.sh to **/*@(.sh|.inc|.bash|.command)
• Makes file glob configurable with GLOB_PATTERN environment variable

I'll release a version of the Bash IDE VS Code extension soonish.

@przepompownia can you try out the new version in vim?

[skovhus]

VS Code extension 1.5.0 has just been released.

Everyone, thanks for all the input here. 👏

@bunam @Lucretia @nwinkler let me know if it resolves the issue for you.

[przepompownia]

I see that glob pattern works after setting it by environment variable. I can jump to definitions in analyzed files but the same definitions are not present in completion list. Items from the current file are suggested only. Probably it is not an issue related to this change.

Thanks for this step :+1:

[skovhus]

I can jump to analyzed files but the same definitions are not present in completion list. Items from the current file are suggested only. Probably it is not an issue related to this change.

Thanks for reporting this. Can you create a new issue with this? A screenshot or some small reproducible example would be great.

[przepompownia]

No problem. Unfortunately, I also noticed that files located at the top of root path are analyzed only.

[przepompownia]

Probably you can faster check whether searching files to analyzing is recursive.

[skovhus]

I also noticed that files located at the top of root path are analyzed only.

I cannot reproduce that. Console output when running the LSP on this repository:

Analyzing files matching glob "**/*@(.sh|.inc|.bash|.command)" inside /Users/kenneth/git/bash-language-server
Glob resolved with 16 files after 7.549 seconds
Analyzing file:///Users/kenneth/git/bash-language-server/node_modules/cssstyle/scripts/run_tests.sh
Analyzing file:///Users/kenneth/git/bash-language-server/node_modules/exit/test/fixtures/create-files.sh
Analyzing file:///Users/kenneth/git/bash-language-server/node_modules/watch/release.sh
Analyzing file:///Users/kenneth/git/bash-language-server/scripts/release-client.sh
Analyzing file:///Users/kenneth/git/bash-language-server/scripts/release-server.sh
Analyzing file:///Users/kenneth/git/bash-language-server/server/node_modules/cssstyle/scripts/run_tests.sh
Analyzing file:///Users/kenneth/git/bash-language-server/testing/fixtures/extension.inc
Analyzing file:///Users/kenneth/git/bash-language-server/testing/fixtures/install.sh
Analyzing file:///Users/kenneth/git/bash-language-server/testing/fixtures/issue101.sh
Analyzing file:///Users/kenneth/git/bash-language-server/testing/fixtures/missing-node.sh
Analyzing file:///Users/kenneth/git/bash-language-server/testing/fixtures/not-a-shell-script.sh
Analyzing file:///Users/kenneth/git/bash-language-server/testing/fixtures/not-a-shell-script2.sh
Analyzing file:///Users/kenneth/git/bash-language-server/testing/fixtures/parse-problems.sh
Analyzing file:///Users/kenneth/git/bash-language-server/testing/fixtures/sourcing.sh
Analyzing file:///Users/kenneth/git/bash-language-server/testing/fixtures/subfolder/test.sh
Analyzing file:///Users/kenneth/git/bash-language-server/vscode-client/node_modules/vscode-languageclient/lib/utils/terminateProcess.sh
Analyzer finished after 7.623 seconds

It would be nice if you also could create an issue with how to reproduce it.

[przepompownia]

Try to analyze file without sh extension, within subdirectory.

[skovhus]

Try to analyze file without sh extension, within subdirectory.

We do not analyze files without sh extensions yet in version 1.5.0.

[przepompownia]

My mistake - I need glob pattern **, but used *.

[przepompownia]

I can jump to analyzed files but the same definitions are not present in completion list. Items from the current file are suggested only. Probably it is not an issue related to this change.

Thanks for reporting this. Can you create a new issue with this? A screenshot or some small reproducible example would be great. #190

[skovhus]

The initial shebang detection is now implemented and released:

• [email protected]
• vs code [email protected]

What is missing:

1. vs code might still ask us to analyze a non-bash file (example not-a-shell-script2.sh with a python shebang). Although we skip the initial parsing of the file, we still redirect diagnostics (e.g. "failed to parse")... This should be fixed.
2. The only case we currently do not handle is bash files without any file extensions. In order to do so, we could load all files without any file extension and detect their mimetype/shebang. This is a fairly small change.