You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After some painful debugging with a student, I just wanted to draw attention to a potential race condition(?) which is causing the error in the title.
As part of an introductory programming task, the student had placed a command to execute a MOTD-like C binary in their .bashrc whenever it gets sourced to generate some coloured ASCII art into stdout.
Since the issue immediately goes away upon removing this command and reappears when putting it back in, I reckon the output from the echo Home: ~ is being corrupted with the ASCII art.
Fixed in 860f65a and released in v1.23.0 of the extension. If your student installed it from the marketplace, it should auto-update, or at least give you a quick "Update to 1.23.0" button in the extensions tab.
Instead of expecting the output to be of the exact format Home: <path>, it now echoes ::sshfs:home:<path>\n which it'll look for, no longer being affected by whether .bashrc (or similar) echoes anything before/after the "magic pattern".
After some painful debugging with a student, I just wanted to draw attention to a potential race condition(?) which is causing the error in the title.
As part of an introductory programming task, the student had placed a command to execute a MOTD-like C binary in their
.bashrc
whenever it gets sourced to generate some coloured ASCII art intostdout
.Since the issue immediately goes away upon removing this command and reappears when putting it back in, I reckon the output from the
echo Home: ~
is being corrupted with the ASCII art.vscode-sshfs/src/connection.ts
Line 25 in 3527259
I don't know if there's an elegant fix for it other than to save output to a file in
/tmp
and reading from it but that should be a good start.The text was updated successfully, but these errors were encountered: