SlickEdit Community
SlickEdit Product Discussion => SlickEdit® => Topic started by: rowbearto on July 13, 2022, 04:24:52 PM
-
I often like to ssh into a different machine manually from the "Build" tool window and then run the "Build" command in SlickEdit.
This worked fine in previous releases.
But now in 26.0.3.1 when I try to do this I get an error:
/home/rbresali/pen/slickedit/se_26000301_linux64/bin/vsbuild -signal vsbuild_done -commandfile "/tmp/slk.486800.20220713162217087.-6.cmf"
/home/rbresali/pen/slickedit/se_26000301_linux64/bin/vsbuild -signal vsbuild_done -commandfile "/tmp/slk.486800.20220713162217087.-6.cmf"
ERROR: Could not open arg file '/tmp/slk.486800.20220713162217087.-6.cmf'
As I have sshed somewhere else then vsbuild is running on a different machine then SlickEdit. That machine has a different /tmp directory, so SlickEdit is not able to find it.
I would really like to be able to get this ability back.
-
Ah, it's referencing a local arguments file. I may need to put in a configuration option so you can disable it for this case. I'll look and see what I can do.
-
Patrick:
This issue is still there in beta2. Any way I can get this functionality back?
-
In beta 3, you'll be able to set "def_allow_vsbuild_use_commandfile" to 0 and get back the old behavior where it isn't referencing a commandfile on the local filesystem.
-
Thanks Patrick.
What is this new feature with def_allow_vsbuild_use_commandfile set to non-zero?
Why not have the old behavior as the default and the new behavior be non-default?
-
The var just controls whether some arguments to vsbuild are passed inside of a file rather than on the command line to vsbuild.
It's on by default because it fixes some obscure problems with different build shells and expansions/quoting. I don't think anyone anticipated that vsbuild commands would be running on a remote machine, so it was enabled by default with no way to revert to the old behavior. If you didn't have problems before, turning this off gets the old behavior that will work with the remote vsbuild.
-
Couldn't you fix the issues by passing on the command line to vsbuild? Seems like when I build remotely I would also have the same obscure problems that you fixed? By figuring out how to pass to command line with vsbuild then you solve the issue for both remote and local builds. Now if you have 2 solutions your fixes won't carry over to the remote case which could be unmaintained and stop working over time.
Not sure nobody anticipated that vsbuild commands can run on a remote machine, I've been doing this for years and it only stopped working in 26.0.3 - it worked fine in 26.0.2 and for all releases before it. I even have this issue about an aspect of it, see: https://community.slickedit.com/index.php/topic,18611.msg74869.html#msg74869
-
What about having vs_exe do escaping that vsbuild interprets? Then you can work with any shell. You control the code on both sides - vs_exe and vsbuild, so you could have complete control over how to escape things. Then you can make sure that vsbuild runs with all the proper parameters that are supposed to have space, quotes, etc.
For example with url encoding spaces are converted to %20. Couldn't you use a urlencode() to send the command line parameters to vsbuild? Then you could continue to send the parameters over the command line. If urlencode() doesn't work you could possibly reuse some other available encoding/decoding scheme?
-
In beta3 I tried adding:
def_allow_vsbuild_use_commandfile = 0;
into my Slick-C file for my settings.
When loading my .e file I get error:
Identifier 'def_allow_vsbuild_use_commandfile ' not declared.
I found it in 'compile.e', but even after I add "import compile.e" I still get this error.
-
That's odd. I can set it in a macro, or in a defmain {} script when compile.e is imported.
I can do either of these:
def_allow_vsbuild_use_commandfile=1;
set_var('def_allow_vsbuild_use_commandfile 0');
Does it work if you do the set-var version?
Does it make any difference if you load the "compile.e" from the SlickEdit install directory, and then re-load your macro file and re-run your setup? (I wouldn't expect it to unless another version of compile.e was loaded, so this is a paranoia check).
-
The set-var version loads and executes properly.
I tried loading 'compile.e' from SlickEdit directory, but macro still won't load if I do:
#import "compile.e"
...
def_allow_vsbuild_use_commandfile = 0;
Not sure if this makes a difference but I set that variable inside a command function:
_command void initialSeConfig() name_info(','VSARG2_READ_ONLY)
{
Look for robutils_20220923.e on support and try to load it. This is the .e file where I get this error.
-
I can't reproduce it with that file. I've gone through different scenarios, with clean configs, and existing v27 configs, and upgrades from v26. No luck.
If you run v27 with -sc /tmp/CleanConfig, can you load the file then? It seems like it's should be something related to upgrading, but if you get it with a clean config, then I'm on the wrong track.
-
I'm also getting the error with a clean config.
-
Not what I was expecting. Could you go to the build window when it is not connected to a remote machine, and run "printenv" and get the output? Might be best to upload it to support rather than post it, since it will have a lot of system information.
-
In beta3 I tried adding:
def_allow_vsbuild_use_commandfile = 0;
into my Slick-C file for my settings.
When loading my .e file I get error:
Identifier 'def_allow_vsbuild_use_commandfile ' not declared.
I found it in 'compile.e', but even after I add "import compile.e" I still get this error.
Make sure when loading/compiling your macro that SlickEdit isn't finding the wrong compile.e. I've been burned by this since I have copies of macros all over the place.
-
I have attached my macros/compile.e file. I have loaded it multiple times and then tried loading my macro, but I still get the error.
Do I have the correct compile.e file?
I also tried erasing the vslick.sta file when slick was closed and restarted, still couldn't compile my macro file.
-
Try putting your macro in the same directory as this correct compile.e and load it from there. This compile.e does look fine and compiles (matches v27 beta3 version).
-
When I put my macro in the same directory as compile.e, then my macro loads without error.
But with my macro in a different directory, my original one, I get the error.
-
SlickEdit macros references MANY macros. For example, compile.e references many other macros (#imports, #includes). The wrong version of a macro is being found. I have no idea which one. I suspect the directory which has your macro may have other macros in it which are the wrong version. It only takes one wrong/problematic macro.
-
Clark: Thanks for that pointer. Yes looks like there was another 'compile.e' in the same directory as my macro. It was dated Dec 15, 2021. I don't remember how it got there - I suspect for some past issue someone on SlickTeam provided me this compile.e with some fix and I completely forgot it was there.
After removing this compile.e in same directory as my macro I'm now able to load my macro without this error.
Thanks!