not able to run .sh file using java - shell

I have a .sh file which i am trying to run using runtime api.
It runs perfectly if .sh file is under main project folder, but I want it to be accessed from outside the project folder.
example: /home/test/test.sh.
When i try to run this I get /home/test/test.sh not found error
Can anyone tell me how to execute .sh file using runtime accessing the file from local system?

is the .sh file chmoded to be executable?
if its not you could either:
chmod +x /home/test/test.sh
or
when you call the script pass it through sh so:
sh /home/test/test.sh

Runtime.exec() is not a command line
One pitfall to cover with Runtime.exec() is mistakenly assuming that exec() accepts any String that your command line (or shell) accepts. Runtime.exec() is much more limited and not cross-platform. This pitfall is caused by users attempting to use the exec() method to accept a single String as a command line would. The confusion may be due to the fact that command is the parameter name for the exec() method. Thus, the programmer incorrectly associates the parameter command with anything that he or she can type on a command line, instead of associating it with a single program and its arguments.

Related

Instead of giving command for batch mode, give .scm file path?

It is possible to supply batch commands directly with the -b flag, but if the commands become very long, this is no longer an option. Is there a way to give the path to an .scm script that was written to a file, without having to move the file into the scripts directory?
No as far as I know. What you give in the -b flag is a Scheme statement, which implies your function has already been loaded by the script executor process. You can of course add more directories that are searched for scripts using Edit>Preferences>Folders>Scripts.
If you write your script in Python the problem is a bit different since you can alter the Python path before loading the script code but the command line remains a bit long.

write to terminal via bash script

I have to run some hundreds of simulations and scan the output file for a certain variable. In order to run the program, I need to write
$SIMPLESIM/simplesim-3.0/sim-outorder -config ../../config/tmp.cfg bzip2_base.i386-m32-gcc42-nn dryer.jpg
to the terminal, where tmp.cfg is the config file I will be modifying for each simulation. Running this outputs a file in which I named via tmp.cfg. This obviously works when I literally type it into terminal, however, in bash script, running this command gives me the error
simplesim-3.0/sim-outorder no such file or directory
I believe it has to do with the $ symbol? Thanks for any help.
Before calling any command its path must be defined in $PATH variable or you have to manually give the complete path to invoke it.
So define SIMPLESIM in script to the path, like SIMPLESIM=/usr/bin , this /usr/bin is for reference only.To know the path do echo $SIMPLESIM in terminal and see the path
and call the command $SIMPLESIM/simplesim-3.0/sim-outorder -config ../../config/tmp.cfg bzip2_base.i386-m32-gcc42-nn dryer.jpg

Simple Linux shred script error

I have an ultra-simple script that houses the Linux program shred, and it contains the parameters that have always worked from the command line (bash). Specifically 'shred -uzn 35'
The script, named D, has execute permissions set.
When I run the script, bash prints an error:
$ D some_file_to_delete
shred: missing file operand
I realize that the solution to the problem is probably as simple as the program itself. Please help?
Thanks in advance.
EDIT: The error "missing file operand" was due to the fact that the script was not set to take arguments, such as via "$#". Also, as stated in the accepted answer, I agree that an alias makes total sense for such a scenario (much more sense than, say, a script somewhere in $PATH).
Since you are using a script, not an alias, you need to pass the arguments through
shred -uzn 35 "$#"
In this case, however, I suggest you do make it an alias. In your .bashrc file, add this:
alias D='shred -uzn 35'

How Secure is using execFile for Bash Scripts?

I have a node.js app which is using the child_process.execFile command to run a command-line utility.
I'm worried that it would be possible for a user to run commands locally (a rm / -rf horror scenario comes to mind).
How secure is using execFile for Bash scripts? Any tips to ensure that flags I pass to execFile are escaped by the unix box hosting the server?
Edit
To be more precise, I'm more wondering if the arguments being sent to the file could be interpreted as a command and executed.
The other concern is inside the bash script itself, which is technically outside the scope of this question.
Using child_process.execFile by itself is perfectly safe as long as the user doesn't get to specify the command name.
It does not run the command in a shell (like child_process.exec does), so there is no need to escape anything.
child_process.execFile will execute commands with the user id of the node process, so it can do anything that user could do, which includes removing all the server files.
Not a good idea to let user pass in command as you seem to be implying by your question.
You could consider running the script in a sandbox by using chroot, and limiting the commands and what resides on the available file system, but this could get complet in a hurry.
The command you pass will get executed directly via some flavor of exec, so unless what you trying to execute is a script, it does not need to be escaped in any way.

Is it possible to override hashbang/shebang path behavior

I have a bunch of scripts (which can't be modified) written on Windows. Windows allows relative paths in its #! commands. We are trying to run these scripts on Unix but Bash only seems to respect absolute paths in its #! directives. I've looked around but haven't been able to locate an option in Bash or a program designed to replace and interpreter name. Is it possible to override that functionality -- perhaps even by using a different shell?
Typically you can just specify the binary to execute the script, which will cause the #! to be ignored. So, if you have a Python script that looks like:
#!..\bin\python2.6
# code would be here.
On Unix/Linux you can just say:
prompt$ python2.6 <scriptfile>
And it'll execute using the command line binary. I view the hashbang line as one which asks the operating system to use the binary specified on the line, but you can override it by not executing the script as a normal executable.
Worst case you could write some wrapper scripts that would explicitly tell the interpreter to execute the code in the script file for all the platforms that you'd be using.

Resources