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.
Related
I want to use my_name to compile my program ; instead of make
command . Any idea to do the same ??
Your question is difficult to decipher, but one approach is to make a shell script that calls make (or your program, if that's what you're asking about) and name this script whatever you want.
I'm currently running into a bog-standard Bobby Tables problem, but the environment is Chef + Ruby + powershell.
All of the solutions I've seen so far appear inadequate: they surround the arguments with quotes, but do not fully escape the arguments. Shellwords and shellescape look promising, but they appear to be bash-specific.
For example, I may want to construct in Chef this windows shell command:
.\foo.exe BAR="#{node['baz']}"
Generalizing from the SQL dev world I'd naively anticipate an interface something like this:
cmd = "foo.exe BAR=?"
args = (node['baz'])
run-command(cmd, args)
Where run-command would handle escaping any arguments. Instead I see interfaces that remind me of the bad old SQL days when developers had to construct SQL as a string, and escape any arguments "by hand".
Any pointers to best practices on how to proceed? Use system? Thanks!
Edit: to be clear, the argument baz above can be expected to include arbitrary text, including possibly any combination of characters. Think of it as being identical to the Bobby Tables problem.
The easiest generic solution is to use the array form for the execute resource's command property. This avoids all shell parsing an runs the command verbatim.
execute 'whatever' do
command ['foo.exe', "BAR=#{node['baz']}"]
end
This doesn't work for script style resources though, which take a string for the script chunk to run, including powershell_script. There you would need something more tailored to PowerShell and I don't know its rules well enough to say if Shellwords would match.
The scala documentation shows that the way to create a scala script is like this:
#!/bin/sh
exec scala "$0" "$#"
!#
/* Script here */
I know that this executes scala with the name of the script file and the arguments passed to it, and that the scala command apparently knows to read a file that starts like this and ignore everything up to the reversed shebang !#
My question is: is there any reason why I should use this (rather verbose) format for a scala script, rather than just:
#!/bin/env scala
/* Script here */
This, as far a I can tell from a quick test, does exactly the same thing, but is less verbose.
How old is the documentation? Usually, this sort of thing (often referred to as 'the exec hack') was recommended before /bin/env was common, and this was the best way to get the functionality. Note that /usr/bin/env is more common than /bin/env, and ought to be used instead.
Note that it's /usr/bin/env, not /bin/env.
There are no benefits to using an intermediate shell instead of /usr/bin/env, except running in some rare antique Unix variants where env isn't in /usr/bin. Well, technically SCO still exists, but does Scala even run there?
However the advantage of the shell variant is that it gives an opportunity to tune what is executed, for example to add elements to PATH or CLASSPATH, or to add options such as -savecompiled to the interpreter (as shown in the manual). This may be why the documentation suggests the shell form.
I am not on the Scala development team and I don't know what the historical motivation for the Scala documentation was.
Scala did not always support /usr/bin/env. No particular reason for it, just, I imagine, the person who wrote the shell scripting support was not familiar with that syntax, back in the mid 00's. The documentation followed what was supported, and I added /usr/bin/env support at some point (iirc), but never bothered changing the documentation, it would seem.
Given that my Ada builder use a function ada_action which is registered by
static_obj.action(suffix, Action(ada_action, print_action_string)
which currently calls env.Execute() and further
def print_action_string(target, source, env):
print env.subst(env["ADACOMSTR"], target=target, source=source)
How can I control the verbosity levels so that if env["ADACOMSTR"] is defined it should only call print_action_string and inhibit echoing of the shell command currently done by env.Execute()?
You normally don't need to use Execute() in a builder action. Perhaps if you share that bit of code it might help. You could also look into using a generator, depending on what exactly you're looking for.
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.