Error in running the command $ dse gremlin-console -i test.groovy - groovy

I came in to a situation in which I have to run a bash script lets say testbash.sh has the following lines:
#!/bin/bash
dse gremlin-console -i test.groovy
test.groovy file contains:
:remote config alias g cord.g
schema.describe()
The output of bash script testbash.sh is below
Error in /home/nithin/test.groovy at [2: schema.describe()] - No such property: schema for class: groovysh_evaluate.
Any clue will be greatly appreciated.

I can't seem to recreate your problem (at least on the latest version of 5.1.x). To troubleshoot, I think that you should first start dse gremlin-console without the -i and paste the commands from the script into the console and make sure that they return properly. If you get the same error, then you know that you can start looking into the problem from there without worrying about -i at all. Is cord.g initialized with a graph for a schema to be present?
If the commands work fine, then there must be something wrong with the console bootstrap that initializes it to work with the server on startup. The bootstrap script should be present in your DSE installation and is called dse-init.groovy. I would try pasting you commands into the bottom of that script and seeing if that solves your problem. If it does, then perhaps you have an older version of DSE because I do recall some changes in recent months for -i and -e handling that perhaps are related. I think that editing dse-init.groovy could be a reasonable workaround for you if you aren't able to upgrade for some reason.

Related

Command not found in WSL2 even though it's on the path

I'm having an issue with WSL2:
$ where b4a
/usr/local/bin/b4a
$ b4a new
/usr/local/bin/b4a: 1: Not: not found
Even though where finds commands, I can't run them. And it's not a PATH issue either:
echo $PATH
/usr/local/sbin:/usr/local/bin:[...]
And b4a isn't the only command with this problem. What could be the cause? My distribution is Debian 10 and host is Windows 10.
Not necessarily a full answer, but hopefully the troubleshooting methods you need to arrive at a solution ...
Note that it doesn't say that the command itself isn't found. For instance, if you run:
# lllllllllll
lllllllllll: command not found
That's truly a command not found. This is different. While I don't (yet) know the exact cause, this seems closer to the issues we might see with improperly quoted paths with spaces in a shell script.
You mention that other commands have this problem -- Is there something in common with the commands that don't work properly? Is it possible that they are all shell scripts?
Try several things to debug:
Start WSL without your startup profile. It's very likely that something (or you) added a line that is causing problems. From PowerShell or CMD:
wsl ~ -e bash --noprofile --norc
b4a
If that works, then there's a problem in one of your startup files that you'll need to debug. Look for anything modifying environment variables without proper quoting, especially the PATH. WSL automatically appends the Windows path to your Linux path to make it easy to run Windows commands, but the fact that almost every Windows path has spaces in it can cause problems for unsuspecting scripters that don't take this corner case into account.
Having a space in a path is fully allowed in Linux, but some scripts just don't handle it properly.
If the command that is failing is a shell script, trying starting it with:
bash -x /usr/local/bin/b4a
Or even start WSL with wsl ~ -e bash -x to see all trace output from the shell.
In this case, you'll be looking for some problem in the script right around where it actually fails.
If all else fails, you can disable WSL's PATH modification via its config file:
sudo -e /etc/wsl.conf
Add the following:
[interop]
appendWindowsPath = false
Then exit Debian, run wsl --shutdown and restart Debian. Try the b4a command again.
If this works, then the problem is almost certainly due to some problem in the PATH quoting in these commands. I don't recommend it as a permanent solution since you will have to type out the full path of Windows applications each time you want to run them.

Unable to execute shell script using deploy command in jboss

