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
Related
I'm attempting to make a Linux system that is meant to run a GUI on top of a window manager, as it requires it for inputs from a device to work. I say attempting because I've been trying for several days but I can't get the bash scripting to work no matter what.
My approach is using a bash script that starts an X session using openbox with nothing on it except for the program I want running on top (I don't care which WM, as long as it's a WM that makes the input work, which I've found that both XFWM4 and Openbox do. I'm willing to use any other that will be better if after testing suggestions those also happen to work).
Once the program is closed (by selecting Quit on it) I'm left with the WM still running, which I don't want, it must go down along with the app, so the system returns to lightdm's login screen.
I can't modify what the quit command on it does either; would take a long time recompiling and modifying such a big app for something so trivial. This is why I really need the WM to go down by itself when the app's process is gone.
I've tried using the openbox autostart script and also a custom script that is run using the .desktop file that is found by lightdm. All my attempts end up with a script that simply kills the display right after entering the session.
I just want something simple like this:
#!/bin/bash
openbox &
guiapp; openbox --exit (or killall Xorg whatever)
But this syntax won't work. I've tried using things like pid=$(pgrep guiapp) to make it look for the PID every bunch of seconds and if it's not there, kill the WM or Xorg entirely; but those also didn't work, I don't know if my attempts were bad or what. Sorry I can't put those examples since I didn't make backups of my script attempts and I've been trying for quite a long time without success.
I really hope someone can help me.
I finally got it working! I found a post online that was attempting a similar thing to mine and he did this approach:
in ~/.config/openbox/autostart:
xsetroot -solid black &
gnome-terminal --full-screen --hide-menubar -e guiapp &
/etc/guiapp/Exit.sh &
in /usr/share/xsessions/gui.desktop:
[Desktop Entry]
Name=OpenBox Session
Exec=openbox-session
TryExec=openbox-session
Finally the actual solution in /etc/guiapp/Exit.sh:
#!/bin/bash
until [[ $(pidof guiapp) ]] ; do
sleep 1
done
while [[ $(pidof guiapp) ]] ; do
sleep 1
done
openbox --exit
His task was slightly different but all it took was some slight modification of his exit script to tailor it to what I wanted.
This way, LightDM will run OpenBox with the flag telling it to read the autostart script, and autostart will run both the app and a script that will keep looking for the pid of my app every second, and when it's down, it'll quit OpenBox to the login screen automatically, so I can switch to a different DM. Just how I wanted it!
I have 64-bit Cygwin installed on Windows 10, and I would like to open Cygwin GUI applications such as atril from desktop shortcuts, without having to open a Cygwin terminal and launching them from the command line manually.
I have:
created a ~/.startxwinrc file containing the line "exec sleep infinity"
added these lines to ~/.bashrc
export DISPLAY=:0.0
which startxwin > /dev/null 2>&1
if [ $? -eq 0 ]; then
startxwin > /dev/null 2>&1 &
fi
I can now open the applications by launching a Cygwin terminal, typing the name of the application, and pressing Enter. However, the desktop shortcuts I have created silently fail. One of these was:
C:\cygwin64\bin\run.exe -p /bin xterm -display 0.0 -e /bin/bash -l /cygdrive/c/Users/MYNAME/atril-launcher.sh
(I think that one failed because xterm and startxwin are incompatible; I may be wrong.)
I have tried other command lines which include run.exe, but have been unable either to launch the application or to get a meaningful error message.
atril-launcher.sh has the correct permissions, and contains the following text after the shebang (I couldn't get the formatting right trying to post the shebang in here.). It can be successfully launched from within the Cygwin terminal.
nohup /bin/atril.exe &
sleep 3s
I have searched the Internet for information on this problem, much of which is out of date (Cygwin now using /bin instead of /usr/bin, Cygwin no longer having an X11R6 folder, DISPLAY=:0.0 instead of DISPLAY=localhost:0.0, etc...) but at this point I'm at my wits' end.
It looks as though I've found a partial answer to my own question. It's imperfect for various reasons:
It probably depends on startxwin already having been launched elsewhere as a background process.
The applications are slow to launch; there's a delay of a few seconds.
Terminal windows which the user cannot interact with (presumably the shells which act as parent process for the GUI applications) appear alongside the application windows.
But it will probably be enough to be getting on with. Assuming pluma to be our application, here is the shortcut that successfully launches it:
C:\cygwin64\bin\mintty.exe /bin/bash -l -c "export DISPLAY=:0.0; pluma"
I'd like to thank the author of answer https://stackoverflow.com/a/12215570/9223868 - which I did not find through googling, only through its appearing in the "Related" list when this was posted.
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)
When a GUI process is launched from the OS X terminal, the window shows up in the background, and you have to use command-tab to give it focus.
Is there a way to make the terminal automatically give such GUIs focus after they are launched?
For example (assuming gitk is installed):
% gitk
should launch the GUI and then switch to it.
Note: For several reasons, using open as this answer suggests is not a general solution.
Update: To better explain why the open method isn't satisfactory, here's a sample bash session (with witty commentary).
% cd /my_repo
% gitk
Waiting for the GUI to appear ... any day now ... oh wait -- it's already open. I just didn't notice because it opened a window BEHIND my terminal. I wonder how long I was going to sit here waiting....
% open gitk
The file /my_repo/gitk does not exist.
Ah, of course.
% which gitk
/usr/bin/gitk
% open /usr/bin/gitk
What the ... it opened a new terminal window to run gitk, and it did so in my home directory, not /my_repo, so gitk complains that the current directory isn't actually a repository...
Do you need to invoke it synchronously? If not, you could start it asynchronously with & and then activate it with osascript -e 'tell application "gitk" to activate'.
If you are dealing with gitk specifically you can edit the gitk file to achieve this, I posted an answer on the apple stack exchange: https://apple.stackexchange.com/a/74917/35956
You can find the gitk file using the following command from the terminal
which gitk
In my gitk file I found a line that looks like the following near the top (line 3)
exec wish "$0" -- "$#"
I changed it to this
exec wish "$0" -- "$#" & exec osascript -e "tell application \"Wish\" to activate"
When I execute gitk from the command line the gitk window comes to the foreground, another side effect of this is that it executes asynchronously
You can wrap up #chris page's answer in a bash function and drop it in your .bashrc
function gitk() {
command gitk "$#"&
command osascript -e "delay .5" -e "tell application \"wish\" to activate"
}
There should be a way to get rid of the delay by looping and looking for 'wish' with a timeout.
NOTE: 'Wish' is the window title that shows up on my Mac for gitk.
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.