WSL: hana-cli hdi --cf false --> **/bin/sh: 1: Syntax error: Unterminated quoted string**

[draschke]

I did the same request with PowerShell ans WSL. PS works fine, but WSL gives me an error. /bin/sh: 1: Syntax error: Unterminated quoted string

But I do have one more question.
Is there a filter for only hana instances with hdi-shared plans? I miss hana services with securestore and sbss plans in the result.

Latest hana-cli version available on npmjs.com: 2.202106.1
**PS**
PS C:\git\Secure-Store-with-NodeJS> hana-cli hdi --cf false
name                                                      last_operation   
--------------------------------------------------------  -----------------
DIRASCHK-16tb4r1uvw6vpwms-capm-capm-db-hdi-container      create succeeded
dr-hdi-shared                                             create succeeded

**WSL**
Latest hana-cli version available on npmjs.com: 2.202106.1
diraschk@vmn-it-ful-05:/mnt/c/git/Secure-Store-with-NodeJS$ hana-cli hdi --cf false
Error: Command failed: xs curl "/v2/service_instances/?q=space_guid:f74450b6-af3a-4c90-9d1a-da3b30e4dd49%3Bservice_plan_guid:6126d8a3-949%3Bservice_plan_guid:6126d8a3-9ebf-4c70-ab30-e9626b40b1ca&results-per-page=5000
**/bin/sh: 1: Syntax error: Unterminated quoted string**

[jung-thomas]

In wsl you have the xs command line installed? This command branches out the xs command.

As far as filtering - yes this command only returns hdi-shared plans. That's why the command is called "hdi" - it only returns HDI container instances. securestore and sbss wouldn't be HDI.

[draschke]

In wsl you have the xs command line installed? This command branches out the xs command.

yes, I'm able to connect via xs with the hana system using WSL.

As far as filtering - yes this command only returns hdi-shared plans. That's why the command is called "hdi" - it only returns HDI container instances. securestore and sbss wouldn't be HDI.

Is there a way to get the other plans by using hana-cli?

[jung-thomas]

I just pushed a new version to npm. It fixes the issue on WSL (which oddly enough was just a missing closing quote on the URL generation). I also added new commands that will lookup service plans filtered by sbss, securestore and schema (named schemaInstances because we already have a schema/schemas command that looks at the DB catalog directly).

[draschke]

Ok, everything works fine. Thank you for the fast fix and the new features!

[draschke]

hi Thomas,

maybe you have an idea to throw a different error message, while using the wrong npm version.

This command hana-cli hdi --cf false (connecting an XSA platform by using xs-cli) leads with the wrong npm version (in my case v15.5.0) to this error msg.
--> Connection Problems: Error: CF configuration missing. Please use cf login first

With v14.17.3 every works fine.

