I'm trying to use the input function from the Sys class, but when I run the build and the prompt occurs, I'm unable to enter any input. What alternatives are there to Sys, or what ought I do to resolve this? I've checked Haxelib and haven't found anything that I think can be used.
For reference, what I have written:
Sys.println("First player's name: ");
var p1:String = Sys.stdin().readLine();
My hxml args:
-main Main.hx
-cp src
-cp src/cards
-cp src/cards/library
-lib Random
-neko test.n
-cmd neko test.n
It works fine if you manually start the generated test.n instead of doing that via -cmd in the hxml. I suspect that the Haxe process does not direct input to the stdin of the -cmd process or something like that.
If you still want to compile and run at the same time, I recommend creating a little .bat (or .sh if you're on Linux) script for this:
haxe build.hxml
neko test.n
Related
I've recently started using fish, and I needed to use a jar file for google's bundletool.
As such, I needed to set up an alias/function for bundletool, and I chose a function since it seems more "fishy".
My function is simple:
function bundletool
java -jar bundletool-all-1.12.1.jar $argv
end
The bundletool jar itself lives at ~/.local/bin, which is on my fish user path:
lase#laser-razer /m/c/U/matth [1]> echo $fish_user_paths
/home/lase/.local/bin /usr/local/go/bin /home/lase/.nvm /home/lase/.cargo/bin /home/lase/.cargo
In a regular shell, I can execute java -jar bundletool-all-1.12.1.jar, and the command runs as expected. However, in the function, fish doesn't seem to know about my fish_user_paths, and reports it cannot find the jar file.
To remedy this, I had to update my function to specify the full path:
function bundletool
java -jar ~/.local/bin/bundletool-all-1.12.1.jar $argv
end
This works, but I feel like I'm doing something incorrectly. Should I be setting up my paths or functions in a different fashion?
Your function will run in the ordinary environment.
It will run with the current $PATH [0] and, more importantly to you, the current working directory.
What happens is this:
java -jar bundletool-all-1.12.1.jar
Will tell java to run the jar found at bundletool-all-1.12.1.jar.
Notably, fish just hands java the string "bundletool-all-1.12.1.jar", and java will then not look at $PATH. It does not care about $PATH. It simply looks at "bundletool-all-1.12.1.jar", and tries to open a file by that name.
And it will find that file, if it is in the current directory.
And that's the reason this worked for you when you executed it interactively - because you happened to be in that directory
And then you tried it with the function, but you tried it from a different directory, and so it didn't work.
This works, but I feel like I'm doing something incorrectly. Should I be setting up my paths or functions in a different fashion?
No, giving the full path to the file instead of relying on the working directory is the right thing to do.
[0]: $fish_user_paths is just a variable you set, that fish will then take care to add to $PATH. $PATH is the actual variable that fish and other tools (including any command fish starts, if it wants to) will use to find commands.
I am working on a program that I want to run a console command and save the output to a string. This program is installed by the user before running my program.
However, I have found I keep getting the error Cannot run program "XXXX" (in directory "C:\Users\accou\Downloads"): CreateProcess error=2, The system cannot find the file specified
For example, I have the program "Maui" that I have added to my system path:
Running in my Command Prompt:
C:\Users\accou\Downloads>maui
HELLO
C:\Users\accou\Downloads>
If I run the following code in Java I get the exception above
ProcessBuilder pb =
new ProcessBuilder("maui");
pb.directory(new File("C:\\Users\\accou\\Downloads"));
File log = new File("C:\\Users\\accou\\Downloads\\log.txt");
pb.redirectErrorStream(true);
pb.redirectOutput(ProcessBuilder.Redirect.appendTo(log));
Process p = pb.start();
assert pb.redirectInput() == ProcessBuilder.Redirect.PIPE;
assert pb.redirectOutput().file() == log;
assert p.getInputStream().read() == -1;
Exception:
Exception in thread "main" java.io.IOException: Cannot run program "maui" (in directory "C:\Users\accou\Downloads"): CreateProcess error=2, The system cannot find the file specified
at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1142)
at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1073)
at Application.main(Application.java:13)
Caused by: java.io.IOException: CreateProcess error=2, The system cannot find the file specified
at java.base/java.lang.ProcessImpl.create(Native Method)
at java.base/java.lang.ProcessImpl.<init>(ProcessImpl.java:483)
at java.base/java.lang.ProcessImpl.start(ProcessImpl.java:158)
at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1109)
... 2 more
I will get the same error if I try commands such as "dir" which I know 100% is available in windows.
However, if I can the command to the following it workes perfectly fine.
new ProcessBuilder("cmd.exe", "/c", "maui");
The following also works
new ProcessBuilder("maui.cmd");
Why is it that I cannot run "dir" or more importantly "maui" directly?
You're confusing ProcessBuilder with a shell. ProcessBuilder is not 'ask the dos box cmd shell to act as if we ran this statement', and when you type something in that black box, such as 'dir', that is not the same as 'ask the OS to execute this process'.
The shell does all sorts of intriguing transformations and interpretations of what you typed. That's cmd.exe (or, on other OSes, e.g. /usr/bin/bash), it is not the OS doing that, and java does not ship with a bash or cmd.exe baked in. It just asks the OS to do what you asked.
Thus, you can't use all these shellisms. Unfortunately, java tries to do some very basic shellisms, which just adds confusion. In particular:
The single-string argument variant will split on spaces to attempt to extract the executable to run + the arguments to pass.
On windows, *.txt and friends probably works. On other OSes it probably does not, as expanding a star into all matching files is a bashism. Best not use it.
built-ins, such as cd, pwd, test, dir, and others definitely do not work.
Relying on $PATH probably doesn't work, but this is one that java does sometimes try to apply. Still, best not rely on it.
Any fancy redirects and the like are all shellisms and do not work. You can't ask java to redirect to printer using foo.exe >PRN or /usr/bin/whatnot >/dev/printer. You can't write an if or a loop, or use %foo% or $foo or any other such things.
This leads to the following conclusion:
Do not ever use relative paths for anything ProcessBuilder related.
Do not ever try to squeeze the executable and the arguments into a single string; always use the multiple strings variant.
Don't rely on ANYTHING other than an absolute path, and absolute arguments.
If you need any shellisms of any sort, run cmd.exe /c C:\absolute\path\to\something.bat, or on posixy systems, /bin/bash -c /abs/path/to/shellscript, and strongly consider on windows to use System.getenv to get the installed location of windows, so you can absolute-path cmd to thatPath + "cmd.exe", so that you end up with "C:\\Windows\\cmd.exe" or equivalent (windows may not actually be installed there, hence, use env).
Unwieldy? Yeah. Don't use ProcessBuilder unless you know what you are doing.
In this case, if type maui on the command line, it's cmd.exe that figures out: Oh, hey, there is a maui.cmd in this dir on the path, surely they meant that. That's a shellism. Not baked into the OS itself, and java does not ship with cmd.exe built in, so that does not work. dir is not an executable but a built-in feature of cmd.exe. Same rule.
Java can do all these baked in things. There is no need to call dir - java can walk paths and give you all relevant info with e.g. the java.nio.file.Files API.
I have a set of json files in directory /Desktop/jsons, and I have a Scala script which takes in a json and outputs stuff. I can run it manually in the terminal by cding into the directory of the Scala script (/Me/dev/scalastuff) and running
sbt --error "run /Desktop/jsons/jsonExample.json",
which outputs the stuff I want in the terminal.
I want to write a Python script which does this automatically and additionally outputs a json file with the "stuff" thats outputted by the Scala script.
My issues right now are using subprocessing. When I try to run
BASEDIR = '/Me/dev/scalastuff'
p = subprocess.Popen(['sbt --error "run /Desktop/jsons/jsonExample.json"'], cwd = BASEDIR, stdout = subprocess.PIPE)
out = p.stdout.read()
print out
I get OSError: [Errno 2] No such file or directory.
I'm completely stumped as to why this is occurring. I'm new to subprocess, so be light on me!
popen in python takes a list of shell arguments. You're passing only one!
So it's trying to execute a file named wholly 'sbt --error "run /Me/Desktop/jsons/jsonExample.json"'.
Obviously, this doesn't work.
If you use popen; only pass a simple array -- you needn't care about escaping:
subprocess.popen(['sbt', '--error', 'run /Me/Desktop/...'], cwd = BASEDIR, stdout = subprocess.PIPE)
I am having trouble launching an executable that I have created from a shell script. I would like to automate testing by running the program many times with different command line options to verify it is working.
When I type echo $SHELL, /bin/sh is displayed.
The following is my shell script:
#!/bin/sh
clear
echo "Running first test."
./myProgram
exit 0
When I run the script (sh myScript.sh), with myProgram in the same directory, I see the following output:
Running first test.
: not foundsh: line 4:
When executing the program ./myProgram, it runs as expected with no command line options.
I have also tried:
myProgram
./myProgram &
myProgram &
based on answers to somewhat similar questions, but they all result in the above error message.
Your newlines are goofed. Use dos2unix to fix.
why don't you try using the full path?
e.g., if myProgram is in /home/user1/bin, you can try /home/user1/bin/myProgram instead of ./myProgram. This should work.
You can also add the path to path variable, $PATH and directly call myProgram from anywhere.
Run "export PATH=$PATH:/home/user1/bin" on your terminal without the quotes. Note that this affects only your current termial session. If you want to permanently add the path, update your .bashrc file in your home directory with the following line:
I have script lets say:
C:\foo.bsh
I want to be able to run this command via the windows run command:
Start -> Run
Windows Key + R
and type something small like 'foo' and hitting return.
However, I do not want a cmd prompt to be visible. This script does some preprocessing for an IDE. I do not want the cmd prompt to be open for the lifetime of the IDE process.
I have tried:
1) Creating a bat file with the following contents:
c:\cygwin\bin\bash --login "C:\foo.bsh" (this fails because it keeps a cmd open)
2) Converting the above bat file to an exe using bat_2_exe_converter (does not make the cmd silent)
thoughts?
EDIT: The solution so far suggests something to type from an actual cygwin shell. I am trying to get a faster solution by having something short I can type in the Windows run command. Also, the nohup command; exit doesn't automatically kill the box - however I can manually kill it without killing the IDE process. The run command accepts shortcuts (.lnk's), bat's, exe's.
Try the run.exe command of cygwin. It is a big install, a complete unix environment for your Windows machine. Suppose you installed it at c:\cygwin\.
No mystery, just run c:\cygwin\bin\run.exe <your command here> and you will have your no dos window execution.
You can run it from any DOS window (run cmd.exe from the start menu). You don't need to run it from cygwin.
To make it easier, append C:\cygwin\bin to your %PATH% env var (My Computer → Properties → Advanced → Environment Variables) (Kudos to Felipe Alvarez comment).
Now you can just type
c:\cygwin\bin\run.exe "C:\foo.bsh"
You must create a link in your Start Menu with this command so will be able to run it with Win-R.
Here is the man page of the runcommand:
$ man run
RUN(1) run 1.3.0 RUN(1)
NAME
run - start programs with hidden console window
SYNOPSIS
run [ -p path ] command [ -wait ] arguments
runcommand [ -p path ] [ -wait ] arguments
DESCRIPTION
Windows programs are either GUI programs or console programs. When
started console programs will either attach to an existing console
or create a new one. GUI programs can never attach to an exiting con‐
sole. There is no way to attach to an existing console but hide it if
started as GUI program.
run will do this for you. It works as intermediate and starts a pro‐
gram but makes the console window hidden.
With -p path you can add path to the PATH environment variable.
Issuing -wait as first program argument will make run wait for program
completition, otherwise it returns immediately.
The second variant is for creating wrappers. If the executable is
named runcommand (eg runemacs), run will try to start the program (eg
emacs).
EXAMPLES
run -p /usr/X11R6/bin xterm
run emacs -wait
runemacs -wait
run make -wait
AUTHORS
Charles S. Wilson
Harold L Hunt II
Jehan Bing
Alexander Gottwald
Version 1.3.0 November 2005 RUN(1)
You can use either...
c:\cygwin\bin\bash -l /path/to/script_to_interpret.sh
...or...
c:\cygwin\bin\bash -l -c /path/to/executable_script.sh
Note: the -l flag tell bash to "act as if it had been directly invoked by login" and use Bash Startup Files. This is important in that it sets your $PATH and other things you rely on when you launch a cygwin terminal. If you don't include -l or --login you will get "command not found" when you try to call anything except of a bash builtin.
The difference between the 2 is like the difference between doing...
bash script_to_interpret.sh
...and...
./executable_script.sh
...in *nix. The former interprets the script using bash. The latter executes the script (only if it has chmod +x executable_script.sh) and interprets it according to its "shebang" line. The latter method is also what you want to do if your executable is not a script at all, like a *nix binary compiled from source.)
It has been bugging me for a while I couldn't find the solution for this, but I finally got the right mix together.
You can simply do the following if you have cygwin on your PATH:
run bash test.js
If cygwin is not on your path, you can do this:
c:\cygwin\bin\run.exe -p /bin bash test.js
If you are looking for more control over the created window (maximize, etc) it looks like you can use cygstart also.
Sources:
- neves answer above (though that wasn't enough by itself for me personally to figure it out)
- http://cygwin.com/ml/cygwin/2008-09/msg00156.html
As the terminal can't close while your script is still running, try the command:
"nohup C:\foo.bsh; exit"
This way your script will be backgrounded and detached from the terminal, and it should exit quickly so the terminal goes away. I think that the window may still 'flash' with this approach, but the results should be better than what you're getting.
I'm running Cygwin64 and the xwin server link points to:
C:\cygwin64\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/startxwin.exe
This creates an icon AND a notification on the taskbar. I don't like that. The icon is rather useless, the notification has all your menu options from .XWinrc.
So... I wrote a .vbs script to silently run this command and make the icon go away:
Set objShell = CreateObject("WScript.Shell")
objShell.Run("C:\cygwin64\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/startxwin.exe"), 0
Another imperfect possibility is to run the script via a shortcut and set the shortcut's Run option to "minimized".
Go to the directory where you have installed cygwin(on my machine it is c:/cygwin64/bin)
Once there simply type "bash.exe"