1.23.0 Change to tryGetHome Breaks for tcsh

[emajekral]

Hi,

I supervise labs for several hundred students who must use tcsh (chsh is disabled, sysadmin's choice not mine) and who I have directed to sshfs as a primary tool for remote file editing on our servers. The latest version, 1.23.0, changes the method to get home folders to:

echo "::sshfs:home:$(echo ~)\n"

which fails because $() does not exist in tcsh. As a result, my students are unable to connect when using 1.23.0 unless they set '-CHECK_HOME', which is a bit much to ask from some of my beginners. The test you used in 1.22.0 works for us, so I've instructed my students to revert to that version for now. However, the following appears to work for both tcsh and bash on my systems:

echo "::sshfs:home:`echo ~`"

and it requires no changes to the regex match() you are using. More testing is required of course, but since you are not nesting backticks, I think the two are roughly equivalent. Note though, that I had to remove the terminal \n from the outermost echo.

Alex.

[telecasterer]

I have the same issue on servers where we are enforced to use csh. I can confirm that the proposal above to use backticks would work for us too. In the meantime I'm reverting to 1.22.0.

Paul

[dylan-robins]

Same issue here, the servers we work on have a similar chsh situation and users are required to use csh/tcsh. The proposed solution should also work for us, in the meantime I'll also revert to 1.22.0 and direct others to do the same.

Dylan

[huginandmunin]

Thank you for the advice on reverting to 1.22.0.

I've had the same issue for connecting to a csh user on Solaris. Reverting to 1.22.0 is working.

George

[SchoofsKelvin]

Note though, that I had to remove the terminal \n from the outermost echo.
@emajekral

Why's that? I've installed tcsh and both my original echo (but using backticks) and echo "a\nb" both seem to work fine?

---

The latest build should fix this, although some quick testing shows it doesn't support REMOTE_COMMANDS (#267) or environment variables (the environment JSON key) yet. Doubtful any of you are using this though as it would've already lead to issues in previous versions. Swapping

Planning on releasing a patch version for this later tonight, i.e. max 5 hours from now. Seeing if I can by then set up shell detection and add more feature support.

[emajekral]

Note though, that I had to remove the terminal \n from the outermost echo.
@emajekral

Why's that? I've installed tcsh and both my original echo (but using backticks) and echo "a\nb" both seem to work fine?

It appears that having \n inside the "" causes the problem. I can't tell for sure, but the escaped endline seems to be coming back and messing things up in VS Code. So, for me, this:
echo "::sshfs:home:`echo ~`"\n
and this:
echo "::sshfs:home:`echo ~`"
Both produce a result that looks like the following. The regex match executes properly, I can see the returned string in o, and both terminate with \n.

However, for some reason this:
echo "::sshfs:home:`echo ~`\n"
does not allow me to break on the regex match. Instead, I end up in the exception handler with the name of the SSHFS configuration I'm trying to use stuck inside o, which is supposed to be the result of the ssh-exec call and contain my home folder.

This only occurs for me when using tcsh, not when using bash or csh, here's a comparison on my student server. I confirmed on a Vanilla WSL Ubuntu on my personal computer as well.

(Sorry about using
prettified extension code here... I'm kind of new to this stuff.)

[SchoofsKelvin]

@emajekral Did you try the .vsix from here? You can drag-and-drop it into the Extensions pane or use the Extensions: Install from VSIX... command. Make sure to reload the window to make sure VS Code loads the new version.

[emajekral]

Looks good! I see the new echo "::sshfs:home:`echo ~`: and matching regex and they work with both my tcsh and bash shells.
Thanks for the quick response. :)

[SchoofsKelvin]

Fix is released in v1.23.1 of the extension. VS Code should auto-update, but mind that you'll probably have to reload the window afterwards before it actually starts using the new version. The Extensions view should display a "Reload Required" button if that's the case, otherwise it should say v1.23.1 (or higher) for this extension.