Sysprogs forums › Forums › VisualGDB › Custom Shortcuts – how to run conditional command
- This topic has 3 replies, 2 voices, and was last updated 4 years, 5 months ago by support.
-
AuthorPosts
-
June 18, 2020 at 18:10 #28456wilstarkParticipant
VisualGDB version 5.5 preview 7, build 3666. I have a CMake integration project. VS 2017.
I’d like to create a symlink on my target machine as part of a custom shortcut. It appears that the command must return success, or later attempted runs of the shortcut (which has copy commands in it as well) stop working altogether (I find I have to reload the VisualGDB project in my solution to recover this situation). So I need to make the ln command conditional, otherwise it will return failure if the link already exists. So my first attempt with “Command” set to ln and “Arguments” set to the ln arguments works but only if the link does not already exist.
Next I try to use conditional shell logic, basically:
if[ ! -e mylink ]; then ln -s linktarget mylink; fi
The Command and Arguments to try to make this work are like this:
bash
and
-c 'if [ ! -e mylink ]; then ln -s linktarget mylink; fi'
The above ‘bash -c’ command works as expected if run from an interactive shell. However, the custom shortcut output is:
Executing Run "bash -c 'if [ ! -e /tmp/libpalio.so ]; then ln -s /usr/lib/libpalio.so.5.2 /tmp/libpalio.so; fi'" in directory "/tmp" on TargetMachine (alias)... LIBSSH2 returned LIBSSH2_ERROR_SOCKET_SEND Failed executing custom shortcut. See the log above for more details.
or it prints this, if I have freshly (re)loaded the project:
Executing Run "bash -c 'if [ ! -e /tmp/libpalio.so ]; then ln -s /usr/lib/libpalio.so.5.2 /tmp/libpalio.so; fi'" in directory "/tmp" on TargetMachine (alias)... The custom shortcut was executed successfully. See the log above for more details.
Any suggestions for how to achieve the creation of this link in a custom shortcut would be appreciated.
- This topic was modified 4 years, 5 months ago by wilstark.
June 19, 2020 at 03:53 #28461supportKeymasterHi,
This actually looks like a bug in the SSH server (LIBSSH2_ERROR_SOCKET_SEND means that the server has unexpectedly closed the connection), so simply updating the SSH server might solve this.
It may not trigger when running commands manually due to the differences between interactive SSH mode (used by regular terminal software) and the command mode (used by VisualGDB) and you might be able to trigger it manually by running “ssh user@host <command>”.
Either way, we can also add a special custom action to upload and run a temporary script instead of just a single command line. If this works, please confirm that creating a script manually, setting chmod +x on it and running it via Custom Shortcuts) works. If it does, we can add support for uploading and running temporary scripts from the VisualGDB GUI (it will include substitution of variables like $(TargetPath) in the script contents).
June 19, 2020 at 07:45 #28462wilstarkParticipantsshd is pretty recent.
root@ff:/tmp# sshd –version
OpenSSH_7.9p1, OpenSSL 1.1.1g 21 Apr 2020I was able to run:
$ ssh root@ff “ln -s /usr/lib/mytargetname.so.1.2 /tmp/mylinkname.so”
successfully from a MINGW64 bash shell against the target machine. So… sshd seems OK with ssh command mode. Not sure why VisualGDB’s ssh client cannot do the same?
I can verify that an executable shell script /tmp/test can be run with a shortcut
Command: /tmp/test
Directory: /tmp
and it successfully runs the script that creates the link.
Thanks.
June 21, 2020 at 23:34 #28469supportKeymasterThanks for confirming this. We have added support for running temporary scripts as custom actions to the following build: VisualGDB-5.5.7.3688.msi
You can create the script actions as shown below:
Edit: the differences between running the command with VisualGDB vs. manually could be caused by either the extra environment VisualGDB specifies (you can find it out via View->Other Windows->VisualGDB Diagnostics Console) or by the fact that VisualGDB runs multiple commands within the same SSH session, while the command-line SSH command reconnects each time you start it. Either way, the new script action should work around it regardless.
Attachments:
You must be logged in to view attached files. -
AuthorPosts
- You must be logged in to reply to this topic.