I have an OSGi environment which runs on equinox. For the execution of custom comands I use the gogo shell (org.apache.felix.gogo.command, org.apache.felix.gogo.shell).
By default the command scope is set to equinox so the help command does not print anything. If I use felix:help it does print all of the available commands.
How do I switch the default command scope to felix? Is there a way to give the system a startup script which sets that up?
Additionally, how can I force the user to use the scope I introduce in the component property like shown here:
property = {
"osgi.command.scope=myScope",
"osgi.command.function=myFunc"
}
=> I want that the user has to write myScope:myFunc into the shell. Is that possible anyhow?
Thanks for your help :-)
You can make your own commands since Gogo has closures.
Welcome to Apache Felix Gogo
g!
g! h = { felix:help }
felix:help
g! h
felix:bundlelevel
felix:cd
felix:frameworklevel
...
g! $h
felix:help
You can put a startup script in ./etc/gosh_profile, where . is the current working directory.
The SCOPE variable sets up a colon separated path for searching the scopes.
g! SCOPE='felix:*'
Gogo is way more powerful that almost everybody I know thinks. Gogo can basically call any Java function with shell like syntax. You can see some examples here: https://v2archive.enroute.osgi.org/appnotes/gogo.html
Related
I have a Rails application and am trying to communicate with a Java program via the CLI.
When I run the Java code using system:
system "java askQuestion"
it prompts for user input and waits for an answer, such as "What is your age?"
I want to pass a value in from a variable, and capture the output.
How can I interact with the CLI and run the command?
I did research but I couldn't find anything or I missed the correct term to search.
Solution: IO.popen
update -->
I found here what exactly I want and share maybe help someone else too , http://ruby.bastardsbook.com/chapters/external-programs/
Kernel#system just executes the command in a subshell, returning the result (true/false) of process start.
To catch the output, use backticks (or %x||).
To interact with a shell, one might use IO#popen, but in your case I would just stick to executing
output = `echo 37 | java askQuestion`
The above will pass the output of echo (37 in this particular case) to the Java process. The response of the Java process will be stored in the output variable.
I have written a shell script with commands like:
version=$1;
sed -i 's/def version = ".*"/def version = "'$version'"/' $file;
grails package-plugin;
echo -n 'Enter description of new version: ';
read desc;
git commit -m "$desc";
I want to convert it into a groovy script i.e, to create a custom grails-command that does the same thing, using GANT.
I searched a lot. But, I'm unable to find the proper methods in Apache Ant API to run a linux command like above.
Please suggest me a solution to my shell-script code with equivalent GANT script
Atleast suggest me where to start with to achieve my task.
Thank you very much in advance...
Well at last, I have figured it out how to perform the above said task.
Thanx to Grails documentation and Apache Ant tasks manual . .
After taking a whole day time, I observed that for any task to be performed:
one can refer to Apache Ant manual first,
Find it in the index,
and then knowing its usage along with necessary arguments and examples given in XML,
Then observe how XML syntax is converted to corresponding Groovy script i.e., GANT script
For e.g., observe the mkdir task and its corresponding usage in grails doc example i.e., use ant variable, then . task-name [ arguments-map ]
For those shell commands which don't have a direct task in Apache Ant manual, use exec() to run the command
That's it ... task complete :)
In REE, and MRI 1.9+, ruby's garbage collector can be tuned:
http://www.rubyenterpriseedition.com/documentation.html#_garbage_collector_performance_tuning
http://smartic.us/2010/10/27/tune-your-ruby-enterprise-edition-garbage-collection-settings-to-run-tests-faster/
http://blog.evanweaver.com/articles/2009/04/09/ruby-gc-tuning/
But none of these articles say where to put this configuration. I imagine that if it's in the environment, ruby will pick it up when it starts -- however, there's no way to check this as far as I can tell. The settings don't show up in any runtime constants that I can find.
So, where do I put this configuration, and how can I double-check that it's being used?
These settings are environment variables, so you would just need to set them in the parent process of the ruby process itself. Many people recommend creating a simple shell script for this purpose, perhaps calling it /usr/local/bin/ruby-custom:
#!/bin/bash
export RUBY_HEAP_MIN_SLOTS=20000
export RUBY_HEAP_SLOTS_INCREMENT=20000
...etc...
exec "/path/to/ruby" "$#"
The first few lines set whichever custom variables you want, and the last line invokes ruby itself, passing it whatever arguments this script was initially given.
You will next need to mark this script as executable (chmod a+x /usr/local/bin/ruby-custom) and then configure Passenger to use it as the ruby executable, by adding this to your Apache .conf file:
PassengerRuby /usr/local/bin/ruby-custom
I've pulled a few scripts into Jenkins for a proof of concept and think I'd like to move that direction for all of our scripts. Right now I keep an environment.rb file with my code (watir-webdriver, cucumber) which tells the script which environment we're testing and which browser to use (global variables). Jenkins fires off the script using rake.
I'd love to let the user choose the environment and browser through Jenkins 'choice' variable or similar, and then pass that to the script. While I see the framework in that for Jenkins and set up a choice list for environment, I'm having trouble determining what the next step is.
I could write to environment.rb, I could pass a variable to rake - I have many options for how to pass the information, I just need some assistance finding the first step to find the Jenkins way of accomplishing them. Google results and previous Stack questions weren't what I was looking for.
Thanks
Sure. Give the user either a text entry field a dropdown after telling Jenkins that this is a parameterized build. You'll give them a name, something like BuildEnvironment. Then when you call the build, you can pass these from the environment variables. For example, if you were using ANT, you'd add a line to the parameters that said environment = ${MyEnvironment} Jenkins will then pass the value along for your build tool to use.
There is a way to pass Jenkins Environment Variable to Ruby script. Please see the following example:
workspace_path = `echo $WORKSPACE`.strip # note the use of backticks
puts workspace_path
In the "echo $WORKSPACE".strip # the code work only if you replace quotes with backticks
This code example works in Jenkins on a Linux system.
While playing with Heroku, I found their approach of using environment variables for server-local configuration brilliant. Now, while setting up an application server of my own, I find myself wondering how hard that would be to replicate.
I'm deploying a sinatra application, riding Unicorn and Nginx. I know nginx doesn't like to play with the environment, so that one's out. I can probably put the vars somewhere in the unicorn config file, but since that's under version control with the rest of the app, it sort of defeats the purpose of having the configuration sit in the server environment. There is no reason not to keep my app-specific configuration files together with the rest of the app, as far as I'm concerned.
The third, and last (to my knowledge) option, is setting them in the spawning shell. That's where I got lost. I know that login and non-login shells use different rc files, and I'm not sure whether calling something with sudo -u http stuff is or not spawning a login shell. I did some homework, and asked google and man, but I'm still not entirely sure on how to approach it. Maybe I'm just being dumb... either way, I'd really appreciate it if someone could shed some light on the whole shell environment deal.
I think your third possibility is on the right track. What you're missing is the idea of a wrapper script, whose only function is to set the environment and then call the main program with whatever options are required.
To make a wrapper script that can function as a control script (if prodEnv use DB=ProdDB, etc), there is one more piece that simplifies this problem. Bash/ksh both support a feature called sourcing files. This an operation that the shell provides, to open a file and execute what is in the file, just as if it was in-lined in the main script. Like #include in C and other languages.
ksh and bash will automatically source /etc/profile, /var/etc/profile.local (sometimes), $HOME/.profile. There are other filenames that will also get picked up, but in this case, you'll need to make your own env file and the explicitly load it.
As we're talking about wrapper-scripts, and you want to manage how your environment gets set up, you'll want to do the sourcing inside the wrapper script.
How do you source an environment file?
envFile=/path/to/my/envFile
. $envFile
where envFile will be filled with statements like
dbServer=DevDBServer
webServer=QAWebServer
....
you may discover that you need to export these variable for them to be visble
export dbServer webServer
An alternate assignment/export is supported
export dbServer=DevDBServer
export webServer=QAWebServer
Depending on how non-identical your different environments are, you can have your wrapper script figure out which environment file to load.
case $( /bin/hostame ) in
prodServerName )
envFile=/path/2/prod/envFile ;;
QASeverName )
envFile=/path/2/qa/envFile ;;
devSeverName )
envFile=/path/2/dev/envFile ;;
esac
. ${envFile}
#NOW call your program
myProgram -v -f inFile -o outFile ......
As you develop more and more scripts in your data processing environment, you can alway source your envFile at the top. When you eventually change the physical location of a server (or it's name), then you have only one place that you need to make the change.
IHTH
Also a couple of gems dealing with this. figaro that works both with or without heroku. Figaro uses a yaml file (in config and git ignored) to keep track of variables. Another option is dotenv that reads variables from an .env file. And also another article with all them options.
To spawn an interactive shell (a.k.a. login shell) you need to invoke sudo like this:
sudo -i -u <user> <command>
Also you may use -E to preserve the environment. This will allow some variables to be pased for your current environment to the command invoked with sudo.
I solved a similar problem by explicitly telling Unicorn to read a variables file as part of startup in its init.d script. First I created a file in a directory above the application root called variables. In this script I call export on all my environment variables, e.g. export VAR=value. Then I defined a variable GET_VARS=source /path/to/variables in the /etc/init.d/unicorn file. Finally, I modified the start option to read su - $USER -c "$GET_VARS && $CMD" where $CMD is the startup command and $USER is the app user. Thus, the variables defined in the file are exported into the shell of Unicorn's app user on startup. Note that I used an init.d script almost identical to the one from this article.