Custom Shortcuts – how to run conditional command

Sysprogs forums Forums VisualGDB Custom Shortcuts – how to run conditional command

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
    Posts
  • #28456
    wilstark
    Participant

    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.
    #28461
    support
    Keymaster

    Hi,

    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).

    #28462
    wilstark
    Participant

    sshd is pretty recent.

    root@ff:/tmp# sshd –version
    OpenSSH_7.9p1, OpenSSL 1.1.1g 21 Apr 2020

    I 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.

    #28469
    support
    Keymaster

    Thanks 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.
Viewing 4 posts - 1 through 4 (of 4 total)
  • You must be logged in to reply to this topic.