(I'm asking because I had this issue more times in the past and it took me some time until I realized the reason of the issue)

[jung-thomas]

You only get a message back that says wrong npm version? That's interesting. Does the please use cf login first message come next? You were able to install hana-cli on node 15? Or did you install hana-cli and then upgrade the node version? Because the engines section should be checked during installation and restriction to node 12 and 14.

[draschke]

You only get a message back that says wrong npm version?

I would like to see this message "you use the wrong npm version", instead of Connection Problems: Error: CF configuration missing. Please use cf login first

My nvm is default 15.5.0 and I always forget to change it to the right version 12 or 14.

Now I changed the nvm default version and it won't happen so fast for me again, but I guess there are other users would have the same problem.

nvm alias default lts/fermium
default -> lts/fermium (-> v14.17.3)

[jung-thomas]

So you are changing the node version after install. OK - I can probably put a version check on any command startup and report back the error right away.

[draschke]

You were able to install hana-cli on node 15? Or did you install hana-cli and then upgrade the node version?
I installed and upgraded it with the required version 14. The check during the installation works

The problem exists only because I used a wrong npm after the installation.

[jung-thomas]

I added a version check to the startup of the entire hana-cli. It will output as a warning on every command if your node engine version doesn't match what is specified in the package.json.

[draschke]

thanks for the solution, the installation works fine (for both powershell and wsl)

But I think the issue is more complex by using WSL as I thought, because the check compares with the locally installed npm by Powershell which is valid (14.8.0) although I use nvm with the npm version 15.5.0.
The validation for the required npms won't work in my case. It seems to be okay, but its not, because I use 15.5.0.
So I get the same error msg as before. ("Connection Problems: Error: CF configuration missing. Please use cf login first")

But I guess we can stop here, because I think we wouldn't get this issue on a real linux system.

you can see the two npm versions on the left and on the right side.

[jung-thomas]

I'm not sure I entirely understand your setup here; but it's rather fascinating. Are you connecting via remote explorer in VSCode to a WSL instance? And that's where you are running hana-cli? Yet somehow you are getting the node.js version from the host OS instead of the remote WSL instance? From the terminal where you are running hana-cli what do you get when just issue a node -v?

I have a similar setup using WSL - I use nvm in both the host OS and the WSL instance. In VSCode and the command line in the host OS it reports version 14.17.0 correctly. The hana-cli and the node -v command both agree on that version:

If I connect to WSL within the terminal, the VSCode extension in the command line still shows the host OS version of 14.17.0, but now node -v reports the WSL version of 14.17.1. And so does hana-cli. So that all works as expected:

Finally if I use remote explorer in VSCode to connect to WSL, now the VSCode extension also reports 14.17.1 - the WSL version and node -v and hana-cli both still agree as well.

So I've not been able to replicate the situation you describe.

[draschke]

Thanks for your detailed explanation! Its really weird and I didn't get this fixed.
I reinstalled on my host OS (Windows 10) node.js, but still the same behaviour.

Are you connecting via remote explorer in VSCode to a WSL instance? And that's where you are running hana-cli?

I tried both remote WSL and not remote WSL, but it doesn't make any difference. (screenshot)

Yet somehow you are getting the node.js version from the host OS instead of the remote WSL instance?

I don't know.

From the terminal where you are running hana-cli what do you get when just issue a node -v?

Remote WSL

Not Remote WSL

For the moment I don't have a clue what I did wrong. But it helps me a lot to know that here is something wrong!

[draschke]

Because of this strange behavior, I came across VS Code Docker Remote Containers and was wondering if there is already a sample development container from your team that contains the environment with a hana-cli (cf-cli or xs-cli) and all required things.
I think such a container would be very convenient for our users moving from WebIDE to VSC for on-premise hana development.

Remote development in Containers

[jung-thomas]

Actually I just added a development container configuration to this project last night: https://github.com/SAP-samples/hana-developer-cli-tool-example/blob/main/CHANGELOG.md#changed

It creates a development container with all the supporting tools (like the cf command line, @sap/cds-dk, etc) that you would need to develop further functionality in the hana-cli itself. It doesn't install the hana-cli because that's the project it pulls in by default to work on. But you can just do a npm install and then npm link and run it from the sources within the development container as well. It also allows you to setup and develop or use the project within Codespaces.

But back to your original problem - when you run the hana-cli version command notice you aren't receiving the Node.js version in the output. Towards the end of the output of the command in my environment (or in the Codespaces screenshot above as well), it lists the Node.js version that hana-cli is seeing. I'm just using process.version in that instance.

But most importantly what I notice is that it is showing an old version of the hana-cli itself. In your screenshots, it's reporting 2.202104.04. That's a few months old. The current version on npm is 2.202107.5.

[draschke]

Actually I just added a development container configuration to this project last night

Unbelievable, I swear I didn't see it before in your project. This is absolutely awesome! :)
Will check for it later, but need to go now... :(

[draschke]

But most importantly what I notice is that it is showing an old version of the hana-cli itself.

thank you, I wasn't aware of it before. This could also be a reason why I am not getting the new warning you added a few days ago (because there is no node validation check).

I think I did a wrong hana-cli installation. :(
I guess I installed it on Windows and not WSL because I couldn't install npm in WSL (** Error: npm: / bin / sh ^ M: bad interpreter: No such file or directory **)

I did not critically question the wrong hana-cli installation under Windows because the valid node version for hana-cli worked for me. But of course that was stupid.

But I'm still wondering why Remote WSL runs the node version 14.7.3. from my OS host.

Now I need to fix the npm issue.
https://stackoverflow.com/questions/39311147/cannot-run-npm-commands
microsoft/WSL#4249

[jung-thomas]

Well first keep in mind when using nvm, that when you switch node versions that the node_modules folder storing your global modules is within each particular version. If you are using nvm and switching back and forth between versions, the most recent installation of any global modules does not copy over when you switch. This has bitten me before as well. I'll switch versions only to find I'm suddenly using an older version of @sap/cds-dk or some other global utility like hana-cli.

On WSL I wonder if that's the inherited environment path from the host OS. Perhaps it doesn't find the module in the expected location in the guest OS but then just starts looking through the PATH for it. It won't find it in the path of the guest OS but if it also searches the locations in the PATH of the HOST Windows OS and runs it from there. But that would mean that it's not only finding node_modules folder from the host OS but also running the Node.js runtime itself from the host OS. But I'd be a little surprised if that worked on the Node.js runtime itself since that should be platform specific. So in the end; not exactly sure what's happened there in the WSL situation.