I'd like to call a shell script from within a Rego script.
How can I do it?
The rego built-in functions don't seem to help.
You can't. Rego isn't a general purpose programming language, and policy evaluation should ideally be free of side effects — i.e evaluating the same policy twice with identical input should render identical results. Best alternative is likely to execute your shell script first, and provide the result as input to OPA. If you really want to run a shell script from inside your policy, a custom built-in function would be the way to go.
Related
Simple question - I have a shell script that initiates other subscripts as its only major function. Is there any industry standard / best practice name for this type of script?
You could call this a wrapper script, perhaps?
http://tldp.org/LDP/abs/html/wrapper.html
I need to refer to the same variable in several functions in a python script. (The write context of a CGPDFDocument).
I can either write global writeContext in every function;
or add the variable as an argument to every function;
....both of which seem to be excessive duplication.
Other answers to questions about global variables in python suggest that they are "bad".
So what's the better way of handling it?
I work on a team that decided long ago to use Chef's template resource to make dynamic scripts to be executed in an execute reource block.
I know this feature was only built to generate config files and the like, but I have to work with what I've got here.
Basically I need to know how to write to Chef::Log from a Ruby script generated from a template block. The script is not in the same context as the cookbook that generated it, so I can't just call require 'chef/log' in the script. I also do not want to just append the chef-run.log because that runs into timing problems.
Is there any way to accomplish this as cleanly as possible without appending to chef-run.log?
Thank you for your time.
Chef::Log is a global, so technically you can just call its methods directly from inside a template, but this is really weird and you probably shouldn't. Do whatever logging you need from the recipe code instead. If you need to log some values, compute them in the recipe and them pass them in using variables.
Simple question. I'd like to know how to tell whether the current shell is running as a mc subshell or not. If it is, I'd like to enter a degraded mode without some features mc can't handle.
In particular, I'd like this to
Be as portable as possible
Not rely on anything outside the shell and basic universal external commands.
Though it's not documented in the man page, a quick experiment shows that mc sets two environment variables: $MC_TMPDIR and $MC_SID. (It also sets $HISTCONTROL, but that's not specific to mc; it affects the behavior of bash, and could have been set by something other than mc.)
If you don't want to depend on undocumented features, you can always set an environment variable yourself. For example, in bash:
mc() { MC_IS_RUNNING=1 command mc "$#" ; }
Entering a "degraded mode" is another matter; I'm not sure how you'd do that. I don't know of any way in bash to disable specified features. You could disable selected built-in commands by defining functions that override them. What features do you have in mind?
I'm pretty new to Gradle and have to invoke a shell command and parse it's console-output.
After doing some research how to achieve this i ended up with two ways:
The Gradle-way using the task-type: Exec (org.gradle.api.tasks.Exec) with commandLine.
The Groovy/Java-way using java.lang.String with execute and java.lang.Process.
The question is, why should i use the Gradle-way over the Java-way or vice versa? I couldn't find any resource pointing out the difference, yet.
If what You need to do is a pretty standard task it's better to use Gradle's Exec. It's just a wrapper that also starts a command under the hood.
If what You're looking for is a better control or untypical command or maybe a dedicated handling of result it better to use execute() on String (but it's better to pass command as a List to avoid parser issues). It's more low level and needs more coding.