I have been looking for solutions to this problem for a couple of days and have not found a suitable one.
Currently i have two lines of code in my shell script file.
cd /app/jboss/sample_project/bin
./jboss-cli.sh -c --controller=$hostnameVal:$jboss_port_no1 --user=$jboss_id --password=$jboss_pwd --command="deploy --force /sample/uploaded/sample-1.0.war --runtime-name=sample-1.0.war"
I am facing this error:
'--force' is assumed to be a command(s) but the commands to execute have been specified by another argument: [deploy]
I think it has something to do with the spaces between deploy and --force but I can't seem to find a solution to this. Would really appreciate if someone can shed some light. Thank you!
The root cause of the issue was due to the space between the deploy command and the file path, therefore jboss was not be able to find the parameter the properly.
Hence, a work around for this which I have found out is to create a cli file, write the deploy command in the cli file and pass the file as an input in the script that i am writing.
Do you observe the same problem in a terminal?

Cassandra Nodetool can't find NodeCmd from Git Bash

I'm running Cassandra 2.0.9 with Java 1.7.0 on Windows. I can run nodetool normally from the Windows command line, but I'm not able to run it from the Git Bash (directly from terminal or through a sh script) or Cygwin when running .sh files that call NodeTool (but otherwise can run it).
The exact error I get is:
Error: Could not find or load main class org.apache.cassandra.tools.NodeCmd
I haven't done any kind of extra configuration outside of the recommended changes Datastax recommends, and I haven't had any other issues with Cassandra. I don't think I have any environment screw ups (but who knows what could be wrong). Has anyone else run into this issue before? Thanks!

Having trouble with post-commit hook

I am following this tutorial that is like the hello world for post-commit
I am using Ubuntu 10.04. I installed svnnotify and ran $ which svnnotify which output:
/usr/bin/svnnotify
so I changed the path in the turorial from /usr/local/bin/svnnotify to /usr/bin/svnnotify
I also tried changing the line: #!/bin/sh to #!/bin/bash since bash is the login shell in ubuntu 10.04.
I tried to run it the way the tutorial originally had it, with my changes, and combinations of the two.
Every time the commit is successful but I get
Warning: post-commit hook failed (exit code 1) with no output.
The original way had output not found
I am very new to linux and shell scripting and have exhausted everything I can think of. What am I doing wrong?
Get the script working and tested before trying to run as a commit hook. I expect that your problem is something to do with the script, maybe not being marked as executable, environment wrong, etc.. i.e. if you can't get it to run successfully from the command line, this is more of a unix/shell question and doesn't really have anything to do with SVN (yet).
I'm not sure whether this applies in the Linux world, but in the Windows versions of SVN I've used, the code which runs the hook scripts only captures STDERR. If your hook script is only writing messages to STDOUT, that would likely explain the "No Output" warning.

module: command not found

I'm attempting to load several modules for building a library on Linux but am told that the command 'module' doesn't exist. I've Googled around and discovered that the solution was to source a directory called "module" which I am unable to locate despite extensive searching.
I'm not quite sure what I should and any help would be appreciated (it might help to know that the makefile I'm working with uses csh while my default shell is bash). Thanks!
I tried to reproduce it and it turns out that for me sourcing
source /etc/profile.d/modules.sh
in th .sh script helps for bash and similar. For csh and tcsh, you have to add
source /etc/profile.d/modules.csh
to the script. Note, that this line must come first and then the
module load foo
line.
I got here as I was searching for ways to install multiple php versions in CentOS7 and https://blog.remirepo.net/post/2019/05/22/PHP-7.4-as-Software-Collection was one of the articles I tried to follow and encountered the same "module: command not found" issue.
Sourcing /etc/profile via command:
. /etc/profile
seems to make the "module load" work.
Credits to fadishei in https://forums.fedoraforum.org/showthread.php?262708-module-command-not-found
To make the version of php (e.g. php7.4) persist, append the following to file /etc/profile.d/custom.sh
source /etc/profile.d/modules.sh
module load php74
Reboot and run the php --version to cross-check that php 7.4 is the current version installed.
I think that you have to put this in your script to define the module command:
module () {
eval `/usr/bin/modulecmd bash $*`
}
This was working for me
#!/bin/bash -i // it will make this interactive

Resources