Now I have a question for the mac os. I activated the unattended mode for the installer and tried out this on a win system. There it works fine. Now I wanted to start the installer on a mac os but didn't get it run correctly. I tried the following command:
open MyApp.app --args -q -console -varfile my.varfile
This starts always the GUI installation instead the unattended mode. Maybe the terminal command is incorrect?
Kind regards
Hardie
"/bin/open" is not suitable for command line-style invocations, since the passing of arguments is not synchronous and they are not passed to the main method. Instead, call the executable directly:
MyApp.app/Contents/MacOS/JavaApplicationStub -q -varfile my.varfile
Btw: "-console" is not applicable for Mac OS X, only for Windows.
Related
I currently use MINGW64 (Git Bash) as my terminal on my Windows 10 machine. It works great, I like it, but it only has Vim installed as an editor and I prefer Emacs. I'm unfortunately having a really awful time getting it to work in my terminal.
What's weirder still is that I have Emacs working in Cygwin64; but I don't like using that as my terminal. The most logical fix is simply that it Emacs to my Path ENV, however that doesn't seem to help (perhaps I'm doing that wrong?). I just get bash: emacs: command not found. I found a command to install it, using Pacman, however the Pacman command cannot be found either (which is weird because I thought that was installed by default with MINGW64.
Would love any and all help on this.
A couple of options:
Use Cygwin and the Cygwin emacs. Consider your Cygwin environment completely separate from Windows, so set your PATH from within the .bashrc, not within Windows. Launch emacs from the bash command-line.
Use the Emacs Windows binary distribution, but point to the utilities within Cygwin (there's an emacs package to help with this). Again, launch from the bash command line to inherit the bash environment within emacs.
Use the Windows Subsystem for Linux, with a Linux installation, and stick with emacs from there. You get the best of the Linux world, and access to the Windows directories and files as well.
My goto choice for MANY years was the Emacs Windows binary in conjunction with Cygwin. Once I started using the WSL, however, it just worked a lot better, in a clean Linux environment, and I could get terminal and GUI emacs (and other apps) running using the VcXsrv X Server. WSL has a version that directly supports X Windows, but I don't care for the windowing environment it uses, so I stick with VcXsrv.
Trying to choose Command Prompt in the Terminal however I can only see Zsh, bash, and Javascript bug terminal.... I've gone in to Select Default profile as suggested in similar threads I've found and still can't find it?
How do i get Command Prompt in there?
Note: I don't have Powershell either, and I'm on a Mac
If you are referring to cmd.exe, that is a windows only program and you won't be able to use it on MacOS.
Terminal is the MacOS Equivalent and can run shells such as bash and zsh as you noted.
I'm using GDB 8.0.1 on Mac OS High Sierra 10.13.3. Basically, doing:
(gdb) r < some_input_file.in
ignores the input file. It acts as if the command ran was simply
(gdb) r
The closest thread I found about this problem was Input redirection from file gdb but no solution was posted.
Any clues?
Thanks!
You are probably running into an interaction between gdb and macOS SIP ("System Integrity Protection").
gdb implements run redirections by passing the command line to the shell; then it waits for the shell to invoke your program before starting to "really debug". The shell is actually still controlled by gdb using ptrace -- gdb uses this to observe the eventual exec and to ensure that your process is also traced.
However, SIP prevents certain programs from being traced, and in particular programs in /usr/bin, like most shells. This causes run to stop working entirely, because the shell can't be started.
So, to make gdb continue to work, users often set startup-with-shell off. Perhaps whatever gdb build you are using does this by default (or maybe, like me, you put this in your .gdbinit and forgot about it). This setting lets run work -- but at the cost of disabling redirections.
There's a gdb bug for this which you can follow.
I am trying to redirect Terminal output to Eclipse console using external tools where I specified Terminal path (for example /usr/bin/xterm). When I run this tool it opens Terminal outside eclipse. When I did same thing in Windows 7, setting external tool location to Windows\System32\cmd.exe it ran inside Eclipse console. I wonder how I can make Terminal (in Ubuntu 14.04) work the same way.
You should use /bin/sh as command interpreter.
In Windows, cmd.exe combines two functions—interpreting commands and displaying terminal window. In Unix these functions are strictly separated. /bin/sh interprets commands and /usr/bin/xterm (or /usr/bin/x-terminal-emulator) displays terminal window, inside which it runs /bin/sh (or other shell like /bin/bash, /bin/zsh etc.) to interpret commands.
So if you ask Eclipse to run something via /usr/bin/xterm, it will appear in a new window, because that's what XTerm does. If you just want Eclipse to capture the output, ask it to run it directly via /bin/sh.
When I run...
perlbrew switch perl-5.16.0
...I get...
A sub-shell is launched with perl-5.16.0 as the activated perl. Run 'exit' to finish it.
...then a bash prompt appears.
Is this expected behavior?
If not, how can I fix it?
That happens when you have an improperly installed perlbrew. As part of the installation, you are instructed to add a command to your shell startup script, but that appears to be missing.
Add the following to your shell startup script:
source .../perlbrew/etc/bashrc
There's a similar script for csh.
source .../perlbrew/etc/cshrc