I run my program through tee:
<prog.exe> | tee out.txt
prog.exe runs for a long time, and sometimes I pause it (in the console) with the pause/break key. From that point, wincyg1.dll seems to be blocking, and any app that I run (e.g. ls.exe from another console window) would hang and wait until I release the break from the console that runs the tee.
EDIT
Some more details. As console, I'm using conemu (at the moment, I can't test cmd.exe.)
My app is a python extension (.pyd that was built with swig and visual studio and has nothing to do with cygwin), and I use it in a PyQt script.
I can't come up with a simple minimal example to reproduce the issue, and it would take some effort to track it down.
I guess right now I'm wondering if anyone is familiar with cygwin's architecture to answer if they use a mutex that would cause such a thing.
I merely use cygwin commands (e.g. ls, tee, grep, which) as convenient shell extensions, and they have nothing to do with my program.
Related
I am making a small-scale project which reads from a file of 101 items, creates a vector of strings, and then randomly accesses one of the items and prints it to the standard output. The program works exactly as intended when run from the terminal, whether through cargo run
or by running the executable from the terminal with ./executable_name. The problem is, if I double click on the executable without a terminal open there is nowhere for the information to be printed and the program is essentially useless. I know how to check if a terminal is open using
if atty::is(Stream::Stdout) {
println!("Already in terminal");
} else {
// this is where I get confused
}
but from there I don't know where to go. I have experimented with things like Command::new("sh"); but am struggling with the documentation. Eventually, the idea is that I can compile this on my partners Mac without losing its functionality as I am writing it on Linux, and create an easy to use application to run it on her machine.
Programs generally do not open their own terminal windows. The way you arrange for one to exist varies by platform:
On macOS, you actually don't have to do anything; the default behavior of double-clicking an executable is to open a terminal to run it in. (GUI applications have their executables inside of .app packages, so that this behavior does not apply to them.)
On Windows, whether a terminal is opened is a property of the executable, which you can set in Rust with the windows_subsystem attribute. However, the default value is console so you don't need to do anything. (I've heard it is also possible to open a console window after startup, but I am not a Windows developer and can't advise you on the proper system calls to do that.)
On Linux, you'd create a .desktop file that specifies Terminal=true, to ask the desktop environment to launch your program in a terminal, and double-click that file rather than the executable. Or, you could make your program launch a terminal emulator and instruct it to start your program again within itself, but how you do that will depend on what terminal emulator programs are installed.
The one thing you'll have to do for all these cases is add a “Press Enter to exit” prompt to your program. Otherwise, the terminal will close immediately after your program exits, and so your output won't be visible.
eprintln!("Press Enter to exit.");
std::io::stdin().read_line(&mut String::new()).unwrap();
I'm coding a Rust app and since it's fairly small and there don't appear to be any stable UI frameworks, I've made it run in the console using println! and whatnot for input/output. However since this program is intended to be used by people directly after downloading from the internet (due to its use case), they're likely to just double click on it instead of navigating to their downloads directory in a terminal and running it from there.
This is a problem because on Linux, it runs in the background waiting for input and looks like it's not working. On Windows, Rust programs do open in CMD by default. (and in fact many of the search results for my question were about disabling this behavior - the exact opposite of what I want!).
So is it possible to somehow make my application open in the system's default terminal? My preferred way would be to somehow embed in the executable to open in terminal (similar to the -mconsole compiler flag on MinGW). Otherwise would it be possible to detect it's in the background and fork it into a terminal? If that's not possible then is it at least possible to detect that the app is not running in a terminal and throw up a message box telling the user to run in a terminal?
My app is cross-platform but I'm OK with writing code conditionally compiled on one OS.
One typical way would be to distribute a program.sh along with your executable. If .sh extension is bound to opening a terminal in their window manager of choice, it would open automatically. If not - it is enough of a hint for running it from the shell.
Without this file you could:
Detect if the program is already running inside a terminal can be done with isatty(). There's a crate for it.
If not, spawn the terminal app process (see process::Command) and relaunch the program with it by passing its path to the terminal command line options. As #Caesar mentioned there's a bunch of popular terminals that you might want to check for presence on Linux. If nothing is found, xterm could sometimes be a fallback.
I need to open a new terminal from my script but I want to wait for that terminal to exit before continuing with the rest of the script. I know that
gnome-terminal -e 'nano test.txt'
opens a new terminal window with "test.txt" opened in nano, but the calling script does not get blocked. Is there a way to wait for the new terminal to exit, before continuing the original script?
For the benefit of the reader: The answer from #Feiteira used to be the correct answer, but is no more supported by gnome-terminal. Option --disable-factory got removed from gnome-terminal.
To explain the different observation of several people here:
gnome-terminal only blocks, if it is the first instance of it. This single instance then acts as a server for all future invocations of gnome-terminal. Those other gnome-terminal calls then hand everything over to this server and immediately terminate. So you can observe both behavior: "blocking" (when it is the one-and-only single instance) and "nonblocking" (when another instance is already running).
There is a wrapper, for example used by Ubuntu 16.04, which emulates this missing option. However this wrapper is complex. This is done by starting another server (with another service name). And for this server, the same assumption holds (you can attach other gnome-terminals to this server, and those others then come back immediately as well).
My suggestion is to stop using gnome-terminal and to switch to something, which works right out of the box. For example xfce4-terminal officially supports all those little absolutely necessary options for a mature terminal window:
xfce4-terminal --disable-server -x nano test.txt
Also xfce4-terminal introduces --hold which allows you to see the output of a command. Sadly --hold has a bug (at least under Ubuntu 16.04), which causes it to (often) truncate the output (the terminal is closed too early if a command terminates, so all still buffered output of the PTY does not make it to the window. This is a very well known common bug if you are not careful enough with PTYs).
The option you want is: --disable-factory
gnome-terminal --disable-factory ...
You could use && for instance (also see What is the purpose of "&&" in a shell command?):
gnome-terminal -e 'nano test.txt' && sleep 5 && echo "Done"
I am on windows machine, when I temporarily change to console using :sh then back to vim with exit command and then again back to console and it starts over. this causes me to lose my previous directory. Is there other way returning back to vim won't start the shell over?
Not really
https://stackoverflow.com/a/12089631/1427295
GVIM does not retain a "handle" to the shell that launched it in a way
that allows it to send commands back to it. Because of they
synchronous execution, you also cannot launch a shell from GVIM, keep
feeding it commands while also continue working in GVIM.
I'm afraid you have to use the functionality of your window manager to
launch (and then later re-activate) a shell window, and send the
commands as keystrokes to it. On Windows, this can be done (e.g. in
VBScript) via WshShell's Run(), AppActivate() and SendKeys() methods;
there are probably similar mechanisms for window control on Linux,
too.
If you don't mind having that shell inside your GVIM (emulated, with
all its drawbacks), though, there are plugins that enable that.
https://serverfault.com/a/95405
The Windows command interpreter ("cmd.exe") doesn't provide any
support for saving/exporting/keeping history, of, if it does,
Microsoft didn't document it and nobody was ever able to find it. You
can of course try to work around that, like Sean suggested, but
there's (or does appear to be) no built-in support for this
You may be able to output your command history using echo %cd% > prev_dir.txt then create a script that cds to the directory in prev_dir.txt, but you'd still have to remember to save your directory to the file before you exit the shell each time.
I have a recurrent problem when using R with a Linux console. I sometimes suspend it with [Ctrl+Z], then put it to the background with bg, (execute some other commands), then put it to the foreground again with fg.
R resumes correctly with all the workspace intact, but when I type, the characters are invisible (just like when we type passwords).
I still can execute commands though, and I see the response. Moreover, when I type [enter], the prompt doesn't go to the next line, but does something like this: > > >.
Then I need to quit R using q(), in order that everything returns to normal. I didn't manage to find any reference to this problem on internet.
Would you have an idea? Thanks a lot for your help.
No direct answer but via
"Doctor, doctor, it hurts when I do this."
"Then just don't do this."
I would suggest that if you must have an R console open, place it inside screen --- or if you have it, byobu a fancier extensions, or even tmux.
Or even inside the One True Editor (TM) using ESS. For what it is worth, I always run emacs --daemon and then connect to the same R session either via emacsclient -nw on the terminal or under X11 via emacsclient -c (both of which I aliased to emt and emx). I also run byobu sessions for command-line work where I often use littler for command-line tasks and tests.
Unix is a multitasking system. There is no need to limit yourself to one prompt, especially if you suffer side-effects as a consequence.