I want a script to check if it has been started from within a terminal window. If it was started without window, it shall re-run itself in a visible terminal window.
If found this script line:
tty -s; if [ $? -ne 0 ]; then konsole -e "$0"; exit; fi
It works fine. However since it uses konsole, it is specific to KDE. Is there a more portable solution that runs on Linux system without KDE as well?
No generic solution exists that will work over ALL window systems. however, you can look into implementing a list of common terminal programs. Good thing all take '-e'.
if [ ... ] ; then
for t in konsole gnome-terminal xterm ; do
if type "$t" >/dev/null 2>&1 ; then
$t -e "$#"
break
fi
done
Also note that 'tty -s' checks if your current stdin is connected to a terminal. You probably want to add a test for valid display ("$DISPLAY"). No point in launching a terminal window, if not running under some window manager.
You can improve code further by checking for environment variables that let you know if you are running under terminal: 'GNOME_TERMINAL_SCREEN', 'XTERM_SHELL', or checking of '$TERM' for 'xterm*'.
Related
I would like prevent other terminals from running a certain script whenever another terminal is running it however in bash but I'm not quite sure on how I would be able to go about in doing it. Any help or tip could be greatly appreciated!
In example:
When that script is being run on another terminal, all other terminals would be unable to run that certain script as well. And display a message "UNDER MAINTENANCE".
You can use the concept of a "lockfile." For example:
if [ -f ~/.mylock ]; then
echo "UNDER MAINTENANCE"
exit 1
fi
touch ~/.mylock
# ... the rest of your code
rm ~/.mylock
To get fancier/safer, you can "trap" the EXIT signal to remove it automatically at the end:
trap 'rm ~/.mylock' EXIT
Use flock and put this on top of your script:
if ! flock -xn /path/to/lockfile ; then
echo "script is already running."
echo "Aborting."
exit 1
fi
Note: path/to/lockfile could be the path to your script. Doing so would avoid to create an extra file.
To avoid race conditions, you could use flock(1) along with a
lock file. There is one flock(1) implementation
which claims to work on Linux, BSD, and OS X. I haven't seen one
explicitly for Unix.
There is some interesting discussion here.
UPDATE:
I found a really clever way from Randal L. Schwartz here. I really like this one. It relies on having flock(1) and bash, and it uses the script itself as its own lockfile. Check this out:
/usr/local/bin/onlyOne is a script to obtain the lock
#!/bin/bash
exec 200< $0
if ! flock -n 200; then
echo "there can be only one"
exit 1
fi
Then myscript uses onlyOne to obtain the lock (or not):
#!/bin/bash
source /usr/local/bin/onlyOne
# The real work goes here.
echo "${BASHPID} working"
sleep 120
In Ubuntu 14.04, I created the following bash script:
flock -nx "$1" xdg-open "$1" &
The idea is to lock the file specified in $1 (flock), then open it in my usual editor (xdg-open), and finally return to prompt, so I can open other files in sequence (&).
However, the & isn't working as expected. I need to press Enter to make the shell prompt appear again. In simpler constructs, such as
gedit test.txt &
it works as it should, returning the prompt immediately. I think it has to do with the existence of two commands in the first line. What am I doing wrong, please?
EDIT
The prompt is actually there, but it is somehow "hidden". If I issue the command
sudo ./edit error.php
it replies with
Warning: unknown mime-type for "error.php" -- using "application/octet-stream"
Error: no "view" mailcap rules found for type "application/octet-stream"
Opening "error.php" with Geany (application/x-php)
__
The errors above are not related to the question. But instead of __ I see nothing. I know the prompt is there because I can issue other commands, like ls, and they work. But the question remains: WHY the prompt is hidden? And how can I make it show normally?
Why isn't this command returning to shell after &?
It is.
You're running a command in the background. The shell prints a new prompt as soon as the command is launched, without waiting for it to finish.
According to your latest comment, the background command is printing some message to your screen. A simple example of the same thing:
$ echo hello &
$ hello
The cursor is left at the beginning of the line after the $ hello.
As far as the shell is concerned, it's printed a prompt and is waiting a new command. It doesn't know or care that a background process has messed up your display.
One solution is to redirect the command's output to somewhere other than your screen, either to a file or to /dev/null. If it's an error message, you'll probably have to redirect both stdout and `stderr.
flock -nx "$1" xdg-open "$1" >/dev/null 2>&1 &
(This assumes you don't care about the content of the message.)
Another option, pointed out in a comment by alvits, is to sleep for a second or so after executing the command, so the message appears followed by the next shell prompt. The sleep command is executed in the foreground, delaying the printing of the next prompt. A simple example:
$ echo hello & sleep 1
hello
[1] + Done echo hello
$
or for your example:
flock -nx "$1" xdg-open "$1" & sleep 1
This assumes that the error message is printed in the first second. That's probably a valid assumption for you example, but it might not be in general.
I don't think the command is doing what you think it does.
Have you tried to run it twice to see if the lock cannot be obtained the second time.
Well, if you do it, you will see that it doesn't fail because xdg-open is forking to exec the editor. Also if it fails you expect some indication.
You should use something like this
flock -nx "$1" -c "gedit '$1' &" || { echo "ERROR"; exit 1; }
I'm using emacs under Ubuntu
If I want to edit a.txt then I either click on the emacs icon or use
$ emacs --geometry 10x10 --fullscreen --no-splash ~/a.txt &
from bash. My .emacs file starts the emacs server.
If I then want to edit another file from the command line, I use
$ emacsclient -n ~/b.txt
to load the file into the existing emacs.
but I keep getting it wrong, and all hell breaks loose in various ways.
How would I make a bash command 'e', that checks whether the emacs server is already running, and executes the appropriate command?
Attempts to use the emacsclient -a switch invariably produce undesirable and ill-determined behaviour.
Extra points if it can 'do the right thing' when run on a console too.
So far this function definition in .bashrc seems to be a perfect solution:
function e #open emacs in background and disown it, or if already running use emacsclient
{
echo "emacs function backgrounds and disowns emacs, or calls client if server already running; see .bashrc";
local FLUFFY="$#";
local SERVERSOCKET=/tmp/emacs${UID}/server ;
echo "trying to open: " $FLUFFY
echo " checking: " $SERVERSOCKET "for emacs server " ;
# test for existence of emacs server socket
if [ -e $SERVERSOCKET ]; then
echo "using emacsclient"
emacsclient -n $FLUFFY;
else
echo "starting emacs: make tea..."
emacs --geometry 10x10 --fullscreen --no-splash $FLUFFY & disown ;
fi;
}
which was derived from this incantation:
FLUFFY=~/b.txt ; if [ -e /tmp/emacs1000/server ]; then emacsclient -n $FLUFFY; else emacs --geometry 10x10 --fullscreen --no-splash $FLUFFY & fi;
which does what I want by checking for the existence of the emacs server socket for user 1000.
I am creating an application installer for Mac. The installer involves getting a code from the user on install. I used an Installer Plugin for the Code Input screen.
I have read (from this link) and verified that plugins do not work in the command line and Apple Remote Desktop. I can check if the installer is running from the command line using a variable ("$COMMAND_LINE_INSTALL").
My questions is, how can I programmatically check if it is running via Apple Remote Desktop?
If pstree is available, you can get a quick ancestry of the current process and see if Apple Remote Desktop is in it, something like pstree -p $$ in bash. Unfortunately, I installed pstree using brew, so this is most likely not going to be available for you, unless you distribute a binary yourself.
The other approach is to walk up the parent yourself. Here is a sample that I tested to be working to check if I am running inside iTerm (I used iTerm as a sample because I don't know what the pstree output would look like when running inside Apple Remote Desktop).
pid=$$
running_in_iterm=0
while [ $pid -ne 1 ]; do
command=$(ps -o command= -p $pid)
case "$command" in
*iTerm*)
running_in_iterm=1
break;;
esac
pid=$(ps -o ppid= -p $pid)
done
if [ $running_in_iterm -eq 1 ]; then
echo "Running in iTerm"
else
echo "Not running in iTerm"
fi
You can try running this script from both the built-in Terminal app as well as iTerm and see the difference.
I'm trying to debug my application on Mac OS X Mountain Lion using a bash script which is used to open the application with several input methods. Though I would like to the script to quit running with a short description what happened, if it encounters any error signals (without set -e).
Script is constructed in a following manner:
#!/bin/bash
#
...
while true
do
for input in $INPUTS
do
/path/to/app $input 2> mylog.log &
sleep 2
tail -2 /private/var/log/system.log | grep $ERROR &&
echo $input &&
exit 1;
test $? -gt 127 &&
echo $input &&
exit 2;
# nothing happened, kill the app and continue with a new test
pkill -9 app
done
done
And I've tried to debug the script by manually sending
pkill -SIGSEGV app
in Terminal.
I'm trying to get the script to print the output to the command line (hence the '&' in the app command) and also to the log file (2>), but it looks like if a crash occurred, it doesn't print the application log properly neither to the file nor terminal and the script just keeps running. Also, somehow the grep from system.log does not catch the crashes.
What would be a better option to monitor and catch application crashes in a shell script on Mac? I've done similar tests on Linux and they worked fine.
EDIT: I am also open for suggestions on other methods for monitoring crashes than a shell script. :-)