Wait for screen window to end - bash

I'm writing a shell script which utilises screen to display several things at once (split screens)
One of the windows will be the "gui" code which will ask the user questions while other windows display various progress items.
Part way through the script I have a need to vim a file. But this part of the code is within a subshell with redirected inputs. vim does not work well here*
So I figured I could open up a new screen window and load vim in there screen -X screen vim file
The problem is I need the gui code to wait until vim has quit before continuing.
So how can I wait for a specific screen window to end, from within screen?
screen -ls will not work here because it is only one of several windows within the whole session which I need to monitor.
I've also looked at screen -QX windows but this would appear to interrupt the vim session
* Relating to vim and the subshell: I've tried using exec 3<&1; cat file1 | ( read whatever; vim file2 <&3 ) but this has some major issues (e.g. can't see the first few lines of the file!)

Based on #William's comment this code:
screen -X screen vim --servername MYSERVER`
sleep 1
vim --servername MYSERVER --remote-wait file.txt
opens up vim in a separate window (and focusses it)
and then opens the file into that session and waits until the user quits vim
The sleep would appear to be required to give them vim session time to start up, otherwise the 2nd command can't find the vim server and instead tries to edit locally (which won't work inside the redirected subshell)

Related

Why does Fastscripts work with this but Platypus doesn't

Mac running Catalina. This code
#!/bin/bash
pbpaste|pbcopy
pbpaste>/tmp/tmp$$
open -W -a macvim /tmp/tmp$$
while [ `ps -A|grep MacVim|wc -l` -gt 1 ]
do sleep 1
done
cat /tmp/tmp$$|pbcopy
rm -f /tmp/tmp$$
is intended to plain-text the paste buffer then call up a terminal running macvim so I can use vi with less faff then put the result back in the clipboard. Its a way to speed-up editing when using various tools other tools and I just want to edit a section with vi.
I works well when called from Fastscripts or just plain execution but it won't work when I use Platypus to build a menubar app so its one fast click to use it - or rather, it works sometimes. Sometimes it hangs because it cannot connect input to the window in which macvim runs. I have to kill it from Activity Monitor to regain any control of input to other windows such as terminal. I've tried connecting stdin in the "open" command but still only works sometimes. And it shouldn't be standin anyway.
How is Fastscripts launching it and how can I do the same inside the script ?
I'd like very much to be able to launch it with a single click from the menubar but I don't know how to. I can build the platypus app if I know what to put in the shell script.
Thanks
andy

-echoctl not being ackonowledged in forked program

Please,
I have a terminal application that requires no echoing of control characters back to the terminal.
I can happily issue 'stty -echoctl' at a terminal, run my application and obtain the result I am after. Further, I can include 'stty -echoctl' in .bashrc and everything is fine. (I have also added it to .profile but that seems to bring in .bashrc anyway)
I can then open another terminal (type 'konsole/gnome-terminal/xterm' in the original console and again I get the result I expect.
The problem I have (and this is in preparation of forking the program form another application) is that if i try
$ xterm -e ./V2.13
or even
$ xterm -e bash -c ./V2.13
the control characters are in fact echoed back to my app.??
EDIT:Additionally is there any need (benefit) in executing bash to execute my application ?

Open a small window while in Vim for executing commands

I need to write lot of code and compile very often. I hate switching back and forth various windows just to compile the code. Is it possible to open a small window at bottom and run invoke shell and close that window when needed?
With GVim or MacVim, you can run external commands in the command-line: Gvim/MacVim comes with a (very) limited shell that will happily show you whatever the compiler outputs. The general usage pattern is:
:!command
:!command %
With CLI Vim, the same method will pause Vim and return to the shell to execute your command.
In both cases, you'll get a message asking you to press ENTER to come back to your normal editing.
Using :make | cw would be a slightly more sophisticated alternative, with the added bonus of showing the errors in the quickfix window.
An even more sophisticated approach would be to use Tim Pope's Dispatch plugin in combination with tmux or screen.
Sounds like a problem for Screen
http://www.gnu.org/software/screen/
Quick reference of commands
http://aperiodic.net/screen/quick_reference
I use tmux to achieve something like that. I have the following in my ~/.tmux.conf file:
bind s splitw -v -p 25 -c '#{pane_current_path}' '/bin/bash'
bind q kill-pane
On pressing Ctrl-b + s (prefix + s), a new pane containing a bash shell opens up at the bottom. I can run shell commands from there: find, grep, make, etc. When I'm done, I press Ctrl-b + q to close the shell.
To enable tmux on every bash session, add the following to your ~/.bashrc:
[[ -z "$TMUX" ]] && exec tmux
Maybe map a key to shell out to the compiler and run the program if compilation is successful:
:map F8 :!cc % && ./a.out
Or maybe just
:sh
make run
Ctrl-D
Another option is to suspend vi, using Ctrl-Z and do your stuff in the shell, then type fg to bring vim back to the foreground. Note that this is actually a feature of your shell, rather than vim but it produces the effect you seek.
Note this idea originates from the book "Efficient Linux at the Command Line" by Daniel Barrett. I forget the page number.

How to start a new process in a new window in an existing GNU screen session, from outside the session

I asked a similar question here and got pretty close to what I'm looking for
How to start a process from another application and then open a terminal to that process in gnu screen
...but, this doesn't quite get to what I'm after, which is starting a process in a new window (not an existing window) in an existing screen session (not a new screen session).
If you are at a command prompt in a screen session, you can do this:
screen [screen options] command param1 param2
But, how do you do it if you are outside the session? For example, if you want to run this as a cronjob?
When you aren't in a screen session, you can pass the -X flag to screen to execute a screen command.
For example, the screen command in screen opens a new window, optionally with a command to execute.
Assuming you already have screen open somewhere:
screen -dr -X screen sleep 20
Note that the new window will close once the command (sleep in this case) finishes. If you want to keep it open you could potentially do something like this, which will type 'date\n' in the new window:
screen -dr -X screen
screen -dr -X stuff "date
"
The man pages of course have much more detail.

Linux equivalent of the DOS "start" command?

I'm writing a ksh script and I have to run a executable at a separate Command Prompt window.
xdg-open is a similar command line app in linux.
see https://superuser.com/questions/38984/linux-equivalent-command-for-open-command-on-mac-windows for details on its use.
I believe you mean something like xterm -e your.sh &
Don't forget the final &
maybe it´s not a seperate window that gets started, but you can run some executables in background using "&"
e.g.
./myexecutable &
means your script will not wait until myexecutable has finished but goes on immediately. maybe this is what you are looking for.
regards
xdg-open is a good equivalent for the MS windows commandline start command:
xdg-open file
opens that file or url with its default application
xdg-open .
opens the currect folder in the default file manager
One of the most useful terminal session programs is screen.
screen -dmS title executable
You can list all your screen sessions by running
screen -ls
And you can connect to your created screen session (also allowing multiple simultaneous/synchronized sessions) by running
screen -x title
This will open up the emulated terminal in the current window where executable is running. You can detach a screen session by pressing C-a C-d, and can reattach as many times as you wish.
If you really want your program started in a new terminal window, you could do something like this:
xterm yourtextmodeprogram
or
gnome-terminal -e yourtextmodeprogram
or
konsole -e mc
Trouble is that you cannot count on a particular terminal emulator being installed, so (again: if you really want to do this) you would need to look for the common ones and then execute the first one encountered.
As Joachim mentioned: The normal way to do this is to background the command (read about shell job control somewhere, if you want to dig deeper).
There are also cases where you want to start a persistent shell, i.e. a shell session which lives on when you close the terminal window. There are two ways to do this:
batch-oriented: nohup command-to-run &
interactive: screen
if you want a new windows, just start a new instance of your terminal application: in kde it's
konsole -e whatever
i'm sure the Gnome terminal has similar options
Some have recommended starting it in the background with &, but beware that that will still send all console output from the application you launch to the terminal you launched it from. Additionally, if you close the initial terminal the program you loaded will end.
If you're using a desktop environment like KDE or GNOME, I'd check the alt+f2 launching apps (gnome-open is the one for GNOME, I don't know the name of the KDE app) and see if you can pass them the command to launch as an argument.
Also, if your intention is to launch a daemon, you should check the nohup documentation.
I used nohup as the following command and it works:
nohup <your command> &
then press enter and enter!
don't forget the last &
for example, I ran a python code listening to port 5000:
nohup python3 -W ignore mycode.py &
then I made sure of running by netstat -tulnp | grep :5000 and it was ok.

Resources