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
Related
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.
I wrote a function to handle unknown commands in bash
via command_not_found_handle ().
My intention is to source scripts on demand and access
its functions inside the handler.
But unfortunately the sourced functions run in a subshell so
variables are lost after return/exit.
Finally I did it with some signal/trap/fifo mechanism to command_not_found_handle's parent shell to achieve my goal, but its everything but elegant.
Now I am wondering if function_not_found_handle loadable builtin could be implemented.
The builtin should be called if command_not_found_handle () fails.
For the time being I found a great article by Ed Schaefer about this subject, but it seems to be an entrance point.
Is anyone experienced with dynamically loadable builtin bash commands?
Who could point me to useful information?
I hope to come up with some results soon to concretize my question.
Thank you!
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.
In Haxe, is there a method in the Sys class (or some other class) that returns the output of a shell command (for example, the command "ls"), or will I need to implement this method myself for each target language? I'd like to find a method for invoking shell commands that works with every Haxe target language.
Yes, your own comment contain the answer, which is:
var output = new sys.io.Process("ls", []).stdout.readAll().toString();
Or the cross platform way: sys.FileSystem.readDirectory('')
It might also be faster, because it doesn't invoke an extra process.
Do you know if there's any tool for compiling bash scripts?
It doesn't matter if that tool is just a translator (for example, something that converts a bash script to a C program), as long as the translated result can be compiled.
I'm looking for something like shc (it's just an example -- I know that shc doesn't work as a compiler). Are there any other similar tools?
A Google search brings up CCsh, but it will set you back $50 per machine for a license.
The documentation says that CCsh compiles Bourne Shell (not bash ...) scripts to C code and that it understands how to replicate the functionality of 50 odd standard commands avoiding the need to fork them.
But CCsh is not open source, so if it doesn't do what you need (or expect) you won't be able to look at the source code to figure out why.
I don't think you're going to find anything, because you can't really "compile" a shell script. You could write a simple script that converts all lines to calls to system(3), then "compile" that as a C program, but this wouldn't have a major performance boost over anything you're currently using, and might not handle variables correctly. Don't do this.
The problem with "compiling" a shell script is that shell scripts just call external programs.
In theory you could actually get a good performance boost.
Think of all the
if [ x"$MYVAR" == x"TheResult" ]; then echo "TheResult Happened" fi
(note invocation of test, then echo, as well as the interpreting needed to be done.)
which could be replaced by
if ( !strcmp(myvar, "TheResult") ) printf("TheResult Happened");
In C: no process launching, no having to do path searching. Lots of goodness.